There Are No Instances in ATProto - Dan Abramov Explains the Architecture

Dan Abramov - yes, the React/Redux Dan Abramov - has written a piece explaining why the mental model most people bring to ATProto from Mastodon is fundamentally wrong. The post hit the Hacker News front page with 467 points and 236+ comments, and it's worth reading in full if you care about how decentralized protocols actually work.

The title is the thesis: there are no instances in ATProto.

What the Article Actually Says

Abramov's core argument is that Mastodon-style federation bundles two things that should be separate: hosting and applications.

In Mastodon, you are "Alice-from-instance-#1." Your identity, your data, and your experience of the network are all tied to which server you picked when you signed up. If that server shuts down, goes offline, or decides to defederate from other parts of the network, your identity goes with it.

ATProto decouples these. You have:

1. Hosting (called a PDS, or Personal Data Server) - where your data lives
2. Applications (called AppViews) - which aggregate and display data from across the network

The key insight: hosting servers in ATProto never talk to each other directly. They just store data. Applications pull from all the hosting servers and present a unified view.

Abramov uses an RSS analogy: "Keep our stuff outside the apps; let the apps aggregate over it." Your blog posts live in one place. Any RSS reader can display them. You can switch readers without losing your posts, and you can move your blog without breaking your readers.

Abramov moved his own hosting to Eurosky, uses multiple applications (Tangled, Semble, Bluesky), and notes he could self-host on Cloudflare without losing his identity or connections.

What Hacker News Is Saying

The discussion thread is one of the more technically substantive HN threads in recent memory, with Abramov actively responding to critiques.

The relay question came up immediately. Several commenters pointed out that the article glosses over relays - the components that aggregate data from all the hosting servers so apps don't have to connect to thousands of individual servers. One commenter asked: "Aren't relays basically instances?"

Abramov's response: relays are an optimization, not a fundamental part of the architecture. An app can work without a relay (like reddwarf.app does). Running your own relay costs about $30/month now. There are multiple community-run relays. And crucially, a relay is just a "dumb retransmitter" - it doesn't make moderation decisions or control your identity.

The "centralization in disguise" critique showed up. Some commenters argued that having one main Bluesky AppView is effectively centralization. Abramov's counter: "It's not centralized in any way that matters." You can run your own AppView, there are independent ones like Blacksky, and the relay infrastructure is cheap enough that multiple competing ones exist.

The moderation angle got attention. One commenter linked to prior writing about why federated moderation is a problem - the "warring fiefdoms" dynamic where instance admins fight about who to defederate. Another pointed out that ATProto's separation means you can take your identity to another AppView if you disagree with Bluesky's moderation, without losing your data or network.

Mastodon defenders pushed back. Some argued that you can plug different frontends into Mastodon servers, and that the article treats Mastodon (the implementation) as if it were ActivityPub (the protocol). Fair point, but Abramov's response is that even with different frontends, the fundamental coupling of hosting to a specific server's policies and uptime remains.

The "can it scale down" question. One commenter asked if you could run this on a Raspberry Pi at home. Abramov linked to a post showing that some ecosystem services do run on Raspberry Pis, and noted that "the best algorithmic 'For You' feed on the app runs off someone's gaming computer at home."

Why This Matters for Developers

If you're building anything that touches social protocols, this architectural distinction has real implications.

Data portability is a first-class concern. In ATProto, your posts are stored in a format that any compliant application can read. This is not an afterthought or an export feature - it's how the system works. If you're building an app, you're building something that reads and writes to a shared data layer, not a walled garden.

Identity is not locked to infrastructure. The DID (decentralized identifier) system means your handle and your data are yours regardless of who hosts them. If you're building auth flows or user management, this is a different model than "log in with X server."

The "build your own Twitter" question has a real answer. You don't have to build your own Twitter. You can build an application that reads from and writes to the same network everyone else is using. The barrier to entry is "build an AppView" not "build an entire social network."

Moderation happens at the application layer. This is both a feature and a responsibility. Applications decide what to show, not hosting providers. If you're building an application, you're also building a moderation policy - but that policy doesn't affect other applications or force users to choose between your moderation and keeping their data.

For related reading on protocol-level architecture decisions, see our coverage of MCP server ecosystem and agent infrastructure tools.

Sources

• Original article: "There are no instances in ATProto"
• Hacker News discussion
• ATProto documentation
• Can ATProto scale down?