did-method-webvh is exactly what we need! It keeps did-method-web’s simplicity (same HTTP/DNS mapping) while adding the verification method history that’s been missing. No more “was this key valid 2 years ago?” questions - the entire cryptographic chain is preserved.
The gap between did:web and did:plc was real: did:web = no history, did:plc = centralized registry. did:webvh sits perfectly in the middle - decentralized like did:web but with full audit trails like did:plc. Each DID document version is cryptographically linked.
Key rotation verification is the killer feature. With did:web, you can’t prove a key was valid in the past. With did:webvh’s did.jsonl log, every verification method change is signed and chained. Critical for compliance, long-term signatures, and forensics.
The SCID (self-certifying identifier) is brilliant - it’s a hash of the genesis entry, so even if someone hijacks your domain, they can’t fake your history. Plus optional pre-rotation keys mean you can recover from compromise. Security without sacrificing simplicity.
You can even run did:web and did:webvh simultaneously for gradual migration. The optional witnesses feature adds governance flexibility without forcing centralization.
Only real drawbacks: larger storage/bandwidth for the full log vs single did.json, and it’s still DNS-dependent for discovery. But for any use case needing verification method history (regulatory, enterprise, long-term signing), these tradeoffs are worth it.
> I think if the W3C standardized did:dht it could be a real contender, but somebody needs to carry the flag and demonstrate it working "IRL" with millions of users, and I suspect that will be difficult, and I would not expect bsky to lead that charge (we already have our own..)
This is going to be a tough bar. You basically need to stand up a successful decentralized social network to prove out the new DID method. I know of only one that has millions of users.🦋
Without reading the Github issue I take issue because did is an identifier and dht is way of finding information. I realize did:plc is a hash.substring(x, y) which confuses the issue but really did should be a pubkey not a strategy.
from the atproto perspective, DIDs get encoded in URIs in records across the network, so mutable DIDs aren't a thing. that means did:webvh would be a more secure variant of did:web, but would not enable migration between hosts; changing the domain part of the DID would in effect be a new account
yeah, it makes a ton of sense as a direct improvement on did:web
the funny thing with did:web that the W3C folks basically treat it as a demo / unserious method. but it *is* extremely helpful to have such a simple method in some cases! eg don't need key mgmt
it would fix the issue of hijacking did:web if domain changed hands. there would be a bunch of UX stuff to figure out depending on what domain is used.
my take is that systems which only use the SCID (like PLC) are more flexible and will work out best
to expand on this a bit more, I think PLC is basically just pure-SCID. the central directory aspect of PLC is pretty flexible/modular and i'm fairly confident will be augmented/replaced over time.
aka, the directory is just one possible "transport" for PLC ops, there will probably be others
Comments
> I think if the W3C standardized did:dht it could be a real contender, but somebody needs to carry the flag and demonstrate it working "IRL" with millions of users, and I suspect that will be difficult, and I would not expect bsky to lead that charge (we already have our own..)
there have been a couple similar proposals floating around; eg having this be part of did:web itself (!?!)
the funny thing with did:web that the W3C folks basically treat it as a demo / unserious method. but it *is* extremely helpful to have such a simple method in some cases! eg don't need key mgmt
my take is that systems which only use the SCID (like PLC) are more flexible and will work out best
aka, the directory is just one possible "transport" for PLC ops, there will probably be others