Gregory's ServerThe 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. It still would have been decentralized at least
|
268 comments
 But to Bluesky's credit, Twitter's DMs aren't decentralized either! And getting and shipping something that works, now for the influx of Twitter users, again... I am sympathetic Bluesky's team is doing an INCREDIBLE JOB in that way of scaling to meet the incoming stream of Twitter refugees On that note, again, I am not reading the replies right now because I am (a) afraid to and (b) I'm never gonna finish this and we are a bit over HALFWAY THROUGH the analysis but I have this fear that EVERYONE is mad at me, Bluesky fans, fediverse fans I am trying to be analytical. I am trying!!! I said we are about halfway through and criminy we're halfway through the afternoon, I need a break to get some tea We have a few big topics left: - Decentralized identity, how does it work (magnets too, yes) And so, it is TEA TIME Go get yourself a hot beverage. Put honey or agave in it, if you like. Dairy, or perhaps, non-dairy, if you prefer. === BREAK TIME! Time for tea! === I can confirm, @cwebber is currently making us both tea :) @mlemweb Thank you for corroborating my story  Okay, I am back and I am back with tea! I made "black tea with ginger" and I put some whipped honey in it. I also made tea for my spouse I am drinking out of an oversized mug from @baconandcoconut that says "I'm that person who likes to serve on open source program committees", which is not actually accurate but I do anyway I am also sad about the US House of Representatives being shitty to trans people who work there and are just trying to make it through the day I used to do data modeling contracting for the US HoR on our legal system, true story, which sends me back to a time when I did a lot of data modeling  The house should ditch men's and women's restrooms and switch to republican & democrat restrooms. A lot of data modeling I did in that time was in the W3C Verifiable Credentials group that was working on Verifiable Credentials, zcap-ld (my spec), and, oh hey, Decentralized Identifiers (DIDs, the name is not my fault) So actually I was pretty excited when I heard that Bluesky was gonna use DIDs! Back in 2017 I wrote a whitepaper: "ActivityPub: from decentralized to distributed social networks" and it also suggested using DIDs https://github.com/WebOfTrustInfo/rwot5-boston/blob/master/final-documents/activitypub-decentralized-distributed.md I no longer think DIDs are necessary to solve this, but then and now I think *decentralized identity is important* In that sense, I am really glad Bluesky is taking on decentralized identity, as a concept! And DIDs, in a way, are a good signal. But there are several problems, the first of which is: Bluesky supports two kinds of Decentralized Identifiers and they're both -- you guessed it -- centralized! Before we get there, let's talk about what the DID spec was and what DIDs are. The core DID spec is an *abstract interface* for key management which provides a way of representing keys (and some other metadata) which can be created, retrieved, and updated/rotated. So far so good... The other requirement you would expect, based on the name, is that Decentralized Identifiers are *actually decentralized*. When I got involved in DID work, that was actually the expectation of everyone. Then it was loosened. What? Why on earth?! The reason actually stems from the first centralized DID method that Bluesky supports: did:web. did:web is centralized, and kinda useless. It just works by a regex rewrite of the DID's name to an https URI and then it's retrieved. Anywhere you use did:web, you could have just used an https: URI "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)! 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. 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!" 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!" 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" 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 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? 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... 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 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) (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) 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 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 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... 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 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 Hey Christine, big fan of your work, but holy yapfest. World record for longest fedi thread??  @cwebber I remember reading about DIDs a few years ago, even did a Norwegian language podcast episode talking about it @cwebber break time? :shibalaugh: I think you invented a new thing there, but understandable  @jonbro@friend.camp @cwebber@social.coop Bluesky's credible exit refers to the ability of another organization to host the network, including user data and posts, without needing any special access or OK from the Bluesky foundation (I think). This should be a laudable goal, but its feasibility remains to be seen.     @cwebber i'm just very glad that you're dispelling the myth that bluesky is federated. i'm so tired of being told on bluesky that fedi isn't safer than bluesky because bluesky is federated so if they fuck it up people can take their stuff and go elsewhere, when it's like "how? go where?"  @cwebber I have been an XMPP fan for ages, and find it really frustrating that due to networking effects (of the social kind) everyone non technical is hooked on WhatsApp and how good and useful it is (and it is, I use it, but reluctantly), when the concept of Instant Messaging is good and useful. I am very concerned about Who pays for WhatsApp . People assume the WhatsApp fairy. |
The point is that I have *seen in the wild* people saying "Oh yeah Bluesky added DMs to their decentralized protocol" and augh
I know they aren't claiming this but it's very clear to me that people are reading things as being completely different architecture than it is