Abramov: ATProto has no instances — and that's the whole point

What happened

Dan Abramov — yes, the React guy, now at Bluesky — published *There Are No Instances in ATProto* on his overreacted.io blog, and it hit 146 on Hacker News inside a day. The piece is a direct, sometimes blunt response to a recurring confusion: developers coming from Mastodon keep asking which ATProto *instance* they should join, and the answer is that the question doesn't parse.

Abramov's core claim is that 'instance' isn't a missing feature in ATProto — it's a category error. In Mastodon (and the broader ActivityPub world), your identity is tied to a server: `@you@mastodon.social` is fundamentally different from `@you@hachyderm.io`. The server is part of your name. If the admin disappears or defederates, you lose your followers, your post history, and your handle. Migration tools exist, but they're a workaround layered on top of a protocol that assumed servers own users.

ATProto inverts this. Your identity is a DID (decentralized identifier) — an opaque string like `did:plc:abc123…` that points to a key the user controls. Your handle (`@danabra.mov`) is just a DNS-verified alias for the DID. The data itself — posts, follows, likes — lives in a Personal Data Server (PDS), which is essentially a cryptographically-signed repository of your records. The PDS is *a host*, not *your address*. Swap PDS providers and your DID, handle, followers, and history come with you.

Why it matters

This sounds like a semantic distinction until you trace the consequences. In Mastodon, defederation is a death sentence for an account; in ATProto, defederation is just a relay refusing to index your repo, which other relays can still do. That's because ATProto separates four things ActivityPub conflates: identity (DID), data storage (PDS), aggregation/indexing (relays), and views/feeds (App Views). Each is independently swappable, and the user can change any of them without changing their identity.

The Fediverse crowd has been arguing for years that this isn't 'real' decentralization because Bluesky PBC currently runs most of the relays and the default PDS. Abramov concedes the operational point — yes, the bills are being paid by a small number of operators today — but argues this is an infrastructure problem, not an architecture problem. A user on bsky.social can, today, point their handle at a self-hosted PDS, and nothing about their identity or social graph breaks. Try doing the equivalent migration on Mastodon and you're filing GitHub issues against a `move_account` script.

The Hacker News thread predictably split along these lines. One camp ([top comment, 89 points](https://news.ycombinator.com/)): ATProto is centralized in practice, and the 'no instances' framing is marketing gloss on a system where Bluesky PBC controls the relay infrastructure. Another camp: Mastodon's instance model is what produced the endless 'which server should I join' anxiety that capped its growth at ~1.5M MAU while Bluesky cleared 30M users. The architectural debate is now an empirical one: ATProto's design choices correlate with 20x adoption, and that's hard to dismiss as a UX accident.

What's underexplored — and where Abramov is most useful — is the developer-facing consequence. Building on Mastodon means building *for an instance*. You need to think about which server hosts your bot, what its admin's policy is, who it federates with. Building on ATProto means building *against the network*: you query a relay (or run your own), you write to a PDS (or run your own), and the protocol doesn't care which. This is the same shift email made in the 1990s — from 'CompuServe vs. AOL' to 'just an address' — and ATProto is betting the social graph can make the same transition.

What this means for your stack

If you're building social tooling, the practical takeaway is that ATProto's data model is closer to Git than to a typical social API. Each user's PDS is a Merkle-signed repository of records. You can clone it, mirror it, index it, or transform it without coordinating with the 'owner' server — because there isn't one in the Mastodon sense. The App View pattern (separating storage from presentation) means you can build a competing client or an entirely different product surface on the same underlying graph without asking anyone's permission and without the user having to migrate.

If you've been holding off on ATProto because you assumed it was 'just Bluesky's thing,' the architecture argues otherwise: the protocol explicitly allows third-party PDS providers, custom feeds, custom App Views, and alternative relays. The economics of running a relay (currently ~$150K/month at Bluesky's scale, per their last public number) are the real moat, not the protocol. If you're a CDN or infra company, that's the interesting business opportunity hiding in plain sight.

For existing Mastodon developers, the migration story is uncomfortable. ActivityPub's instance model is deeply baked into every implementation — you can't retrofit DIDs onto a protocol that treats `user@server` as the canonical identity. The two networks will likely coexist, with bridges (like Bridgy Fed) papering over the impedance mismatch.

Looking ahead

The real test of Abramov's thesis isn't philosophical — it's whether a non-Bluesky-PBC PDS ecosystem actually emerges. As of mid-2026, third-party PDS providers exist but serve a rounding-error share of users. If that doesn't change in the next 18 months, the 'no instances' framing starts to look like a protocol guarantee with no users exercising it. If it does change — if a meaningful percentage of accounts run on PDSes Bluesky doesn't operate — then ATProto will have done something ActivityPub never quite managed: decentralization that survives contact with users who don't want to read a docs page to pick a server.