My idea for user-friendlier Mastodon migrations

As I wrote in this blog post, one of the problems with Mastodon (as I write this in late 2022) is that moving an account to a new server is not one-click easy, and there's no guarantee that your current server won't simply disappear before you have a chance to perform the steps (server covenants notwithstanding). Losing your connection to all the people you follow would be a big inconvenience — you'd have to find and re-follow everybody — but losing all your followers could be irreparable, especially if you're a content provider whose followers extend well beyond just friends and family. If you're a content provider, this alone might be enough to prevent you from ever commiting to Mastodon.

This is my idea for how to solve this problem. (Note: I'm nowhere near an expert in cryptography or network security, so if there are fatal flaws to my idea, please let me know.)

  1. When I sign up with a server, a public/private key pair is generated for me.
  2. Whenever someone follows me, their Mastodon server records not just my handle, but my public key.
  3. Whenever I like, I can download a migration file that I can use in the future if I ever want to migrate to a new server. This file will consist of the following information:
    • My current handle.
    • My public and private keys.
    • A list of all my followers.
    • Other account info that's not as critical as my followers list. (e.g. my preferences, my display name, my follows, etc.)
  4. If I ever want to migrate to a new server, I create the new account, then upload my migration file.
  5. My new server creates a new public/private key pair for me as usual, and sets all the non-critical parts of my profile (preferences, display name, follows, etc.) from the migration file.
    • Note: follows that required that permission be granted might need special handling similar to what I'm about to describe for the followers list. Basically, you need to bypass the permission requirement, because it's essentially already been granted, but you can use my public/private keys to secure that process.
  6. The new server then goes through the list of my followers, contacting all their servers with these three pieces of information: my old handle, my new public key, and my new handle. The last two items, my new public key and my new handle, are encrypted using my old private key.
  7. Each of those servers of my followers decrypts my new handle and public key using my old public key, which they stored back in step #2, and if and only if the decryption is successful, replaces my old handle and public key with my new ones.

As far as I can tell, this procedure is secure (but again, please let me know if you find any flaws) and has the following features:

  • It doesn't require the old server to still be running. (Unless some of my followers were on that server, but I'm not sure if any migration process, including the current one, can handle that case.)
  • It doesn't even require my old account to be closed! I've debated whether this is a feature or a bug, but I think it's a feature. It would be a problem if it allowed both accounts to keep their followers, or if a migration file could be used more than once, but neither should be possible. It does allow users to sell their followers to others, but they could just as easily sell their accounts, and it would work better for the buyer because the posts would seem to still be coming from the trusted source.
  • Even if servers that disappear without any advance warning never becomes a problem, this is just a more user-friendly way of handling migrations.

Here are some downsides I can think of:

  • The user will need to be warned to keep their migration files VERY safe. But I suspect this feature will be used mostly by tech-savvy content providers who might be more practiced at maintaining good security.
  • People might lose their migration files. So the current manual process should be kept available, not just for these users but for anyone who never bothered to download a migration file.
  • Note: the official Mastodon browser extension that I lobbied for in the associated blog post could solve both of the above problems.
  • Malicious Mastodon instances might be able to do very bad things with migration files uploaded to them by trusting users. (But maybe all or most of the harm that can be done will already have been enabled by that user simply signing up.)
  • This would open up a new attack vector which, at the very least, might tie up CPU resources a bit more on every server.
  • I don't know what my new server should do in cases where some other server (a server of someone who follows me) is temporarily down or so busy it times out during step #6 above. But I suppose that's an issue with the current process as well.

Can you think of any more potential downsides? If so, please let me know in the comments.