The thing that is telling to me about DMs is that we *have* federated direct message protocols like XMPP which have been around for ages; if Bluesky wanted to they could have tacked that on pretty quickly, E2EE or not.

[cwebber@social.coop]

"Now wait Christine, didn't you say earlier that the web is decentralized and open? So therefore, did:web is decentralized and open"

Yeah but the naming system of the web is CENTRALIZED

We use DNS and ICANN (and then we add another centralization layer with TLS/SSL CAs)!

[jdp23@blahaj.zone]

@[email protected] for the record I’m not mad at you!!!!!!

[cwebber@social.coop]

Everyone in the DID standards space KNEW that did:web was centralized, so why on earth was a centralized identifier permitted for something named "Decentralized Identifiers"?

The answer is easy. did:web is easy to implement, many DID methods were not.

did:web existed for test suites.

[cwebber@social.coop]

I was kind of exiting that particular area of standards when this happened but colleagues will tell you that I, and some others, were deeply upset and troubled by this

"Sure having a nearly no-op DID to pass the test suite is helpful but it shouldn't be labeled as a DID, people will get confused!"

[cwebber@social.coop]

Confusion, on its own, is one thing. But the problem is when confusion turns into decentralization-washing.

"This is going to turn into decentralization-washing!"

"It's just to pass the test suite!"

[... time passes ...]

"Actually we like did:web now, it's a DID method everyone can implement!"

[cwebber@social.coop]

And of course once the door was open to did:web, the door was open to everything! Decentralization is now no longer a requirement for DIDs. You can make a centralized DID method and call it a "Decentralized Identifier" and you're right because it implements a spec named "Decentralized identifiers"

[cwebber@social.coop]

But it's ONLY EXPERTS IN DIDs WHO UNDERSTOOD THIS

Most users hear "Decentralized Identifiers" and they think they know what's being delivered, the distinction between the *spec* being called that and the *mechanism used* being centralized... you have to go digging to find that out

[cwebber@social.coop]

So did:web is not only useless, it misleads people about the problem domain entirely, but hey it's now the most broadly deployed DID method in the world, congrats everyone!

Speaking of centralized Decentralized Identifiers, did I mention that did:plc is centralized?

[cwebber@social.coop]

For that matter, where did the term did:plc come from? Early versions of "did:plc" documentation called it the "Placeholder" DID method, that's what it stands for, to motivate changing it later

Well the docs no longer say that, it now says "Public Ledger of Credentials"

Good backronymn, but...

[cwebber@social.coop]

did:plc is centralized, and that bothers me because once again, users think something is more decentralized than it is, because they're being *told* it's decentralized

The particular way in which did:plc is centralized doesn't bug me too much but once again, few users have read into this

[cwebber@social.coop]

If you read the documentation of did:plc, they're actually quite upfront about did:plc's centralization being non-ideal. That's good, I appreciate that. Again, you gotta dig though, and the name misleads (which is, to be fair, the original sin of the DID Working Group)

[cwebber@social.coop]

(aside: wow my eyes are getting tired from staring at my monitor while I recap of what was a 24 page blogpost, why do I do this to myself)

[cwebber@social.coop]

Aside from being irritated about the name misleading, I don't mind the centralization of did:plc too much (other things, I am more concerned about, we'll get there)

There's one organization that can be queried via their API that keeps a definitive list of certificate and their updates

[cwebber@social.coop]

In theory, once a DID is registered with Bluesky, it cannot be altered by Bluesky, because a cryptographic update from the original key is necessary; it's a certificate chain, a good design

Bluesky can refuse to share did:plc documents or their updates, but it can't manufacture updates

[cwebber@social.coop]

This is pretty good tbh, it lowers the stakes a lot to have certificate chains

I love certificate chains, certificate chains are great

Honestly, having a centralized registry for them, it's not the best but it's not the worst (aside from that damn naming thing)

However...

[cwebber@social.coop]

There are some strange, strange things about did:plc that heightens the centralization concerns and, well

I'm not a cryptographer, but some of my good friends are cryptographers, etc etc. I got some... reactions to what is to follow

[cwebber@social.coop]

The first strange thing to me is that did:plc uses sha256 and, AFAICT, not sha256d (which is really just running sha256 again over the hash). Unless I am missing something? Am I wrong?

Maybe it's not a concern because of doc parsing but it's best practice to protect against length extension attacks

[cwebber@social.coop]

The next concerning thing is that did:plc truncates the hash to just *15 bytes* of entropy.

I'm... again I'm not a cryptographer, but why throw away all that delicious entropy? So the did fits in 32 characters? Weird choice, and it means collisions are cheaper

[cwebber@social.coop]

This is public information, I don't need to file a CVE to tell you about the truncation of entropy. I am, again, not a cryptographer. Maybe it's fine?

I do remember the Debian short IDs fiasco tho https://gwolf.org/2016/06/stop-it-with-those-short-pgp-key-ids.html

Why not hold onto all the entropy you can get?

[cwebber@social.coop]

DIDs weren't meant to be seen by the user; cryptographic identifiers in general *shouldn't be*, they should be encapsulated in the UI.

We'll get to UI stuff in a bit.

I just don't understand this decision though, it just seems weird to me but maybe a cryptographer will tell me it's fine, actually