A look at how Bluesky works. Bluesky runs on the AT Protocol, an attempt to do what Twitter never did: separate the social graph from any single company’s hosting. The architecture has three layers (PDS, Relay, App View), and the bet is that users own their identity (via decentralized identifiers) and can move hosting without losing their follower graph.
How Bluesky Works: The problem at scale
The fundamental problem with centralized social platforms is that users don’t own their identity or their data: Twitter owns your account, your follower graph, your tweets, and your history. If Twitter bans you, you lose everything. If you want to leave for a competitor, you start from zero. The AT Protocol’s architectural answer is to split the platform into independent layers and let users hold their own identity keys, so hosting can change without losing the social graph.
The core architecture
Three layers. PDS (Personal Data Server) is where a user’s posts, follows, and profile live, but it’s just hosting. The user’s identity (a DID, decentralized identifier) is a cryptographic key the user controls. A user can move from one PDS to another and their DID, follower graph, and post history come with them. Relay is the global firehose: it crawls every PDS in the network, aggregates all events (posts, likes, follows) into a single ordered stream, and broadcasts it to anyone who wants to subscribe. App View is the indexer: it consumes the relay’s firehose, builds whatever indexes it needs (a timeline, a search index, a recommendation feed), and serves those indexes to readers. App Views can be Bluesky’s own, or third-party.
Why three layers instead of one
Each layer has different scale and trust characteristics. PDS scales with the number of users (you need one PDS per ~10,000 users, each cheap). Relay scales with global write throughput (a single relay can serve the whole network if writes are bounded). App View scales with read patterns (heavy compute for indexes, expensive to operate, competitive differentiation). Splitting them lets the market optimize each layer independently: small PDS providers compete on hosting reliability, large relay operators compete on throughput, App Views compete on ranking quality. This is the exact opposite of Twitter’s monolithic stack.
Identity is the cryptographic primitive
Every Bluesky user has a DID (W3C-standard decentralized identifier) backed by a cryptographic keypair. The DID document, hosted at a DID resolver, points to the user’s current PDS. When you post, your PDS signs the post with your key. When a relay or App View sees the post, it verifies the signature against your DID: if your key didn’t sign it, it’s not really yours. This means moving PDSes is a pure data migration: copy your signed posts to a new host, update your DID document to point at the new host, and you’re done. The signatures on old posts still verify because the key didn’t change.
The one non-obvious insight
The Relay layer is intentionally dumb. It doesn’t rank, doesn’t filter, doesn’t decide what’s trending. It just aggregates everything and broadcasts. The intelligence lives in App Views, which are independently operable. If you don’t like Bluesky’s official App View (its ranking, its moderation), you can use a different one without leaving the network: your posts, follows, and followers all still work because they live in the lower layers. This is the architectural precondition for “competitive ranking” : the idea that moderation and ranking become a market, not a single company’s policy.
The bet hasn’t been proven at Twitter-scale yet (Bluesky’s relay handles ~30 million users comfortably as of 2026), but the architecture is the only serious attempt to solve the social-graph-portability problem that’s been on the table since the Mastodon/ActivityPub era.
Bluesky’s AT Protocol is a three-layer architecture (PDS / Relay / App View) where users hold their own cryptographic identity. The split lets hosting, firehose aggregation, and ranking each be operated independently: the architectural precondition for a portable social graph.