Skyvew – View and share Bluesky threads without needing a Bluesky account

Hence why I went on to write:

> 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.

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.