Why Bluesky Accounts Can Migrate Between Servers While Mastodon Accounts Cannot

When a decentralized social network scales past 10 million registered users—the threshold Bluesky crossed in late 2024—the infrastructure holding their data usually becomes a permanent trap. Measured on the basis of a digital population, 10 million people is the size of a small country. In traditional web architecture, moving that population requires the host's explicit permission. If the server shuts down, the identity ceases to exist. Both the AT Protocol and ActivityPub market themselves as 'decentralized' solutions to this lock-in, promising users control over their social graphs. But the marketing language obscures a structural divergence in how the two systems actually route data.[4][6]

ActivityPub, the protocol finalized by the W3C Social Working Group in January 2018, powers federated platforms like Mastodon and Pixelfed. It operates on a document-passing model. When a user publishes a post, their server encodes it as a JSON-LD document and pushes it to the inboxes of their followers on remote servers. It is a highly effective mechanism for cross-server communication, but it binds the user's identity entirely to the host domain.[1][5]

Under ActivityPub, an identity is resolved using WebFinger, formatted as `acct:username@host.com`. Because the domain name is the root of the identity, the user does not cryptographically own their account; the server administrator does. If a remote application queries a server for an account that has been disabled or moved without a redirect, the endpoint simply returns a 405 Method Not Allowed or a 400 error, severing the connection entirely. There is no native mechanism to merge or synchronize follow lists across servers.[1][2]

If an ActivityPub user wants to move to a new server, they must use a 'Move' activity. This requires the old server to remain online and cooperative, placing a redirect notice on the original profile. If the original server burns down, goes bankrupt, or the administrator turns hostile, the identity is permanently destroyed. The user must start over from zero on a new domain.[2][5]

The AT Protocol approaches the problem by separating the cryptographic identity from the physical data hosting. Instead of a domain-bound address, an AT Protocol user is identified by a Decentralized Identifier (DID). This DID acts as a directory of cryptographic keys, completely independent of where the user's files actually live.[3]

The physical hosting is handled by a Personal Data Server (PDS). The PDS stores the user's primary data—posts, likes, and follows—in a Content Addressable aRchive (CAR) file, typically capped around 50MB for heavy users. If the PDS goes offline, the user's identity remains intact because the DID is stored on a separate registry. The official AT Protocol documentation states the objective explicitly: 'The goal of the AT Protocol is to ensure that a user can migrate their account to a new PDS without the server's involvement.'[3][4]

To execute an adversarial migration—moving data when the old host is dead or uncooperative—the user relies on a rotation key. This is a cryptographic master key that asserts changes to the DID document. The user signs a new DID document pointing to their new PDS, uploads their backed-up CAR file, and the network updates their location. The old server is entirely bypassed.[3]

However, the shipped reality currently falls short of the architectural capability. While the protocol supports user-controlled rotation keys—stored on a hardware device or paper backup—most Bluesky users do not actually hold them. For operational convenience, Bluesky Social PBC manages the rotation keys for the vast majority of its 10 million users. The capability for unilateral migration exists in the code, but the practical execution remains centralized until users take custody of their own keys.[3][6]

The AT Protocol also trades server independence for network-wide scalability. Rather than pushing documents directly between servers like ActivityPub, AT Protocol uses a crawler service to pull records from every PDS and stream them over WebSockets to massive index servers, known as Relays. These Relays aggregate the entire network's activity into a single firehose.[4][6]

Maintaining that firehose requires substantial resources. When the network had 6 million users in mid-2024, maintaining a real-time copy of all user repositories on a single server cost roughly $153 per month. That figure covered only inbound bandwidth and storage, excluding the computational power required to build and serve summary indexes.[6]

This architecture means that while anyone can host a PDS on a cheap virtual private server, running a Relay is an enterprise-scale operation. ActivityPub distributes the computational load evenly across the network, prioritizing true decentralization at the cost of global search and discovery. AT Protocol centralizes the indexing layer to enable global features, prioritizing user experience and account portability.[1][4]

The technical divergence defines the future of both networks. ActivityPub ensures that small communities can run entirely independent infrastructure, but forces users to trust their server administrators with their digital identities. The AT Protocol mathematically guarantees that users can fire their hosting providers, provided they take custody of their rotation keys, while relying on heavy, centralized indexers to make the network usable.[3][5][6]