Every ATProto account is identified by a "DID", a Decentralized Identifier. Just two DID flavours are blessed, did:web and did:plc, and close to 100% of accounts use plc. PLC stands for Public Ledger of Credentials. The ledger is a centralized log of identity operations.

Stay with me: the centralized decentralized identity ledger underpinning ~all ATProto accounts today is a web service under the sole control of Bluesky Social PBC.

If Bluesky closed public access to their PLC service tomorrow, everything in the ATmosphere would fall apart: app logins fail, relays grind to a halt, media and records become unfetchable[2, 3].

Non-adversarial migration

Bluesky wants to release control of PLC to an alternative entity:

We are enthusiastic about the prospect of moving governance of the did:plc method, and operation of registry servers, out of the sole control of Bluesky Social PBC.
—did-method-plc's README.md

This is likely to happen and that's a good thing. Like for DNS and TLS, maybe top-down authority with reasonable governance™ will work out in practice[4] for PLC.

But this move hasn't happened yet[5]. We should probably have some contingency plans read in case the company (or its successor) becomes an adversary.

PLC mirrors

The credible exit narrative for PLC goes roughly: to ditch Bluesky, the rest of the ATmosphere can just™ switch over to someone else's mirror. [who?]

The mirror situation right now is, to be frank, a little worrying:

  • There might actually only be three public mirrors[6], all run custom code[7].

  • Zero implement /export (for downstream mirrors) or operation validation (to accept writes).

  • Each is operated by just one individual.

We need more! It's not a demanding task! Janet and Jackson are a 2011 Raspberry Pi and SSD, who just started mirroring PLC:

A black 2.5" Samsung SSD with googly eyes lies appears to look at the raspberry pi original model b, who also has googly eyes on its protruding SSD. the pi has a bright green power cable, a purple network cable, and a black USB cable joining it to the SSD. They lie on a light wooden surface under soft natural light.

But what do we actually need from bigger mirrors to plausibly uphold that credible exit story? Janet and Jackson aren't quite it.

Baseline migration-ready mirror requirements

1. Willingness to collaborate

An adversarially migrated PLC directory represents a degraded state for the whole ATmosphere.

Multiple teams will likely run new authoritative directories that accept identity operations. This can work with the current PLC— identity ops self-certify so directories can forward them to each other—without changing anything in the reference implementation.

This multi-authority mode is not built into the current spec and is not robust. Fractures can arise over differing directory timestamps that directly determine the validity of a sequence of ops, so teams will need to take action together to resolve conflicts as they arise.

It will be urgent for the new authorities to work together toward either the creation of new centralized governance, or evolution of the PLC spec to accommodate a distributed authority mode, to get the ATmosphere back to a stable state.

2. Governance, transparency, trust

PLC audit logs are self-certifying which means nobody, not even the directory operator, can modify or create new valid operations for your identity, unless they have access to one of your rotation keys.

However, the directory operator can take some malicious actions: omit operations from the end (say, undo adding a rotation key), alter a timestamp (reverse a nullification validity) or just refuse to acknowledge your existence at all. The impact from these actions could range from being locked out of apps to identity takeover.

Any PLC directory authority must demonstrate that they are able to govern with integrity, operate with full transparency, and have incentives aligned with all users in the larger ATmosphere.

This extends beyond an individual team and is contextual, intersecting with legal jurisdiction and political climate.

3. Spec compliance and high availability

To minimize the risk of fracturing the ecosystem, any directory accepting identity operations should be exhaustively spec compliant. Today that means it should run the reference PLC directory server code [7 again, really].

Any disruption in service from a PLC directory can have wide impact across the ATmosphere, so a directory authority must show how they have minimized technical and operational risks to their service availability. Including but not limited to:

  • Database redundancy, rapid fail-over, low-latency recovery from backups; high availability application hosting.

  • Appropriate access controls to and clear ownership of all technical infrastructure.

  • Monitoring, alerting, on-call staff to quickly act in incidents.

Future of PLC

The current PLC spec leaves space for evolving into a more distributed architecture, it's an exciting space! That same flexibility is part of what would make adversarial migration today possible.

I have optimism that moves toward distributing the PLC will converge with independent operators' adversarial contingency plans.

Aaaaand of course, the breaking news! today Bluesky announced:

Creating an Independent Public Ledger of Credentials (PLC) Directory Organization | Bluesky
The Bluesky Social app is built on an open network protocol that refers to each user by a unique Decentralized Identifier, or DID (a W3C standard). The most popular supported DID method was developed in-house by Bluesky Social, and is called "Public Ledger of Credentials", or PLC. The PLC identity system currently relies on a global directory service to distribute identity updates, and that directory service has been operated by Bluesky as well.
https://docs.bsky.app/blog/plc-directory-org

This announcement is a big step in both commitment and progress toward PLC independence. While light on detail, it includes this encouraging forward-looking passage (emphasis added):

We do not expect this organization to be the final governance structure for PLC, and we do not expect a single global directory to be the final technical architecture for the system. But as the AT network grows and diversifies, it becomes increasingly important for the identity system to have a clear path toward independence.

We still need more mirrors. We need log monitoring projects, and we need spec evolution. And we still need to be ready for adversarial migration.

Hopefully we won't need to.

Many many thanks to Ted Han, Rudy Fraser, Anirudh Oppiliappan, Akshay Oppiliappan, Ryan Barrett, Anuj Ahooja, and Bailey Townsend for the chats and feedback about this!

Footnotes

1. This post's structure shamelessly borrowed from @retro.id's excellent Adversarial ATProto PDS Migration post. Read it and add a backup PLC rotation key to your identity!

2. Logins starting from your atproto handle require the DID doc from PLC to find your PDS. Relays require the DID doc to find your signing key to verify sync events. Fetching anything by at-uri requires, again, locating your PDS.

3. Sorry for the did:web erasure. There are dozens of you and I love you. All your stuff would keep working just fine, you're perfect.

4. If you feel that DNS and TLS are examples of failures for being centralized, and if you feel similarly toward PLC: totally fair and i really do respect that position.

5. Breaking news! Still light on details, but Bluesky is taking steps toward creating an independent Swiss Association to assume governance of PLC!

6. I took an informal inventory on bluesky, which incidentally led to a 50% increase in the total count.

7. This matters because "In practice the reference implementation […] is more authoritative than the spec". A PLC directory should run the most authoritatively-accepted implementation, which is currently, definitionally, Bluesky's typescript code

8. We haven't had audit log snapshots or automated third-party auditing in much of a meaningful way for PLC so far. I've been working on some related tooling.