By ByteBot
Dan Abramov published a post yesterday that’s sitting at nearly 400 upvotes on Hacker News and counting. The React creator, now building at Bluesky, wrote “There Are No Instances in atproto” — and if you’ve ever looked at Bluesky and thought “wait, where are the instances?”, he’s writing directly at you. His answer is sharper than you’d expect: the question itself is wrong. And understanding why it’s wrong will change how you think about building social apps.
You’re Asking About Email. ATProto Is RSS.
Here’s the mental model most developers bring to decentralized social: email. Your instance is your server. It federates with other servers. Your identity is @user@instance.com — tied to where you live. If your instance disappears, so does your identity. That’s Mastodon. That’s ActivityPub.
ATProto doesn’t work like that. The right analogy is RSS.
In the RSS era, you had a blog (your hosting), and you had readers like Google Reader or Feedly (the aggregators). Your blog lived on your hosting. Google Reader was just reading it — a projection of your content, not a copy of it. You could switch from Google Reader to Feedly without your blog changing. The hosting and the reading were separate things.
ATProto is that. Your Personal Data Server (PDS) is your hosting — the equivalent of your blog. Bluesky’s app, Tangled, Flashes, Skylight — those are AppViews, the equivalent of feed readers. They aggregate from your PDS. They don’t own your data. They project it.
So when you ask “where are the Bluesky instances?”, you’re asking where the Google Readers are, not where the blogs are. The blogs are the PDSes. And you can switch your PDS — migrate to a self-hosted one, or a different provider — and your identity follows automatically. That’s not theoretical. It works today.
The Three-Layer Stack, Plainly
The ATProto network has three moving parts:
Personal Data Server (PDS): Your data home. It holds your signed repository, manages your cryptographic keys, and handles authentication. Bluesky runs a fleet of PDSes for most users. You can self-host. If you want to migrate, your recovery key lets you take everything within 72 hours — without your current PDS’s cooperation.
Relay (BGS — Big Graph Service): Aggregates the firehose from all PDSes into one unified stream. Apps consume from this. Running an independent relay currently costs around $34/month — cheap enough for organizations to do, and a handful already do. This is also where the most legitimate criticism lives, which we’ll get to.
AppView: What most people call “the app.” An AppView reads from the relay firehose and presents a view. Bluesky’s social app is one AppView. Tangled — a decentralized GitHub alternative — is another. Flashes (Instagram-style photos, 29K downloads on day one) is another. Skylight (short video, Mark Cuban-backed) is another. They all read from the same underlying social graph. Your followers on Bluesky follow you on Tangled automatically. You didn’t sign up again. It’s the same DID.
Lexicons are the glue. They’re schema definitions — app.bsky.feed.post, git.tangled.repo — that define what data looks like. Any app that speaks the same lexicon can read and write the same records. It’s interoperability through shared vocabulary, not through federation messages. The ATProto documentation has a full overview of how this works.
The Part Dan’s Post Glosses Over
The Hacker News thread is worth reading alongside Dan’s post, because it surfaces the real tensions.
The relay problem: while the protocol allows anyone to run a relay, in practice almost nobody does. Bluesky, Inc. runs the dominant relay. More than 90% of user data sits on Bluesky’s own PDS infrastructure. This is the same company that just raised $100 million in Series B funding — a public benefit corporation, yes, but also a venture-backed startup. The practical centralization is real, even if the theoretical architecture allows otherwise.
The counterargument is historical: Google Reader dominated RSS aggregation for years. The protocol still outlasted Google Reader. When Reader shut down in 2013, the ecosystem fractured — but it survived, and tools like Feedly, Inoreader, and NewsBlur absorbed the users. The question for ATProto is whether the relay and AppView landscape diversifies before Bluesky becomes too central to dislodge.
That’s not settled. And any developer choosing ATProto deserves to know it’s unsettled.
What This Means If You’re Building
If you’re evaluating decentralized social protocols for a project, here’s what ATProto’s architecture gives you:
Your app doesn’t need to build a user graph from scratch. It inherits one from day one — 43 million users with social connections already established. Tangled launched with a ready-made developer social graph because those developers were already on Bluesky. That’s not a small thing.
New data types are just Lexicons. If you’re building something that doesn’t fit app.bsky.*, you publish a new schema. Other apps can use it. The protocol doesn’t need to change.
And the IETF chartered the “Authenticated Transfer” working group in early 2026, starting the process of turning ATProto into an internet standard. That’s a durability signal. HTTP didn’t die when Netscape did. A standardized ATProto would survive Bluesky.
Dan Abramov’s post is the clearest explanation of ATProto’s architecture that exists right now. Read it alongside the official Bluesky developer docs, then look at the HN thread for the parts he leaves out. Both halves are necessary.
The architecture is genuinely more elegant than ActivityPub. The practical centralization concern is genuinely unresolved. Developers building social features in 2026 should understand both.
