Mastodon very much supports moving followers/following. Not all others do, but the mechanism is well established. It does not yet support moving posts (it supports exporting them, but there's no import mechanism short of an admin manually doing a database import), but there's nothing that makes adding that technically difficult - it's down to coming to agreement about how to do it.
That Bluesky in theory supports it is pretty irrelevant until they open up federation.
In general, mastodon servers (well behaved ones at least) are kind of vouching for the timestamps of all the messages they host.
If a user transfers their account over, with an archive of posts, and uploads them to a server saying 'trust me, bro, I totally posted all this stuff last year'... they're dumping a bunch of posts into that server's feed whose timestamps can't be vouched for.
There might be mechanisms for a server to pull in the timestamps from the original host server, or to recognize the posts as having been streamed over previously... but uploading post archives is definitely a 'high trust' action for a server to take on behalf of a user.
As long as the old server is up, the timestamps are readily available. In the exports, the posts are signed with the users private key. Either way, the new instance can validate what the original instance said about the posts, and put up a banner saying "migrated from...", "date according to ...".
There are some edge cases to consider, such as how well various software will deal with an activity showing up on a url different to the one it was created at, but the date thing is largely a red herring.
> As long as the old server is up, the timestamps are readily available
But among the scenarios we have to expect for users wanting to migrate an account from system A to system B in the fediverse are ones where the user’s departure from the original server is not amicable, or voluntary. And, yes, where the source server has just blown up and vanished.
> In the exports, the posts are signed with the users private key.
This refers to the full archives you can export from within Mastodon of your own activity.
There is every reason to make it easier for people to have always-up-to-date backups of their data because the current process means people need to actively think about it. That is a valid concern (and it really annoys me that Mastodon does not include the post signatures in the JSON served up by the API too, which would make it far easier to keep an up-to-date archive; there's no real reason not to). But as long as* the user has an up to date export, and as long as the other instance has seen your public key before or can otherwise verify it with a truster party, the authenticity of that data can be verified. It's not ideal, but it's an option.
Improving on this would also be easy, and I strongly think that once someone adds an import, the other side of that coin really is to push to ensure signatures for posts are included in the API output, and e.g. encourage apps to opt to let users keep a full copy of their signed posts (that part of the design of Bluesky is one I like) offline. I also do think that the Bluesky choice of ensuring the user has access to a recovery key is good, and would love to see something like that added for ActivityPub as well - with or without Mastodon core devs agreeing. It doesn't solve everything, and you'd still be limited until/unless major instances buy in, so, sure, it's possible and maybe even likely that there will be a time period when Bluesky does better than Mastodon on it. Then again once they turn on federation, that might well get Mastodon devs to take this more seriously.
The protocol trivially supports it given there is already a mechanism to indicate you're moving, and all your posts are accessible,and can be pulled down by the new server, or can be extracted from the downloadable (signed) export. So it boils down to willingness or priorities, not the protocol.
Posts are linked with accounts and blasting old posts out as if they are new is not practical in a federated network, and since Mastodon doesn’t support backfilling (and likely never will) it’s just not going to happen. This isn’t even getting in to the logistics of redirecting replies and likes/boosts. The GitHub issue for it has been open since 2019.
There's no need to post old posts out "as if they are new". They just need to be hosted by the new server, and returned as part of the right collections when someone requests those collections. They do not need to be sent out at all, because they are not new.
Posts are "linked" with accounts in the sence that the actor id contains a URI, and if served up from a new address, that actor id can end up pointing to a location that does no longer exist. But Mastodon also stores the signature of the posts. So a simple solution to this is to also include signed assertions about the transfer of an account, and serve up the signature with the posts, and optionally perhaps wrap the whole thing in a "local" "Announce" activity which would mitigate some compatibility issues with clients that might object to an object being included in a collection with actor id's from a different domain.
This is not a complicated problem to solve, and one entirely orthogonal to the protocol, which just sets out a very simple framework for the distribution of activities and defines a basic set of activities. There's nothing in the protocol which even requires protocol changes for this.
> and since Mastodon doesn’t support backfilling
Mastodon backfills all kinds of things. There are just limits on it that would need to be eased, and limits on what of that it will serve up unauthenticated. Then these objects would need to be imported. This is a very soft barrier to poke at since Mastodon already has code dedicated to processing posts from other instances, just not anything specific to migration.
> (and likely never will) it’s just not going to happen.
Mastodon also "likely never would" support quote posts not that long ago, and yet I see quote posts all the time, and can quote post myself as well.
There are multiple forks of Mastodon, and many other pieces of Fediverse software, and if/when the demand is significant enough people will sooner or later make this happen. To make it more concrete, my girlfriend is involved in setting up a service running various Fediverse software, and I can guarantee you from first hand knowledge that it will at some point add support for migrating posts to Mastodon whether or not the core devs want to. No protocol changes required, and in fact most of the work can be done outside of Mastodon entirely with only minor tweaks to Mastodon itself. Have you looked at the code? I have.
> This isn’t even getting in to the logistics of redirecting replies and likes/boosts.
You don't need to. You're unnecessarily overcomplicating things. You can obtain those when doing an import, and you can accept that either the original server will redirect them, or it won't. Currently they won't. It's not by any means a disaster if new boosts or replies for an old post using the original actor URI disappears into the ether - what matters by far the most to people is that they are still there in their timelines. Frankly, I'd be willing to bet - it certainly applies for my old posts from before I moved to my own instance - that to most people it's irrelevant whether the posts are accessible via ActivityPub at all, as long as they're still visible in their timeline on the web.
They've in the past raised some concerns about what it means that an old post re-surfaces on a new URL, signed by an old instance and it does make sense to do some thinking about exactly how to handle that. One option is to have the instance sign it, and drop the old actor id etc. from it, but then it will seem like it's originated from that instance to anyone who pulls it. So it's just a little bit of a hassle to work through the edge cases.
That Bluesky in theory supports it is pretty irrelevant until they open up federation.