Most people who’ve heard of AT Protocol think it’s “the thing Bluesky is built on.” Technically true. Practically misleading — the same way calling HTTP “the thing Chrome is built on” misses the point.

I spent a while going deep on the actual spec, the reference implementations, and what’s shipped on top of it, because decentralized infrastructure is a topic I keep coming back to. What I found is a genuinely reusable identity-and-data substrate with a small, real ecosystem of production apps that have nothing to do with microblogging — event platforms, blogging, forums, messaging, feed marketplaces. This post is the high-level map: architecture, topology, what’s already live beyond Bluesky, and where I’d point you to go deeper.

The one sentence that explains all of it

AT Protocol’s own docs state the thesis plainly: “Users publish JSON records into repositories. The changestreams of those records then sync across the network to drive applications.”

That’s the whole model. You own a repository of signed records. Records sync as a stream of changes. Any application, including ones that didn’t exist when you wrote the record, can read that stream and build something on top of it. Bluesky is one application. It is not a special one at the protocol level.

Where this design actually comes from

The clearest explanation isn’t a decentralization manifesto — it’s an engineering post aimed at distributed-systems people. It frames AT Protocol as a familiar internal scaling pattern, turned inside out:

  1. Start with one strongly-consistent database. It becomes the bottleneck.
  2. Relax to eventual consistency for write scale.
  3. Poor query flexibility gets solved with view servers — precomputed, cache-like read models.
  4. View servers miss updates on crash, so you add an event log they replay from — a Kappa architecture.

Every large company that scales a product ends up here internally. AT Protocol’s move is to externalize each internal component into something anyone can run an independent instance of:

Internal pattern AT Protocol equivalent
Sharded NoSQL store User repositories (signed, per-account)
Kafka-style event log The firehose
View servers AppViews
Internal addressing AT-URI
Trusted internal network Cryptographic signing (components now talk over the open internet)

The harder part: unlike a single company’s internal pipeline, this isn’t single-writer. Every user’s server is generating events, and many independent apps are consuming and writing to them. It’s the same architecture pattern, but multi-tenant by design — which is also why identity has to be cryptographic rather than “whichever database row you’re in.”

The founding engineers came out of IPFS/Dat, and Martin Kleppmann (Designing Data-Intensive Applications) is an active advisor — which tracks with the “no steps backwards” design principle: the network has to feel as convenient as a centralized app while staying open. That principle is the stated reason they rejected both classic federation and blockchain approaches — both hit scaling walls the Kappa-architecture pattern was specifically designed to avoid.

The topology, in one diagram

User PDS
  │
  ├─▶ Relay ─▶ Jetstream ─▶ bots / feeds / labelers
  │      │
  │      └─▶ AppView ─▶ third-party client
  │
  ├─▶ third-party client   (OAuth + writes)
  └─▶ did:plc directory    (resolves DID)
  • PDS (Personal Data Server) — your account’s home. Hosts your data, manages identity, handles OAuth. Deliberately kept “dumb”: generic storage and account management only, no app-specific logic. The stated reason: app-specific logic on the PDS would warp incentives toward vendor lock-in.
  • Relay — subscribes to many PDS firehoses and re-broadcasts one combined stream. It does not interpret what’s in the records — it just stores and forwards.
  • AppView — the semantically-aware layer. It’s what assembles a feed, computes counts, and powers search. This is the protocol’s analogue to the “view server” from the scaling story above.
  • Jetstream — a lightweight, JSON-only simplification of the raw firehose, built because parsing raw CBOR/Merkle-tree diffs is genuinely hard for a small team. It’s also, notably, a centralization point: most of the “independent” ecosystem is one hop downstream of Bluesky’s own relay and Jetstream infrastructure, not running a full firehose consumer themselves.
  • Feed generators — independent services that return a ranked list of post URIs. No hydration, no data ownership — just ranking logic, callable by anyone’s client.
  • Labelers / moderation — signed metadata distributed outside the main record stream. Any account can run one; clients opt into whichever labelers they trust.

Identity rides on top of all of it: every account has a permanent, cryptographic DID and a mutable, human-readable handle (literally a DNS hostname) that points to it. Your data is a repository — a signed Merkle tree of records — that you can export as a portable file and move to a different host without losing your identity or your history. That portability is the actual value proposition, more than any specific app feature.

The honest tradeoff: “lazy trust,” not zero trust

AT Protocol doesn’t claim to be peer-to-peer trustless, and it’s upfront about that. The design ethos calls it lazy trust: a deliberate middle point between full implicit web trust and full trustlessness. Clients don’t re-verify every signature on every read — that would be slow — but because your canonical data is always exportable, you retain the option to verify or migrate away from a misbehaving host. The term of art is credible exit, not decentralization-as-purity.

That framing matters when you look at where the real centralization pressure still sits: the did:plc identity directory is a single production service almost everything depends on for identity resolution, and it’s the most-cited critique of the whole design (more on that below). The protocol’s answer isn’t “that’s not a problem,” it’s “here’s the mechanism that lets you leave if it becomes one.”

What’s already running beyond Bluesky

This is the part that surprised me. There’s a real, shipping ecosystem that reuses AT Protocol’s identity and sync layer — com.atproto.* — while defining entirely custom record schemas (Lexicons) for what’s actually new. Almost none of it looks like a social feed.

