Notes From a Mastodon Migration
I changed servers on Mastodon last week and I learned a lot and I have opinions.
To begin with, the best time to move from one home server to another (“migrate instances”) on Mastodon is never. The second-best time is as soon as possible, because the longer you wait, the more you stand to lose. But until you’ve been on Mastodon for a while, you aren’t going to know how well you get along with your server’s mod policy and administrators, and how your server’s reputation will affect your experience. It’s not ideal! But it’s what we have right now.
As a freshly moved person, here’s what I’ve learned, what I wish I’d known in advance, and what I hope the makers of federated systems will change. (But first, thank you to all the friends and strangers who advised me on my choice of new server. You-all are great.)
what you can move
If both your old and new home servers are running the most up-to-date version of Mastodon, you will probably be able to automatically bring over your followers and manually export and then upload your following lists, mutes and blocks, and bookmarks.
You’ll manage all of the above by exporting data from your current account, creating a new account on a new server, and then following a short but slightly hair-raising series of steps to move everything over. I very highly recommend using Nuztalgia’s excellent server migration guide to help you through this process.
what you can’t move
Most guidance on moving servers includes a few warnings about what won’t move, but leave out lots more, I think mostly because they seem too obvious to mention if you’ve already internalized the Mastodon way. I don’t think they’re too obvious to mention, and some of them surprised me very much despite my many, many years in tech.
Here’s my best crack at a list:
- Your username: Your old one will no longer work, and your old profile will link to your new one.
- All notifications associated with your old account: If people reply to your old threads, you won’t know it unless you open those threads and look for new replies with your eyeballs. If people mention your old username in new posts, you won’t see those, and they won’t get any notifications that they’re mentioning a decommissioned account, so there can be whole conversations in which people think they’re engaging with you that you never see.
- Your posts: On Mastodon, when you move, you leave your old posts behind at their original URLs. (This isn’t true with all fediverse software—the promising but still small Calckey/Firefish can port in posts from old accounts.) You can export them to a local archive, but you can’t upload them to your new server. But—warning klaxon—when you export your posts, you’re literally ONLY GETTING YOUR OWN POSTS. Which means that you will never again have access to…
- Your inbound (pseudo-)DMs and follow-locked replies: The local archive you export from your old account will not include anything people sent to you. This makes perfect sense to plenty of software developers—so much that it’s not mentioned in any of the migration docs I’ve seen—but seems to me like a massive oversight that implies a deeply peculiar understanding of what sociability and conversations are. (It may be that if you go in and bookmark your incoming messages, they show up in your bookmarks in your export, but I haven’t tested this, and it would still break the integrity of your conversations.)
- Your followers’ lists: If any of your followers made a list (like “people I follow who post flowers” or whatever) and put you on it, you won’t be on it after you move. (Your old dead username will be. Your new live username won’t.) I know this only because someone who follows me noticed I’d gone missing from a list.
So…yes, you can move your account. The process isn’t that difficult. But even if it works well, which it doesn’t always, you lose a lot—more than I think is reasonable to ask of people who just want to hang out with their friends.
why this matters
If it weren’t so difficult to understand how to choose a server to begin with, the downsides of migration would sting less, but it is so hard to know if you’ve found the right (for many varied values of right) server until you’re already settled in—by which time you’ve built up posts and conversations you may not be delighted to lose.
Mastodon-the-company recently tried to partially solve this by nudging new people to Mastodon.social, the big server they run, but that big server is blocked by many small servers, and has a reputation for being middling on moderation, though I think that’s been improving. But this plan rests on the idea that people can get accustomed to Mastodon on Mastodon.social and then migrate to a place they like better. Which makes sense, because migration is at the center of what Mastodon promises.
The biggest selling point of federated networks like Mastodon and the broader fediverse—and, soon, Bluesky!—is that if you don’t like the way your instance is being run, you can move your account without the huge penalty of starting over. Theoretically, this means that unlike Twitter or Facebook or Instagram (or Post or Cohost or…) accounts, Mastodon accounts are much less vulnerable to the predations of negligent corporations, billionaires with bad personalities, and server admins who decide to incorporate invasive surveillance and ad technologies.
In practice, this means you’re trading being vulnerable to the whims of centralized corporate services and rich weirdos for…being vulnerable to the whims of whatever rando spins up a server, unless migration is speedy, comprehensive, and safe. That’s why it matters that migration is both clunky and surprisingly lossy.
where to, then?
Getting account portability right—in the technical architecture sense—is a heated topic across both fediverse/ActivityPub and Bluesky/AT Protocol conversations. Rather than weighing in on anyone’s shouty GitHub issues, I’m posting here—both because I’m not immersed in the protocol-level work and because I think the various system-specific conversations needs cross-currents.
Here are some human/cultural things I hope orgs working on federated systems will do:
- Prioritize, support, and fund both technical and non-technical (or marginally technical) but essential work to improve initial server-picking, including, in order of increasing difficulty:
- developing ultra-clear but not oversimplified guidance to help potential users understand what server choice means (for them as people, not philosophically) and how to pick one,
- collecting and publishing more—and more useful—information about servers,
- building reputation systems (yes! I mean it!) to help guide server choices, with appropriately sophisticated mechanisms for handling maladaptive behaviors and bad actors.
- Put non-dev users through any proposed or existing migration process, take notes, and fix the gaps that this process reveals. For any temporarily unfixable gaps, build in high-viz unmissable documentation and warnings. (Major and permanently unfixable gaps suggest that the underlying technology isn’t there yet.)
- Clearly and officially document the whole migration process, including what you can keep and what you will lose. (I thought before migration that this was done already but after going through the process, it seems clear that the docs are still in the fetal stage.) Use multiple formats! Make a video.
- Most of all: Approach the concepts of “identity,” “conversation,” and “portability,” as cultural patterns that bring with them expectations and assumptions from the whole of your users’ online and offline experience, and build/fix your technical approaches accordingly.
daydreaming
Here’s my reward for writing up the above: Imagine orienting new federation-curious people by offering them a tour of the positive benefits federated systems offer—so not “billionaires can’t take it away” or “ad companies can’t surveil you,” but…
Constellations of trusted, independent, stable, thoughtfully moderated communities that integrate with each other and offer distinctive moderation and curation to meet widely varying needs. Places for people who want to swim in the firehose, places for people who want a gentle sanctuary, and places for people who need to move between those modes.
Easy, reassuring ways to find your way to a home server by signalling what kind of experience you want from a social network and getting back vetted choices that meet your needs and are ready to welcome you in—or drop you into the shitposting lava, if that’s what you’re after.
Portability and migration processes that maintain your connections and conversations (without requiring you to become your own IT department or tying you to data-hosting services that sell your information) when you choose to move within a system.
Easy, subscribable, transparent moderation options that allow you to layer in your own preferences on top of your chosen server’s, so you can tweak your experience as needed.
If you’re watching conversations around ActivityPub and AT Protocol, you’ll know that there are significant tensions about the trade-offs required to build or refit systems to achieve these kinds of ideals. I think it’s going to take (more) years of effort to get federated systems to any of those states, and the techno-cultural work required to get there will be difficult, dizzyingly complex, and controversial, and I doubt any system will get it all right.
But my hope—and the reason I’m writing this stuff—is that as more systems and platforms come online outside the biggest central services, we’ll be able to learn from each other in moving toward better adaptation to human needs.