There are no instances in ATProto

By overreacted | June 19, 2026 | $\text{Price: Pay what you like}$

Whenever a thread about atproto trends on Hacker News, the same question inevitably pops up in the comments: "But where are the Bluesky instances?"

This question stems from a "Mastodon-brained" perspective. I wanted to create a resource that explains why this concept doesn't apply here.

📡 The Era of RSS and Google Reader

While RSS might seem like a relic (though it still powers podcasts!), it represents a pivotal architectural moment. During the "golden age" of the web, blogging was the primary way people shared ideas.

The workflow was simple:

You wrote on your own blog.
You hosted it yourself or used a blogging platform.
Others discovered your content via aggregators.

Crucial Point: Please let this concept sink in. The content lived in one place, and the interface used to read it lived in another.

🏢 The "Facebook" Evolution

Then came the era of centralization. The industry decided to put a "box" around the entire experience. By enclosing everyone in a single space, companies could maximize ad revenue and control the user experience.

~~Alice's blog~~ $\rightarrow$ Facebook Post ~~Cat's blog~~ $\rightarrow$ Facebook Post

Now, we have a single app and a single newsfeed. We traded autonomy for a walled garden.

🐘 Mastodon and the "Instance" Model

To be precise, I'm talking about Mastodon, not ActivityPub. ActivityPub is a protocol; it doesn't dictate implementation. Mastodon chose a specific path: The "Little Facebook" approach.

The goal was to make the Facebook model self-hostable. Instead of one giant box, we have many small boxes. Each community runs its own "instance," which acts like a digital nation-state.

The Fiefdom Problem

In this model, you don't just "use" the network; you belong to a specific instance.

Feature	Mastodon Instance Model
Identity	Tied to the server (e.g., `user@instance.com`)
Data	Stored by the instance admin
Connectivity	Based on "federation" agreements
Topology	Like warring fiefdoms in Ancient China

If Alice (Instance #1) follows Bree (Instance #2), the two servers agree to forward Bree's posts to Alice.

The risks are inherent:

Admin Conflict: If two admins fight and "stop federating," you lose access to your friends.
Identity Lock-in: You aren't followed as a "platonic you," but as "you-from-that-specific-server."

🔓 The ATProto Way: Erasing the Box

The fundamental mistake in the instance model was drawing the box around the hosting and the app together. ATProto erases that box.

We are returning to the RSS logic: Hosting is separate from Aggregation.

$\text{Decentralization} \neq \text{Many copies of one app}$

In atproto, the architecture looks like this:

What this means for you:

Swappable Hosting: You can move your data from one provider to another.
Self-Hosting: For the adventurous, you can host your own data (e.g., via Cloudflare).
App Diversity: You can use apps like Tangled or Semble that have no connection to Bluesky.

To visualize the data structure, think of it as a portable record:

{
  "did": "did:plc:12345",
  "hosting_provider": "atproto-host-alpha",
  "data": {
    "posts": [...],
    "follows": [...]
  }
}

🧠 Freeing Yourself from "Instance Brain"

The reason decentralized social media debates get derailed is that Mastodon users define decentralization by the number of instances. In their world, that's the only variable because the app and the host are fused.

In atproto, an app is simply a projection of the entire "Atmosphere," much like Google Reader was a projection of the "Blogosphere."

You are no longer a citizen of a server; you are a sovereign entity in a network of data.