Bluesky Identified the Right Problem. The Architecture That Solves It Is the Adaptive Index.

Bluesky built something worth examining carefully. AT Protocol is a serious attempt to design decentralized social infrastructure from first principles: portable identity, user-controlled data, open federation, cryptographic self-authentication. The team understood that the failure modes of earlier decentralized protocols were not philosophical but architectural, and they set out to address them directly.

They got a lot right. The separation of handle (human-readable, updatable) from DID (persistent, cryptographic) is a sound design. The PDS federation model is real: any host can run a Personal Data Server and any user can migrate their account between hosts. The data repository model means users own their content in a portable, verifiable form. These are genuine structural improvements over both centralized social platforms and earlier decentralized protocols.

The problem is the PLC directory. Bluesky knows it. Their own documentation says so.

What the PLC directory is and why it matters

Every AT Protocol identity is a DID: a persistent identifier that resolves to a DID document containing the user's signing keys, hosting service, and handle mapping. The most common DID method in the network is did:plc, the Public Ledger of Credentials, developed by Bluesky because no existing DID method met their requirements for consistency, availability, recoverability, and cryptographic security.

The way did:plc works: a central directory server collects and validates operations, and maintains a transparent log of operations for each DID. Bluesky's own GitHub repository for the DID PLC method is direct about this: "A central directory server collects and validates operations." When a client resolves a did:plc identifier, it queries plc.directory — a single global service — to retrieve the current DID document and operation log.

Everything in AT Protocol that depends on identity depends on the PLC directory. Handle resolution requires a DNS lookup followed by a PLC directory query. Identity caches are recommended to have a maximum TTL of 24 hours, after which they must re-validate through the directory. Account migrations, key rotations, and handle updates all propagate through the PLC directory. There are over twelve million registered DIDs in the network as of late 2024. All of them are anchored in a single directory operated by Bluesky Social PBC.

Wikipedia's article on AT Protocol states what the Bluesky team has acknowledged: the did:plc method "has been noted as being a single point of failure within the protocol, as its current implementation relies on a single registry hosted by Bluesky Social, with no system to independently verify the document's current state."

What Bluesky is trying to do about it

Bluesky's Fall 2025 protocol check-in is candid about where things stand and where they are going. They are working to establish a Swiss association to operate the PLC directory and own its assets, with the explicit goal of making governance independent of Bluesky PBC. They have stated that "we do not expect a single global directory to be the final technical architecture for the system." The direction is clearly toward something more distributed, but the path from here to there has not been fully specified.

The check-in also frames their broader goal as "hard decentralization": making the network less dependent on Bluesky PBC's existence. They are working on this through open PDS federation, independent infrastructure, and governance separation of the PLC system.

The intent is right. The question is what architecture actually achieves it.

Why a consortium directory does not fully solve it

The intermediate step Bluesky has described for PLC is a permissioned consortium: multiple parties operating the directory under shared governance rather than a single organization. This is a meaningful improvement in resilience and governance accountability. It is not the same as distributing authority into the identity namespace itself.

A consortium directory is still a single global directory. Identity updates still propagate through it. Resolution still requires querying it. The authority over what a DID document means, and who can change it, still flows through a central system — now with multiple operators rather than one, but still structured as a global registry whose approval is required for any identity mutation.

The structural alternative is: each segment of the identity namespace governed by the nodes responsible for it, under locally held policy, with mutations proposed and validated through local consensus. Identity resolution traverses the hierarchy stepwise without querying a central registry. When a user migrates between hosts, the migration is a mutation proposal evaluated by the anchors governing their identity scope, not a global transaction that must be recorded in a single directory. When a key is rotated, the rotation is validated locally and its lineage preserved cryptographically — not through a central operation log.

This is what AT Protocol's own description of the problem points toward. Their requirements for the identity system were: strongly consistent, highly available, recoverable, and cryptographically secure with fast and cheap propagation of updates. An anchor-governed adaptive index satisfies all four. Consistency is provided by local quorum. Availability is provided by the redundancy of the anchor group governing each scope. Recoverability is provided by cryptographically committed lineage. Propagation is local, not global.

The deeper alignment

What Bluesky got right is the framing: identity portability requires that users, not platforms, be the authority over their own identity. The PLC directory was built to enable that. The gap is that the directory itself is now the platform — a different one from Twitter or Meta, with better intentions and more accountable governance, but still a single point that must be trusted for identity authority to function.

The adaptive index does not replace AT Protocol's identity model. It is the infrastructure layer that would let the PLC directory's function be distributed into the namespace itself. Each PDS operator, each community, each region of the network could govern its own identity scope under locally held policy. The global operation log that the PLC directory currently maintains would become a traversable lineage across anchor-governed scopes, verifiable without querying any single registry.

Bluesky has done the hard work of building an open, federated, portable identity protocol. The last dependency — the central directory — is the one they have already named as a problem. The architecture that eliminates it is the adaptive index.