plc.directory is the directory service that resolves did:plc identifiers used by AT Protocol. Given a did:plc value, it exposes the current DID document and the operation history that describes authorised changes to that identity.
How PLC operations resolve an identity
A did:plc account can update properties such as its service endpoint or verification keys by submitting cryptographically authorised operations. plc.directory stores and serves that operation log, from which the current DID document can be derived. AT Protocol software queries the directory when it needs to learn where an identity's PDS is located or which verification material is current. This keeps the stable DID separate from a particular hosting domain.
Why the directory enables migration
The directory makes migrations practical: references to an account can continue using the same DID while the service endpoint changes. It also supplies a transparent history of operations rather than silently replacing one database row. For applications, the result is a relatively simple resolution mechanism that supports portable account identity without making every client maintain a global distributed ledger.
Central infrastructure inside a decentralised design
The obvious trade-off is that plc.directory is shared infrastructure. AT Protocol's identity model is decentralised in important ways, but did:plc is not dependency-free. The method's design, governance, caching and recovery rules therefore matter. Accounts that want a different trust model can use did:web in supported contexts, although that ties identity more directly to control of a web domain.
Related reading
- What Is did:plc? The Identity System Behind Most Bluesky Accounts
- What Is an AppView in AT Protocol? The Missing Layer Between Data and Apps