@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
@Lady @djsundog @TheGibson Wait, what happens if I'm a jerk and want to do jerk things like looking at distant instance A, noticing that someone on that instance posted a status/urn:uuid:stuffherestuffherefroma , then posting my own, different status/urn:uuid:stuffherestuffherefroma from my jerk-coded instance M which lets me do that?
If my toot makes it to instances L, K, J before the other status/urn:uuid:stuffherestuffherefroma does, what happens then?
Like obviously I get banned for being a jerk, but how do you tell it was me and not A? And how do you clean up my mess, now across multiple servers?