did:plc Considered Harmful
There are two Decentralized Identifier (DID for short) methods blessed for use in atproto:
Both of them have the same problem: they’re identification methods, but not decentralized identification methods.
This document will focus on the problems with did:plc, because the problems with did:web are obvious. You’re not gonna resolve did:web:blockenheimer.click because I let the domain expire – unless someone else bought it back to usurp my identity. You’re not gonna resolve did:how-much-web-would-a-did-web-did-if-a-did-web-could-did.website because the domain got suspended by an algorithm a week after registration and the registrar refused to restore it. The mere fact did:web is blessed allows Meta to come in and make a client where everyone has did:web:something.threads.net identities and never allow users to update their identity e.g. migrate to another provider. did:web is blessed just so there’s a way – regardless of how much it sucks – to avoid your identity being centralized to Bluesky PBC. It’s there for the plausible deniability that atproto is decentralized.
The justification Bluesky PBC gives for the choice of these two methods is that they have the following strigent criteria:
- Updates must be cheap
- Updates must have low latency
- Resolution must be easy to implement
- The method must have real-world use
Bryan Newbold explains this as follows:
there are hundreds of DID methods. most of them are blockchain, but many have unique/novel decentralized properties. if folks invent something better than did:plc, which meets the criteria for atproto (cheap, low-latency, easy to implement, real-world use) we can add support (source)
[…] our design goal with did:plc was to have “who is operating it” not really matter: either because the operator has no power over the DIDs, or a consortia, or good governance (source)
That last point is important and valid! When someone argues against usage of Signal in favour of a different E2EE messenger because the latter is under different jurisdiction, they should be rightfully laughed out of the room.
That’s not so much the case with did:plc. Signal can’t censor a user because they don’t know what user you are when you send a message. Any legal entity that operates did:plc must have the capacity to censor users because every message is necessarily a plaintext identity operation.
Right now, it does matter who’s running did:plc, and Bluesky PBC isn’t looking all that great as a steward of an open protocol.
To be clear, even centralized as it is, did:plc still has decent properties:
- People can watch the global log (the
/exportendpoint on plc.directory) to construct a mirror - Anyone can verify the validity of a single DID by requesting its audit log (here’s mine)
- Censorship of operations on a DID would be pretty obvious, since you can publish a signed DID operation and let other people try to submit it, and observe the failure
Cryptography and log watching will get you a long way… but did:plc is still a single point of failure which could censor a user (or more likely, be forced to; Bluesky PBC has a tendency to comply with governments).
They had a good reason, but Bluesky PBC has reverted did:plc operations in the past. I doubt they ever would again… but now they’ve announced to adversaries that it’s something they have the capacity to be forced to do.
Sometimes I’m the one telling people that assuming the government is out to get you with all they have is unnecessarily paranoid… but did:plc underpins the identity of pretty much every Bluesky user. For most people, Bluesky might only be entertainment, but if we don’t solve this problem we’re doing a great disservice to those for whom it matters more.
Right now, Bluesky PBC is doing a great disservice to its users.
Albeit only in a proof of concept state, a working DID method respecting all of Bluesky PBC’s supposed criteria was released almost a year ago now, and they know it exists. Nothing new.
Bluesky PBC, again and again, does nothing to make themselves more resilient to themselves. The company has become an adversary.
Home About Contact