Dan Abramov says asking for Bluesky's instances is a category error

Every time atproto hits HN someone asks where the instances are. Abramov's answer: there aren't any, and the question imports a Mastodon assumption that doesn't apply. The thread's answer: there's effectively one.

In brief

His argument is architectural. Mastodon bundles hosting and app into one server, so federation is server-to-server and identity is tied to your home instance. ATProto splits them: your data lives in a Personal Data Server, while apps aggregate across everything, like Feedly over the whole blogosphere.

Engineers in the thread pushed back hard. There's one PLC directory, a handful of relays, and in practice one AppView, all mirroring Bluesky's moderation. Decentralized in protocol, one company in practice.

The question Abramov got tired of answering

Title card for the overreacted.io post on atproto instances
Title card for the overreacted.io post on atproto instances

Dan Abramov, the React core developer behind overreacted.io, wrote the post to have something he can link the next time someone asks where Bluesky's instances are. His thesis: the question is a category error. "Instances are a Mastodon-brained concept," and atproto isn't built that way.

The contrast is the substance. In Mastodon's ActivityPub world, a server bundles two things — where your data lives and the app you use — into one "instance." Your identity is tied to that home server, federation means servers shipping messages to each other, and defederation can sever you from friends. ATProto deliberately splits hosting from aggregation: your repository lives in a PDS (Personal Data Server) addressed by a portable DID identity, relays shuttle the firehose of all that data, and AppViews index it into a usable app. The analogy he leans on is RSS: "every app is a projection of the whole Atmosphere, just like Feedly and Google Reader are projections of the entire Blogosphere." Because identity is portable, you can swap hosting providers and, as he did recently, nobody following you notices.

"AT does have instances — they're just grouped differently"

The most cited rebuttal didn't deny the architecture; it relabeled it. The pieces Abramov calls relays and AppViews are, structurally, instances — there just happen to be very few of them:

"In BlueSky, there is only one single 'AppView' instance in the entire network. There is one instantiated 'Firehose'. Each user can instance his own 'PDS' … It's just that the instances are segmented differently." — an independent computer-science researcher

Others made the practical version of the point: there's one PLC directory, very few full relays, and no AppView anyone could name that doesn't mirror Bluesky's moderation decisions. The article, several noted, draws PDSes and apps but leaves relays and AppViews out of its diagrams entirely.

"This article is deeply, deeply misleading, in that it leaves out relays and appviews in all of its diagrams … Are you able to run your own appview? Probably not (this answer has been upgraded from 'No' in only the last few months)." — a reader who tracks the protocol's components

The question the post didn't answer

React-internals maintainer Josh Triplett granted the explainer worked, then named the gap:

"It answered one part of the question but failed to answer … so what does ATProto do to solve the problems that instances solve? … when this article dismisses defederation as merely a mysterious reason you might not see posts from your friends, it fails to answer 'so how does atproto solve the problems that defederation solves?'" — Josh Triplett, Rust and kernel contributor

The RSS analogy itself drew fire. One reader called Google Reader an ominous thing to cite as a model of decentralization, since it centralized the RSS ecosystem and then died at an executive's whim. Another argued the analogy breaks because RSS blogs are self-sufficient, while atproto AppViews depend on expensive relays to be useful at all.

Protocol decentralization vs. who actually holds the keys

The deeper worry was less about topology than about money and control. Tim Bray put it bluntly:

"At the moment, ATProto is existentially dependent on Bluesky PBC, a venture-funded startup ($100M from Bain Capital) … it's hard to see what the business model is that will support what Bsky PBC does at a global scale." — Tim Bray, co-author of the XML spec

And one reader argued the portable, strongly-tied identity is itself the hazard: a permanent link from your stuff to you is exactly what a surveillance state wants, whereas Mastodon's per-instance identity offers a little plausible deniability. tptacek floated the inverse — that if single-user simplicity is the goal, someone should just build the "Blogger.com of Mastodon," one instance per person, and questioned whether atproto's advantages offset its "weird corporate parentage."

The split was clean: the protocol genuinely separates concerns in a way ActivityPub doesn't, and in practice almost everything still routes through one company's relay, one AppView, and one moderation policy. Both halves were true in the same thread.

Get breakdowns like this every day

The top Hacker News stories, unpacked — by email, Telegram, or RSS.

Next story · 10 of 33 Read more
🌍Other

A room of lonely teenagers lost a contest it was never allowed to enter

A Stockholm gaming clubhouse keeps teenagers from being lonely. It exists only because of a government grant, because nobody can put 'a place for lonely teenagers to feel less lonely' on an invoice.

★ 224 · 💬 247 · wilsoniumite.com · 4 min