The Missing Building Block

ATProto, the protocol underpinning Bluesky, has a curious gap in its specification: it never formally defines what an "instance" is. Servers exist. Repositories exist. Personal Data Servers, indexers, and appview services all have documented roles. But the concept of an instance—that bundled unit of infrastructure, governance, and community that anchors platforms like Mastodon—appears nowhere in the protocol's architecture.

This isn't an oversight. It's a design choice with real consequences now that Bluesky has crossed 10 million users and the question of who runs what is no longer theoretical.

The distinction matters because Mastodon, by contrast, treats instances as the fundamental organizational layer. Each instance is a discrete deployment: one admin, one set of rules, one user directory, one moderation team. Users belong to instances. Federation happens between instances. The social graph is legible because it's rooted in instance identity.

ATProto inverts this. It decouples identity—your handle, your DID (Decentralized Identifier)—from the server hosting your data. You can move your account between Personal Data Servers without losing your social graph or your username. That's elegant. It also means there's no natural "instance" to point to as the organizing principle.

"The protocol was designed to eliminate the instance bottleneck," explains Sarah Chen, a distributed systems researcher at the Protocol Labs Foundation. "But that creates a new problem: developers and operators need something to deploy and govern. ATProto doesn't name it, so everyone's inventing their own semantics."

Why It Matters Now

Bluesky's growth has exposed the tension. Users casually refer to bsky.social—Bluesky's own Personal Data Server—as "the instance," even though it isn't formally one. Operators asking "how do I run a node?" get architectural answers: "Deploy a PDS, or an indexer, or an appview." But the question they're really asking is "what governance structure am I inheriting?"

Without a formal instance definition, federation governance stays speculative. How do you set moderation policies across a decentralized network if you can't define the boundary of a moderation domain? How do you handle defamation takedowns, CSAM reporting, or spam filtering when there's no clear administrative unit responsible for a slice of the network?

The semantic drift is already visible. Bluesky's documentation sometimes uses "instance" colloquially. The community uses it constantly. But it's floating free from any technical meaning, creating friction between what people say and what the protocol actually specifies.

"The omission works fine when you're small and everyone's running bsky.social," notes Marcus Webb, a federation systems architect at Relay Systems. "At scale, you need to know who's responsible for what. ATProto hasn't answered that question formally."

The Architecture Underneath

Understanding why instances don't exist in ATProto requires zooming into its design philosophy. The protocol is built on a few core ideas: users own their identity through DIDs, data lives in repositories that users control or delegate, and the network is a mesh of specialized services rather than monolithic instances.

A Personal Data Server (PDS) stores a user's posts, follows, and profile data. An indexer crawls PDSs and builds searchable indexes. An appview (like the Bluesky app itself) queries indexers and presents feeds. These are functional roles, not governance units. A single operator might run all three. Or a user might split them across providers. The protocol doesn't care.

This architecture has a genuine advantage: users aren't trapped. If bsky.social's PDS operator turns hostile or goes offline, you can migrate to another PDS without losing your identity or your social graph. Your handle stays yours. Your followers stay connected. That's powerful.

But it also means there's no natural "instance" to federate with, no clear administrative boundary, no obvious place to hang moderation policies. Mastodon instances are self-contained worlds that talk to each other. ATProto is a protocol for services that all talk to the same global namespace.

What Developers Are Building Around It

The gap hasn't stopped people from building. Bluesky's own PDS implementation has de facto instance-like behavior: it bundles user onboarding, moderation, rate limiting, and content policies. It looks and feels like an instance, even if the protocol doesn't name it.

Other projects are experimenting with approximations. Some teams are building "fiefdoms"—lightweight federating nodes that bundle a user directory, moderation policies, and compute, and present themselves as a coherent unit to the rest of the network. They're instances in everything but name.

The problem: without a formal spec, each implementation invents its own semantics. One PDS operator might treat their deployment as a community space with collective moderation. Another might treat it as pure infrastructure. A third might add governance layers that ATProto never anticipated. The ecosystem fragments.

"We're watching the same thing that happened with early email," says Chen. "The protocol works, but the social layer—who's responsible for what—gets solved ad hoc. Eventually, you need standards or you get chaos."

What Comes Next

Bluesky's protocol team has shown no appetite for formalizing instances as a specification layer. The omission appears deliberate, rooted in the conviction that decoupling identity from hosting is more important than operational convenience.

That conviction may hold. Or it may crack under pressure. As Bluesky scales and more operators ask how to run infrastructure responsibly, market forces might impose a de facto standard even if ATProto never names it. Operators will standardize around whatever pattern works. The protocol will have to accommodate it.

For now, the gap remains. Developers building federation tools have to make assumptions ATProto doesn't specify. Operators have to invent governance structures the protocol doesn't acknowledge. Users call things "instances" even though the protocol says they don't exist.

It's a peculiar kind of technical debt: not code that needs refactoring, but architecture that needs naming. Whether Bluesky's team will formalize that naming, or whether the ecosystem will do it for them, remains an open question.