ActivityPub spread across thousands of servers. AT Protocol asks a different question: what if your identity and data never belonged to the server in the first place?
A Different Starting Point
When Mastodon and the broader Fediverse adopted ActivityPub as their common protocol, they accepted a particular bargain: your account lives on a specific server, and moving it requires the cooperation of that server's administrator. Followers can be migrated, but posts largely cannot — they stay behind when you leave. For a standard designed to enable decentralisation, this is a significant constraint.
Bluesky Social, incorporated in Delaware and initially funded by Twitter, took a different architectural stance when it published the AT Protocol specification. The protocol separates three things that centralised platforms and even ActivityPub typically bundle together: your identity, your data, and the application layer that reads it.
Identity Anchored to a Key, Not a Server
AT Protocol uses a system of Decentralised Identifiers — DIDs — to establish identity. A DID is a string that resolves independently of any particular server, pointing instead to a document that records a user's public key and the location of their Personal Data Server (PDS). The specific method Bluesky uses, did:plc, is managed by a directory that Bluesky currently operates, which is a point of genuine contention: critics note that a centralised directory introduces a single point of control even inside a supposedly decentralised architecture.
From the record
How the pieces fit together
- DIDa Decentralised Identifier that resolves a user's identity without reference to a specific server; used by AT Protocol to anchor accounts
- PDS (Personal Data Server)the host that stores a user's repository of signed records; can be self-hosted or third-party
- Repositorya Merkle-tree data structure holding all of a user's content; designed to be exported and imported whole
- Relayan AT Protocol component that aggregates the public firehose from all PDS instances and rebroadcasts it
- AppViewan application layer that reads from a Relay to build a user-facing interface; Bluesky's own social app is one instance
- Feed Generatoran independent service that filters or ranks the firehose to produce a custom feed
The portability comparison
- ActivityPub: identity tied to a server instance; posts cannot reliably follow a user during a migration
- AT Protocol: identity anchored to a DID; repository is signed and portable; account survives a host change without losing history
- Gap as of early 2025: Relay infrastructure still substantially centralised at Bluesky Social despite open PDS hosting
A second method, did:web, allows a domain name to serve as a DID, which is also how AT Protocol handles human-readable handles — an account can use a domain they control as their username, cryptographically bound to their DID. This is substantively different from ActivityPub's @user@instance model, where the instance is load-bearing and irreplaceable.
The Personal Data Server is where a user's posts, likes, and follows are stored as a signed data structure called a repository — essentially a Merkle tree of records that can be verified for integrity and, crucially, exported whole. If a hosting provider shuts down or a user wants to leave, the repository travels with them. A new PDS imports the repository, retains the same DID, and connections — in theory — follow automatically. The account does not start over.
The Relay, the AppView, and the Feed Generator
AT Protocol's architecture adds three further components that have no direct analogue in ActivityPub. A Relay aggregates the firehose of all public data from across PDS instances and rebroadcasts it. An AppView is an application that reads from the Relay and builds the interface a user sees — Bluesky the social application is one AppView, but the protocol explicitly anticipates others. Feed Generators are independent services that apply their own ranking or filtering logic to the firehose and surface a custom feed within any conforming AppView.
This layering is a deliberate attempt to separate content from distribution from display, and it has real implications for portability. A user's data being legible to any conforming AppView means that switching clients or even social applications does not require abandoning accumulated social graphs or content history.
A user's data being legible to any conforming AppView means that switching clients or even social applications does not require abandoning accumulated social graphs or content history.
Federation in Early 2025
As of early 2025, Bluesky had opened the ability for third parties to run their own PDS instances, and independent deployments were appearing — but the Relay infrastructure remained substantially operated by Bluesky Social itself. Full federation, in which multiple independent Relays could exchange data without Bluesky at the centre, was not yet in production. The AT Protocol's own roadmap documentation acknowledged this gap explicitly, framing the current state as a first phase with relay federation as a subsequent step.
This is the meaningful contrast with ActivityPub, which shipped as a W3C Recommendation in January 2018 into a Fediverse that was already federating across independent servers. AT Protocol's portability guarantees are architecturally stronger on paper — data is owned, signed, and portable by design — but the network's actual decentralisation in early 2025 lagged behind what the specification implies. Whether the infrastructure catches up to the architecture is the open question the protocol's adoption will eventually answer.
