and be diligent about testing migrate-away scenarios

I think this is the most important thing, and sadly, it’s not addressed very well by the current fediverse platforms (e.g. Mastodon, Lemmy, Kbin) because it is indeed a difficult problem to solve.

I’m aware that Mastodon has an account migration scheme, detailed here: https://docs.joinmastodon.org/user/moving/ . However, it’s kind of clunky. It involves making a new account, then posting a redirect notice and optionally a “move” event that will automatically make your followers (if they have a compatible client/platform) unfollow the old account and follow the new account. There’s no mechanism to move posts.

Lemmy has no migration feature whatsoever as far as I know.

Email has no migration feature.

A common anti-feature of all of these platforms is that your instance owns your identity. If you want to change instances, you need to create a new identity and try to inform the world of the change somehow. Even integrating tools to make the “informing the world” part easier, like Mastodon, does not solve the underlying problem. If your instance suddenly goes offline, your identity goes with it. Your identity can be “held hostage” by the instance admins. Your access can be arbitrarily revoked by the instance admins. Your account security is entirely outside your control.

That’s the core problem here: your identity is controlled by a third party, not by you. If the instance bans you, shuts down, or is compromised, you lose access to your identity entirely.

OAuth can help with some of this by decoupling the identity from the application/instance, but then you are still at the mercy of your identity provider (IdP). You still do not own your identity.

So what’s the solution? Honestly, I don’t know enough about cryptography to say. Cryptography is hard. But I feel like a distributed web of trust using public/private key pairs a la GPG should be viable if you build a robust protocol around it. Instead of your canonical ID being user@instance, it would be a public key, which would then be signed by any instances you choose, according to each instance’s own rules. A public key could be associated with any number of human-friendly names (e.g. user@instance1, user@instance2, etc.) which would all map back to the same public key in a distributed account database. Since only YOU control the private key, you could maintain your identity even if your instance unexpectedly went offline, and you could proactively build trust across a wide variety of instances to minimize that impact. If an instance goes rogue and de-validates users willy-nilly, other instances will be able to see that and adjust their trust accordingly.

I look forward to someone smarter than me telling me why that’s stupid. :)