@TheGibson while we’re at it, if one of the projects would alias all the other projects’ url conventions to their own we could even maintain historical links to toots without shit breaking and it’d be pretty nice.
@djsundog @thegibson we need ark-style persistent-IDs-in-URLs for posts on the fediverse tbh
the short version: you navigate to a link like
/@xyz/statuses/urn:uuid:fc33bc35-2f63-49ec-865e-ac58cf86c811
your instance sees the urn:uuid:fc33bc35-2f63-49ec-865e-ac58cf86c811 and knows that is a status, even if it doesn't understand the rest of the path
your instance automatically redirects to
/user/xyz/status/urn:uuid:fc33bc35-2f63-49ec-865e-ac58cf86c811
it's not hard to retroactively generate PIDs for existing statuses e.g. as Tag URIs, but this should have been done from the beginning for a federated service. statuses only having local identifiers is a big part of the problem
(ARK: <https://arks.org/>)
(Tag URI: <https://taguri.org/>)
@gaditb @djsundog @thegibson yeah this is why i think Tag URIs are a better fit than UUIDs, UUIDs are just more recognizable so i used them as the example
with a Tag URI the domain name of the issuer is part of the URI, so you could simply reject any posts where that didn't match. this might mean that posts would cease to be federatable once you moved them to a different domain name (unless you set up a mechanism by which the old domain could verify the new one), but it would at least mean the posts WOULD be movable
@gaditb @djsundog @thegibson and it would definitely solve the use case of migrating posts between services hosted on the same domain name