The Instance Question Is the Wrong Question
Whenever a post about atproto reaches the front page of Hacker News, the comments reliably produce the same question: "Where are all the Bluesky instances?" The short answer is that there are none — because the question assumes a model that atproto doesn't use. Instances are a concept from the Mastodon world, and applying that mental model to atproto produces a category error.
Understanding why starts with an older technology: RSS.
Hosting and Aggregation Are Distinct Concerns
In the RSS era, publishing and reading were cleanly separated. You published posts on your own blog, whether self-hosted or on a platform. Then aggregators like Google Reader or Feedly pulled content from many blogs into a single reading experience. Collective blogs like Monologue did something similar for communities.
The key insight is that your posts never lived inside the aggregator. Google Reader was a projection over the blogosphere, not the home of the content itself. If Google Reader shut down, the blogs remained. The architecture made hosting and aggregation two independent layers.
Traditional social media collapsed this distinction. Everything — hosting, identity, aggregation — got enclosed in a single box so it could be monetized. The result was centralization and runaway network effects.
Federation Couples Hosting With Identity
The Mastodon approach to decentralization keeps the "one box" model but makes it self-hostable. Each instance is a little Facebook or Twitter, and communities run their own. Federation handles cross-instance communication: when a user on one instance follows a user on another, the two servers agree to forward posts between each other.
This design has consequences:
- Your identity is tied to your instance. You aren't just Alice, you're Alice-from-instance-#1. This makes where you registered an immutable part of who you are on the network.
- Instance admins control visibility. If two instance administrations have a dispute, they may stop federating, silently cutting off your view of friends on the other side.
- Your account dies with your instance. People who followed you were following you-from-that-instance, not a portable "you" that exists independently of your server.
There is also a scalability concern: the federation graph between instances grows as O(n²) as the number of servers increases.
atproto Inverts the Model
atproto starts from the opposite direction. Instead of asking how to federate many copies of a single app, it returns to the RSS model: hosting and aggregation are decoupled at the network level.
You can choose where your data lives, and you can change that choice. Applications then aggregate over everyone's hosting, the way Google Reader aggregated over blogs. The network supports a diversity of content types and user interfaces, not just one app's feature set.
What Decentralization Actually Looks Like
Because of this architecture, decentralization in atproto takes different forms than it does in Mastodon:
- You can move your hosting. This is a live feature, not a theoretical one. When you switch providers, your data and identity continue to work. Running your own personal host is possible too, including on free infrastructure if you're willing to set it up.
- You can build or adopt new applications. Third-party apps that are entirely separate from Bluesky exist, with nothing in common except that they read from and write to the same underlying protocol. Building your own is a realistic project for a developer.
The protocol also makes room for infrastructure innovation, including clients that use shared community-run caches rather than maintaining their own full database.
The Instance Mentality Crushes Discussion
The instinct to count instances comes from Mastodon's constraints. In that world, a "box" couples an app with hosting, and the only way to measure decentralization is to count the boxes. They are isolated by default, and federation is an after-the-fact patch for inter-server communication.
In atproto, an app is a projection over a shared network. Moving between hosting providers is a supported, routine operation, and creating new applications is equally central to the design. Operating many full copies of the main database server is possible, but it doesn't improve anything — it's like running multiple copies of Google Reader to increase blog diversity. Some independent servers exist, but they arise to serve community-specific needs like a distinct moderation philosophy, not as the fundamental unit of the network.
The meaningful measures of health for atproto are different ones:
- Are people able to move between hosting providers?
- Are people developing and using apps beyond the defaults?
Decoupling hosting from applications fixes the broken incentives inherent in both closed and federated architectures. The mistake was ever coupling them — keeping content outside the apps, and letting the apps aggregate over it, is what makes the whole thing work.
