(#opev6mq) I’m uncertain I’m looking at the right place, but from how I read it, absolute URLs not only aren’t mandated, they aren’t even a possibility. I’ll open a PR soon™

@prologic@twtxt.net @movq@www.uninformativ.de (#opev6mq) Imagine I want to stop updating my feed on my domain.com by starting a new feed at coolerdomain.net, but point to the previous one in its previous address, for history purposes.

Or maybe I want to stop using this pod because I think I like yours best, or I host my own now… so I want to continue there, pointing to this as my previous one.

@prologic@twtxt.net (#opev6mq) Spoofing is always possible, and always a concern (don’t we “deal” with it already for the url field?).

For the side-question, the feature is nice but depends on availability, and trust, I’m more interested in adversarial interoperability. What if I’m moving from a pod because I dislike their new policies, or new terms of service, their monetization model, etc.? And what guarantees do we have that every pod (or even yarn implementation) will have the redirect option available to its users?

@movq@www.uninformativ.de (#opev6mq) That’s the scenario, yes. Importing twtxt feeds seems like a good functionality, but it doesn’t totally replace (or exaust) the scenarios in which one could want to have their “prev, static twtxt file” on a different path/subdomain/etc…

@movq@www.uninformativ.de (#opev6mq) That would be a scenario, yes.

@prologic@twtxt.net (#opev6mq) I think so, yes. More generically, places were you have no control over the webserver (hosting services via ssh/ftp without htaccess support is another example).

@prologic@twtxt.net (#opev6mq) I see reasons for allowing absolute URIs, and see no reason not to.

I suppose I should condense this thread into a write-up proposing the change, explaining why, and proposing client behaviors (“how to deal with a prev pointing to an absolute URI”). But that takes time, and I don’t know when will I reserve some to sit down and actually do the proposal :-)