@prologic@twtxt.net idk, is admin abuse or user abuse the biggest concern? Giving users the tools they need to seamlessly migrate to a new pod helps with admin abuse. User abuse is a different matter, especially given the decentralized structure.
@abucci@anthony.buc.ci @prologic@twtxt.net we had a conversation about this a few months ago… While the redirect option is nice to have, I still feel it might not be enough, specially since it depends on the support of the poderator. Having the possibility to point a new feed to a specific old one would help (ie, prev allowing full URIs instead of relative paths, and pods letting users define their feeds prev).
Sorry I’m pulling this topic into an already complex thread ;-), specially when I was supposed to write a proposal for this change, and never did (yet?)…
@movq@www.uninformativ.de @prologic@twtxt.net Redirects will work for on feed removals, if the poderator is interested in providing them - it depends on its benevolence and good will. In any case, removals must be implemented somehow (at least in pods operating under EU law), so there’s no downside in implementing it with a redirect option.
Regarding # prev, maybe it is best to recover the old thread (which I think was (#opev6mq)).
@prologic@twtxt.net I suppose https://search.twtxt.net/search?q=%23opev6mq&t=term&f=conv is the right link…
@prologic@twtxt.net well, this is embarrassing, I manage to reach the result on the web interface, but not to find an URL that will point to them…
@prologic@twtxt.net assuming the pod is running a recent version of yarn, unmodified. But we can assume that…
@prologic@twtxt.net @movq@www.uninformativ.de I’ll need to re isit the old thread to be sure if there isn’t more to it than that, but if multiprotocol is the only reason, then we can allow “relative or full”, so both scenarios are catered for, right?
@prologic@twtxt.net @movq@www.uninformativ.de :
Thanks!, reading that was useful.
It seems to me that the choice of ‘relative’ was meant to consider users’ use cases (multi-protocol, moving the feeds from one place to another, etc.), without any added convenience to the clients, specifically. Thus, I’d argue that there is nothing against extending the spec to also allow full paths: current users are unnafected, and we’d be catering for new/other use cases.
Yes, I do realize that would mean this would have to go into a new version of the spec, and clients would have to implement it in order to comply with the new version of the spec.
@prologic@twtxt.net @movq@www.uninformativ.de I created an issue so we can have this conversation outside of twtxt.