Category What’s live What it adds
Events Smoke Signal Event discovery and RSVPs as signed records — an Eventbrite/Meetup analog with a custom Lexicon
Forums / link aggregation Frontpage Hacker News–style aggregation and voting, portable across clients
Publishing WhiteWind, Leaflet Markdown blogging and newsletter/doc publishing, stored in your repo, not the app’s database
Photo/video Flashes, Streamplace Instagram-style sharing and independent livestreaming infrastructure
Messaging Germ, Roomy MLS-based end-to-end encryption and P2P/CRDT group chat, both shipped ahead of any official DM spec
Feeds & discovery Graze, SkyFeed, Surf No-code custom feed builders and a Flipboard-built cross-network reader spanning Mastodon, AT Protocol, and RSS
Reputation & infra Cred.blue, Microcosm / Constellation Account reputation scoring, and a self-hostable backlink index across the entire network’s records
Other niches Rocksky (Last.fm analog), Popfeed (Letterboxd/Goodreads analog), Woosh (Linktree analog) Proof that this is a generic record store, not a microblogging SDK

Two things stand out across that list. First, almost none of these run their own full-network relay or AppView — they lean on Bluesky’s infrastructure for sync and hydration even while being fully independent products. Second, WhiteWind’s own framing of its value prop is the cleanest statement I’ve seen of why this matters: the app itself has no power to modify, hide, or delete your data, because your posts live as plain signed records in your own repository. The app can shut down tomorrow and your writing doesn’t disappear with it — a genuinely different failure mode than a normal SaaS shutdown.

Also worth naming: Blacksky runs an entirely independent stack — its own PDS, relay, AppView, and moderation team, written in Rust — that interoperates with Bluesky’s network without depending on Bluesky’s servers. It’s the clearest existing proof that “anyone can run the full stack” isn’t just a whitepaper claim.

What I’d actually build on this

Set aside “another Bluesky client.” The interesting angle is: what needs portable identity plus a public, syncable event log that doesn’t have it today?

  • Vertical review/reputation products where users own their history. Popfeed and Rocksky are already proving this pattern for movies and music — a decentralized-first alternative to any app whose entire moat is “your ratings are trapped here.”
  • A backlink or provenance index for a specific domain, the way Constellation does it generally — cite counts, reply graphs, citation chains, but scoped to one niche where nobody’s built it (research papers, open-source contributions, product reviews).
  • A feed marketplace, which Graze is already monetizing — algorithmic ranking as a product, sold independently of the app that renders it, because feed generation and content storage are decoupled at the protocol level.
  • Moderation as a standalone service. Labels are signed, distributed independent of the record stream, and opt-in per client — you could build a moderation product that any AT Protocol app subscribes to, the way Ozone works for Bluesky today, without building an app around it.
  • Migration-proof publishing, which is exactly WhiteWind and Leaflet’s bet: if your business model doesn’t depend on holding your users’ data hostage, “we might shut down” stops being an existential threat to the people who wrote content on your platform.

The common thread: none of these need Bluesky’s app to exist. They need the identity layer, the sync layer, and a schema.

Where it’s still thin

I’d be doing this topic a disservice if I didn’t name the gaps plainly, because the protocol’s own docs do:

  • No end-to-end encrypted DMs at the protocol level yet. Permissioned/shared data is the stated prerequisite, and it’s the actual focus of 2026’s roadmap. Germ DM shipped E2EE off-protocol in the meantime — exactly the “community builds ahead of spec” pattern Bluesky’s own roadmap posts predicted.
  • No decentralized full-text search primitive. Search is an AppView feature today, which means it’s centralized by construction, not by accident.
  • Identity resolution has a real single point of dependency: the did:plc directory. This is the sharpest, most-cited critique of the whole design — Christine Lemmer-Webber’s “How decentralized is Bluesky really?” calls did:plc “the single most centralized and not easily replaceable element of the protocol.” Her core argument is architectural: AT Protocol’s relay is a shared heap everyone dumps into and queries from a common store, versus ActivityPub’s message-passing model — more centralizing by default, even if genuinely more open than a walled-garden app. Bluesky’s response has been concrete, not dismissive: the PLC directory spun out into an independent Swiss Association in September 2025, and the core spec was submitted to the IETF the same month, with an approved working group as of 2026. Neither transition is finished. Both are real.
  • Video and full-network relay hosting remain resource-intensive enough that almost nobody but Bluesky runs them at network scale, even though the protocol imposes no such requirement.

None of that is a reason to dismiss the architecture. It’s a reason to be precise about what “decentralized” is currently buying you: portable identity and exportable data, today; full infrastructure independence, only partially, and unevenly across layers.

If you want to go deeper

I compiled and verified all of these while researching this post — they’re the sources I’d point you at first:

Start here

  • atproto.com — the protocol’s own site, relaunched in 2026 with docs framed around general use cases rather than Bluesky onboarding
  • Atproto for Distributed Systems Engineers — the single best explanation of why the architecture looks the way it does
  • Atproto Ethos — the four design commitments (identity-based authority, generic hosting, opinionated structure, lazy trust)
  • Statusphere tutorial — the official “hello world”: OAuth sign-in, one custom Lexicon, firehose listening, ported by the community into half a dozen languages

Build something

Read the critiques, not just the pitch

See it in production, beyond Bluesky

  • WhiteWind, Frontpage, and Smoke Signal are the fastest way to feel the “your data outlives the app” property firsthand, rather than reading about it

I keep landing on the same conclusion whenever I dig into decentralized infrastructure: the interesting engineering is rarely the ideology, it’s the specific tradeoffs a team made to get eventual consistency and real-world scale out of a system nobody centrally controls. AT Protocol made its tradeoffs in the open, wrote them down, and let a small but real ecosystem prove the substrate works for more than one app. That’s worth understanding on its own terms, whether or not you ever open Bluesky.

Thoughts, corrections, or things I got wrong? Find me on X/Twitter @mikezupper or drop a note at [email protected].