There are no instances in ATProto — and that changes everything

What happened

Dan Abramov — yes, the React co-author who has spent the last year quietly rebuilding his mental models from first principles — published 'There Are No Instances in ATProto' to overreacted.io. It hit 411 on Hacker News within hours, with the comment thread doing what HN threads on protocols always do: half the room arguing definitions, the other half conceding the point three replies deep.

The piece is a direct shot at the most common misconception about Bluesky's underlying protocol: that ATProto is 'like Mastodon but with a different logo.' Abramov's claim is that ATProto isn't federated in the way Mastodon is federated — it behaves more like a single global database where the storage layer happens to be sharded across many physical hosts.

The key components, stripped to their primitives: a DID (decentralized identifier) is your portable identity. A PDS (Personal Data Server) is just a host that stores your repository of signed records — posts, likes, follows. A relay firehoses every public record from every PDS into a single ordered stream. An AppView (like bsky.app) indexes that firehose and renders the timeline you actually see. None of these are 'instances' in the Mastodon sense, because none of them own your identity or your social graph.

Why it matters

Mastodon's federation model has a load-bearing concept: the instance. Your handle is `@you@mastodon.social`. Move servers, and you get a new handle, broken follower links, and a migration ritual that mostly works but visibly bleeds. The instance is part of your identity, and the admin of that instance is, functionally, your landlord.

ATProto inverts this. Your DID is the identity; the PDS is just bytes-on-disk that can be picked up and moved to any other PDS without anyone noticing, including your followers. The signed records in your repository are content-addressed and cryptographically verifiable, so a relay doesn't care which PDS served them — only that the signatures check out. The AppView doesn't care either. It's reading the firehose, not polling your server.

This is why Abramov reaches for the database metaphor. In a sharded SQL cluster, you don't say 'I'm on shard 7.' You say 'my row lives on shard 7 today,' and tomorrow it might live on shard 12, and the application layer doesn't care because the primary key is stable. ATProto's primary key is your DID. The PDS is the shard. Migration in ATProto is closer to a database resharding operation than to the Mastodon migration ritual of asking 8,000 people to re-follow you.

The HN thread surfaced the standard objections, and they're worth taking seriously. Objection one: 'If there's one firehose, that's centralization.' Partially true — today, Bluesky PBC runs the dominant relay, and running your own relay is expensive (the full firehose is hundreds of GB and growing). But the protocol permits multiple relays; the cost is an engineering problem, not a protocol one. Objection two: 'DIDs resolve via a centralized PLC directory.' Also true today — `did:plc` is operated by Bluesky PBC. The protocol also supports `did:web`, which puts resolution in DNS. The escape hatch exists; almost nobody uses it yet.

Objection three, the spicy one: 'If the AppView is what users actually see, and everyone uses bsky.app, then bsky.app *is* the network.' This is the argument that ATProto's decentralization is theoretical — that in practice, the application layer is where moderation, ranking, and reach get decided, and there's only one AppView anyone uses. Abramov's implicit response is the one most architects miss: the value of credible exit isn't that everyone leaves, it's that the threat of leaving constrains the incumbent's behavior in ways Mastodon's instance model demonstrably cannot.

What this means for your stack

If you're building on ATProto, the mental model matters more than the API surface. Stop modeling users as `(instance, username)` tuples. Model them as DIDs, with a current PDS that's a cache hint, not an identity. The protocol's promise is that any client, indexer, or AppView you build can ingest the firehose and produce its own view of the network without coordinating with anyone, including Bluesky PBC. That's the part worth designing around.

For identity-bearing apps: if you're issuing capabilities tied to a user, tie them to the DID, not the handle. Handles are mutable (they're just DNS-backed aliases that point to a DID). A user can move `@alice.example.com` to `@alice.bsky.social` and back, and the DID is unchanged. Code that keys off handles will silently break; code that keys off DIDs won't.

For infra people thinking about running their own piece of the stack: a PDS is cheap (it's mostly a signed-record store and a websocket). A relay is expensive and getting more so. An AppView is the highest-leverage thing to build because it's where product opinion lives — algorithmic timelines, custom feeds, niche communities — and the protocol explicitly invites third parties to build them. The Bluesky team has been clear that AppView diversity is the win condition for the network.

Looking ahead

The Abramov framing — 'no instances, one logical database' — is going to seep into how people teach ATProto, and that's mostly good. It clears away a category error that has poisoned every Bluesky-vs-Mastodon debate for two years. The honest test of the architecture isn't whether the diagrams look decentralized; it's whether a credible alternative AppView ever ships and survives. Until then, ATProto is a federated protocol with one dominant operator — which is exactly what its critics say, and exactly what its defenders concede, and exactly the state every interesting protocol has been in at this stage of its life.