Why atproto Has No 'Instances' — and Why Mastodon Brains Keep Asking

Dan Abramov tackles a question that surfaces in every Hacker News thread about the AT Protocol: where are all the Bluesky instances? His answer is that the question itself is a category error. atproto has no instances, because it deliberately separates the two things Mastodon fuses together. The model to keep in mind is the old web: you publish on your own blog (hosting), and apps like Google Reader or Feedly aggregate everyone’s posts (aggregation). Posts live in hosting; apps are just projections of the whole blogosphere.

Mastodon and ActivityPub took the opposite path. Each instance is a self-hostable bundle of app plus hosting — a ‘little Twitter’ you live inside. That coupling forces federation, where instances forward posts to one another so users on different servers can interact. The consequences are real: your identity is permanently tied to your instance (hence user@server handles), admins can defederate and silently cut off your friends, your account vanishes if the instance dies, and the connections between servers scale at O(n²). Abramov argues this is why Mastodon users instinctively measure decentralization by instance count — it’s the only lever the architecture gives them.

atproto erases the box. Hosting and apps are split at the network level, so you swap your data host freely (Abramov moved his to Eurosky in minutes, and notes Cloudflare can host it for free) while any app aggregates over everyone’s data through shared relays. Independent apps like Tangled and Semble have nothing to do with Bluesky, and running a full Bluesky database is no more meaningful than running your own copy of Google Reader. The metrics that actually matter, he says, are whether people are migrating hosting and whether new apps are being built — not how many ‘instances’ exist, because there are none.