First Steps of the PLC Organization – Independent Public Ledger of Credentials
The Public Ledger of Credentials Organization has formally incorporated as a Swiss Association to independently operate the identity directory for AT Protocol accounts.
summary is enough The announcement is short, but the comment thread features helpful architectural debates with core contributors on identity ownership tradeoffs.
summary
Bluesky's identity directory, the Public Ledger of Credentials (PLC), is spinning out into an independent Swiss Association governed by a board of security and protocol experts. The PLC directory tracks account updates and cryptographic key rotations for AT Protocol identifiers using signed logs rather than a mutable database, preventing server tampering. While initially bootstrapped by Bluesky, the organization plans to assume full control of directory assets and establish independent governance. Commenters actively debate how this architecture compares to other decentralized identity schemes like did:web.
key points
- The PLC Organization is newly formed as a Swiss Association led by security figures including Filippo Valsorda, Richard Barnes, and Wendy Seltzer.
- The directory functions as a data availability layer for AT Protocol, storing cryptographically signed account updates that the server cannot forge.
- Because account states are tied to user-controlled keys, the directory can theoretically be forked or replaced if operators turn malicious.
who should read it
Protocol engineers and developers tracking decentralized identity and the AT Protocol ecosystem.
discussion positive
consensus
Commenters welcome the independent governance structure, though many debate whether PLC genuinely achieves self-sovereignty compared to alternatives like did:web or domain-based identifiers.
pushback
Skeptics note that publishing complete identity transition histories can create privacy risks like deadnaming, and question the long-term centralization of a single directory.
Sort of.
I like to insist that the PLC Directory collects and distributes updates to highlight how it's different from a database. The latest state of the account is signed by the key that created it, or by a key that succeeded it. The directory can't inject any values, it's just a low-complexity solution for data availability: the "how do I learn about updates" part.
It could decide to hide/reject updates, but then it could just as well be forked and replaced if it did that. If downstream applications decide to get their account updates somewhere else, that's the directory now, without any …
Core contributor Filippo Valsorda clarifies why the PLC directory is technically distinct from a normal mutable database due to user-signed state transitions.
Generated by an LLM from the article and thread. Check the sources before relying on it.