> Federated networks like Mastodon and Lemmy are going to get people well-acquainted with websites shutting down. It's hard work (time, money, etc.) to run these things for people, and people start to really lean on them.
Mastodon is filled with such utterly basic UX issues. You move instances because the old one announces a shutdown? No old posts visible, no import possible. You want to see the history of an old account on another instance? The oldest toot you'll see is the first one that your instance picked up from that account. You have to switch to their instance to see old toots - there's a helpful link at the end of the feed, but it's still annoying. "Trending" topics only carry stuff happening on your server, and most of it is days old garbage. Search is horribly broken and inconsistent.
> You move instances because the old one announces a shutdown? No old posts visible, no import possible.
But this isn't "utterly basic" to solve on the backend due to how ActivityPub (currently) works. First you have to allow backdated posts[0] (not supported in the spec) which requires a mechanism to stop them being sent out (else they'll appear in current timelines[0]) but also you need a mechanism to send them out (to update the old URLs except how does the new instance know where the old instance sent the status? And how do you prove that you have the right to even request the change?)
These are probably not insurmountable but they do require a lot of thinking about!
[0] I ran into these importing an old Twitter bot into my Akkoma instance. I had to modify the server code and it was not a fun time.
> But this isn't "utterly basic" to solve on the backend due to how ActivityPub (currently) works.
They're basic for the user. I know a few people who left Mastodon for good after the second or third time they had to shift servers. That kind of stuff should have been thought of from the beginning...
> to update the old URLs except how does the new instance know where the old instance sent the status? And how do you prove that you have the right to even request the change?
The same way an account move is currently reported to the instances where followers reside and handled there - the account-move operation would only need to do a full re-scan of the old profile. That's a ton of traffic for people with followers from many instances, I agree, but the source instance could trigger the creation of something like a data dump that destination instances can download without hitting the API.
> something like a data dump that destination instances can download without hitting the API
That gets you the old statuses, great. How do you then insert them into your existing instance? You can't just repost them because they'll appear with new timestamps (bad). You can't just repost them with old timestamps because servers and clients assume "just arrived == now" (bad). If you're using sequential IDs on your status table, good luck with that because I'm pretty sure someone has taken the shortcut of using that instead of the timestamp. Assuming you can work all those out, now you need to update the old URLs in the follower timelines to point to the new URLs (unless we punt on this and just let the old timeline sit around as it.) Except you don't know who got those statuses when they were posted - the old instance would need to have kept all the queue records for every post and be willing to supply them to the new instance. Or you can "eh" that and send them out to the new followers (except we don't want to do that because it confuses current instances and clients to get old timestamps at a new time) but that doesn't mean everyone will be updated. Or you can try and persuade the old instance to redirect each old status to its new URL once you've updated the software and protocol and clients to allow for status redirection, obviously, and worked out how to verify that server X is actually allowed to redirect A@Y's old statuses and isn't some hijacker / spammer / whatever and ...
I've not even given this much thought - I'm sure people who actually dwell in ActivityPub and security worlds can give a much better explanation of why it's not at all easy to implement.
> That kind of stuff should have been thought of from the beginning...
Yep, can't disagree that a whole heck of a lot more thought should have been put into the AP protocol from the start.
Mastodon is filled with such utterly basic UX issues. You move instances because the old one announces a shutdown? No old posts visible, no import possible. You want to see the history of an old account on another instance? The oldest toot you'll see is the first one that your instance picked up from that account. You have to switch to their instance to see old toots - there's a helpful link at the end of the feed, but it's still annoying. "Trending" topics only carry stuff happening on your server, and most of it is days old garbage. Search is horribly broken and inconsistent.