Account portability on the Fediverse vs. the ATmosphere
You want to leave your server. What happens to your followers, your handle, and your posts? On the Fediverse, leaving is a move. In the ATmosphere, most switching isn't a move at all. A neutral look at how each network handles account portability, and the trade-offs behind each.
A standalone piece in the Exploring the Fediverse umbrella. The Fediverse Beyond Mastodon mapped what runs on ActivityPub; the ATmosphere Beyond Bluesky series (forthcoming) maps the AT Protocol app ecosystem. This piece sits between them, on the question both raise: can you take your account and leave?
You want to leave your server. Not the whole network, just the specific machine your account lives on. Maybe the admin made a call you disagree with, maybe the instance is shutting down, maybe you've simply outgrown it. So you ask the practical question: what happens to your followers, your handle, and everything you've already posted?
The answer depends on which network you're on, and the two largest open ones answer it in structurally different ways. On the Fediverse, leaving is a move. In the ATmosphere, most of what people call "switching" isn't a move at all. Neither answer is strictly better. They trade off three things in different ways: identity continuity, content portability, and self-governance. The difference only makes sense once you see what each network fuses together and what it keeps apart.
The Fediverse model: the instance is a bundle
On the Fediverse, your instance is four things at once: the software you post through, the database that stores your content, the identity you're known by, and the moderation policy you live under. A Mastodon server such as mastodon.social (server and instance mean the same thing in fediverse usage) runs the code, holds your posts, issues your handle (@you@mastodon.social), and sets the rules. Your address is the server's address. That fusion is what makes an instance feel like a home. Because your handle and your posts are bound to the server, leaving is a migration rather than a toggle.
Mastodon does support account migration, so this is not a story about being trapped. What moves is less than most people expect, and it arrives by three different routes, which Mastodon's own documentation lays out.
One thing transfers automatically: your followers. When you trigger the move, Mastodon issues a Move activity that tells your followers' servers to unfollow the old account and refollow the new one, so your audience comes across without anyone re-following by hand. This works for followers whose server implements the Move activity. Mastodon does, and many other platforms do, though not all; followers on software that doesn't support it keep following your old, inactive account instead of moving with you.
A second set of things you carry over by hand. Your list of who you follow, your lists, your bookmarks, and your blocked accounts, muted accounts, and blocked domains don't travel through the Move activity itself. You export them from the old account (as CSV and JSON files) and import them into the new one instead. You set up your profile (display name, bio, avatar, header) again on the new account.
The rest stays behind. Your posts, your direct messages, and your uploaded media remain on the old server. You can download an archive of your posts in ActivityStreams 2.0 JSON, but Mastodon cannot import posts into a new account, so your history doesn't follow you. Your handle changes to @you@new-server, and the redirect is forward-only: the old profile shows a "moved" notice that sends visitors onward but can no longer be followed.
The mechanics add friction. You first set the old account as an alias on the new server, then trigger the move. Mastodon enforces a 30-day cooldown before you can migrate again. The follower transfer is also gradual: followers arrive over hours or days as their servers process the change.
The ATmosphere model: unbundled layers
The ATmosphere is the name for the whole ecosystem built on the AT Protocol, the system underneath Bluesky: the apps, data servers, relays, and moderation stacks that run on it. It takes the four things a Fediverse instance fuses together and separates them into independent layers.
Your identity is a DID (a decentralized identifier), a permanent string that belongs to you rather than to any server. Your handle, the human-readable name like @you.bsky.social, is a pointer to that DID resolved through DNS (or an HTTPS record on the domain), so it can change without changing who you are. Your followers follow the DID, not the server it currently resolves to.
Your data lives in a PDS (a Personal Data Server) that holds your repository, or repo: the actual record of your posts, likes, and follows. The repo is app-agnostic, so any application on the network can read and write to it.
On top of those sit the apps you post through and the moderation you choose. Moderation runs through labelers, independent services that annotate content and that you subscribe to, layered on top of the baseline moderation your app and host already enforce.
Three kinds of switching
Because those layers are independent, most switching touches only one layer and leaves the rest alone.
Switching apps is instant. Moving from the Bluesky app to Anisota or Pinksky changes the software you post through and nothing else. Your identity, your data, and your followers stay where they are, because they live in your DID and PDS, not the app. This freedom isn't unique to the ATmosphere: a Mastodon account behaves the same way with third-party clients like Ivory, Tusky, or Phanpy, which talk to your server rather than being your server.
Switching moderation is also just a subscription change. Subscribe to a different labeler or a different feed and your view of the network shifts, but nothing about your account moves.
Switching your PDS is the only one that counts as a genuine migration. Moving your repo to a new host (self-hosted, a different provider, or a community server like Blacksky) relocates your data. Even then, your identity and your follower graph stay intact, because they were never tied to the PDS. Your DID persists, your handle keeps resolving, and the people who followed the DID still follow it.
How a PDS move actually works
A PDS migration is real work rather than a tap, and the steps show why the identity survives it. They assume the cooperative case, where the old PDS is online and willing to sign off on the move. The AT Protocol defines the sequence, and Bluesky ships a command-line tool called goat that runs it. A community-built web tool, PDS MOOver, walks through the same steps in a browser for anyone who would rather not touch the command line.
First, you prove identity: the old PDS issues a service-auth token (through a call named getServiceAuth) that authorizes the move. Second, you create the account on the new PDS (createAccount), where it starts in a deactivated state. Third, you move the data: export your repo as a CAR file (Content Addressable aRchive, a single-file snapshot of your records) along with your blobs (media) and preferences, then import all of it into the new PDS. Fourth, you update your DID document (the record that says where your identity lives) through the PLC directory (the shared service that logs identity changes for did:plc accounts) so it points at the new PDS and its signing key. Fifth, you activate the new account and deactivate the old one.
Every step here counts on the old PDS cooperating. When it won't, whether you can still leave depends on who holds your rotation key.
Rotation keys and self-custody
Control over your DID comes down to rotation keys. They sit in your DID's PLC log (the public, append-only record of every change to that identity), and whoever holds a valid one can update where your DID points. That's what makes migration possible, and it's also what decides how cleanly you can leave a host that won't help you.
By default, your PDS manages both your signing key and your PLC rotation key. On a Bluesky-hosted account, that means Bluesky holds your rotation key. When the old PDS cooperates, a move is smooth: it signs the update and hands you off. When the old PDS is offline or hostile (a case sometimes called an "adversarial migration"), you can recover only if you had already added your own rotation key ahead of time.
You can add one. AT Protocol and community documentation strongly recommend it for anyone able to manage a keypair, and tools like goat provide commands to register an extra rotation key without writing raw PLC JSON by hand. With a self-controlled rotation key you can update your DID and migrate even if the old host refuses to help. For fuller independence, did:web is an alternative identity method that sidesteps PLC entirely by anchoring your DID to a domain you control. So portability here is conditional on key custody: by default the host holds the key, but taking it yourself is a choice available to you, not something the platform withholds.
Community-run stacks
The fullest version of leaving goes past moving between hosts a company runs. It means communities running the whole stack themselves, so they don't depend on Bluesky the company at any layer: their own PDS, their own relay (the service that aggregates activity across the network into a firehose other services read), and their own moderation.
Blacksky is the most developed example. Rudy Fraser started the project in 2021 and launched it in 2023, and it has grown into one of the largest Black communities on the decentralized web. Fraser's team runs every layer: their own PDS software (rsky-pds, written in Rust), their own relay (atproto.africa), and their own moderation. Reach and hosting are two different numbers. A 2025 New_Public profile put the people Blacksky's feeds reach across the ATmosphere at around two million, while the accounts actually hosted on its own PDS are far fewer. The feeds are what most people mean by Blacksky; the PDS is what makes it a place you can fully move to.
Fraser built it as a response to the anti-Black harassment Black users had long faced on mainstream platforms, on the premise that mutual aid could be infrastructure rather than only a sentiment. The infrastructure exists, and it belongs to the community that runs it.
Northsky is earlier and smaller. A worker-owned cooperative serving 2SLGBTQIA+ users and running its servers in Canada, it won the first grant from IndieSky, a fund for independent AT Protocol infrastructure. Free Our Feeds (a campaign backing independent development on the open social web) seeded IndieSky with $50,000, and IndieSky then awarded Northsky $5,000 of that. Northsky is spending it on the unglamorous part: PDS-migration tooling and plain-language guides that make moving an account accessible to people who aren't engineers.
Past Blacksky and Northsky, the projects sit at different layers and stages of maturity. Eurosky, an initiative of the Dutch nonprofit Modal, is building European-hosted infrastructure for digital sovereignty (a PDS provider, a relay, and an index), with its infrastructure coming online across 2025 and 2026. Gander is a Canadian social platform built on the protocol, sitting at the app layer rather than the infrastructure layer. Habitat is earlier still, one of the projects working on permissioned (non-public) data and data agency on the AT Protocol, rather than general-purpose account hosting. They point the same way, toward infrastructure a community or a jurisdiction controls, but the most complete version running end to end today is still Blacksky's.
The point of these projects is self-governance: a community owning the infrastructure its members' identities and data sit on, rather than renting it. The AT Protocol's unbundling is what lets them do that without leaving the network.
What's changing on the Fediverse: LOLA
On the Fediverse, your posts don't come with you to a new account today, but that's a current limit, not a permanent one. The W3C's Social Web Incubator Community Group (SWICG) runs an ActivityPub Data Portability Task Force that's drafting a specification to close it: LOLA, for Live, On-Line Account Portability. LOLA lets a destination server copy your account content out of the source server at your request. Your posts, following list, likes, and block lists are copied across, with the transfer authorized over OAuth 2.0 (the same delegated-access standard behind "sign in with" buttons).
The draft describes the flow in three phases. First, discovery and authorization: the destination server confirms the source supports LOLA, and you authenticate through OAuth so the destination receives a token to act for you. Second, fetching and saving: the destination requests your collections and recreates them as a copy in your new home. Third, finalizing: you notify your followers, set the redirect, and close the old account when you're ready.
In September 2023 the Data Transfer Initiative (a data-portability nonprofit whose backers include Apple and Google) convened a miniconference that brought fediverse developers together with people from the IndieWeb and large tech companies to work out how accounts should move. LOLA is the task force's answer, now a draft at version 0.3. No released version of Mastodon implements it yet (the stable line is 4.6.x as of mid-2026), and it's been discussed at FediForum (the fediverse community's recurring online conference), so it reads as a credible trajectory rather than a live feature. It is also not the only proposal. Cryptographic approaches such as PortaFed, a draft Fediverse Enhancement Proposal (FEP) that ties identity to keys the user holds, target the case LOLA can't reach: a source server that is offline or has banned you. Treat server-to-server copying as one likely direction for fediverse portability rather than a settled one, and none of it as shipped yet.
LOLA's design reflects the model it's bolted onto. It adds portability as a layer on top of a bundled system: a destination server copies content out of a source that was never built to release it. The AT Protocol builds portability into identity and data from the start, so there's nothing to copy out.
What each network trades away
The two networks make opposite structural choices, and each choice creates its own kind of freedom and its own kind of friction. Those choices sort into three axes: identity continuity, content portability, and self-governance.
On identity continuity, the ATmosphere leads. Your DID persists wherever your data lives, so your handle and follower graph survive a move. On the Fediverse, identity is the server's, so leaving means a new handle and a forward-only redirect.
On content portability, the Fediverse has better tooling but loses more. Its account migration has worked for years, yet your posts don't move to the new account (you can export an archive, but Mastodon can't re-import it), and LOLA is the effort to close that gap. The ATmosphere carries your repo, posts included, when you move your PDS; across networks, only the social graph travels.
On self-governance, both offer real independence with real limits. The Fediverse lets anyone run an instance, but leaving one is still a migration. The ATmosphere lets communities run the whole stack, as Blacksky does, yet its scale still centers on Bluesky's infrastructure today, and full self-custody depends on holding your own rotation key.
Which set of trade-offs suits you depends on what you're optimizing for. A reader who wants to move servers without losing their handle and followers is describing something the ATmosphere already does; the same move on the Fediverse means a new handle. A reader who wants a network already spread across thousands of independent hosts, with no company at its center, is describing the Fediverse; the ATmosphere is built that way but still leans on Bluesky's infrastructure today. Both networks say the account is yours. Letting you take all of it with you is the promise each is still working to keep.
What's next
Everything above concerns portability within a single network: Fediverse to Fediverse, atproto to atproto. Moving between the two networks is a different axis, a matter of bridging rather than migration. The Federation Across Networks series covers how Bluesky, Threads, and Nostr connect across protocols, and a planned follow-up will take on the tools that carry an account from one network to another, Bounce among them. What those tools do today is social graph portability: moving your follows and followers. Bounce, for instance, routes this through Bridgy Fed, the infrastructure that bridges ActivityPub and the AT Protocol. Content portability across protocols remains an open problem. If you've wondered whether you can move from Mastodon to Bluesky directly, that's the follow-up to watch for.
For the wider tour of each network, the Fediverse Beyond Mastodon series covers what runs on ActivityPub beyond microblogging, and the forthcoming ATmosphere Beyond Bluesky series covers the app ecosystem on the AT Protocol.
Sources and further reading
Fediverse (ActivityPub) portability
- Mastodon, Moving or leaving accounts — what transfers on an account move, and what stays behind
- Fedi.Tips, Transferring your Mastodon account to another server — practical step-by-step; confirms followers move via a separate process and follows/lists/bookmarks/blocks via CSV and JSON export-import
- SWICG, LOLA Portability for ActivityPub (0.3) — draft spec for server-to-server content portability
- Data Transfer Initiative, ActivityPub and account portability — overview of the LOLA approach
- Data Transfer Initiative, The Federated Data Transfer Miniconference: A Summary — the September 2023 event convening fediverse, IndieWeb, and industry developers on portability
- SocialHub, PortaFed: Cryptographic Account Portability for ActivityPub (FEP draft) — a cryptographic alternative to LOLA for the offline/banned case
AT Protocol portability
- AT Protocol, Account Migration — the PDS-move sequence, step by step
- PDS MOOver, ATProto tools for PDS migrations and backups — a community-built, browser-based migration tool (an accessible alternative to the
goatCLI) - Blacksky, rsky (AT Protocol implementation in Rust) — a community-run PDS, relay, and moderation stack
- New_Public, How Blacksky grew to millions of users — Rudy Fraser on Blacksky's growth and architecture
- AT Protocol Community, The First IndieSky Grant: Northsky — community-built PDS-migration tooling
- Open Future, Eurosky dawns: building infrastructure for sovereign social media — European-hosted PDS, relay, and index
- AT Protocol, Spring 2026 roadmap — permissioned (non-public) data work (Habitat and others)
Cross-network migration (the follow-up's territory)
- A New Social, Bounce: a cross-protocol migration tool
- TechCrunch, Introducing Bounce, a tool to move your following between Bluesky and Mastodon
