Back

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

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

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

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?

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

At any rate, I continue to not understand it, maybe it's fine, but it did play a part in that "Hijacking Bluesky Identities with a Malleable Deputy" blogpost, which is fascinating and, unlike me, is written by a Real Cryptographer (TM) https://www.da.vidbuchanan.co.uk/blog/hacking-bluesky.html

Good post btw

One way in which the truncation shows up in that blogpost which I thought was curious is that the attack involved generating a *longer* truncated hash

The fix ended up resulting in codifying the hash length: 24 characters, and no longer https://github.com/did-method-plc/did-method-plc/pull/31

There's another thing about that blogpost that caught my attention. I will just quote it:

> However, there's one other factor that raises this from "a curiosity" to "a big problem": bsky.social uses the same rotationKeys for every account.

> This is an eyebrow-raising decision on its own; apparently the cloud HSM product they use does billing per key, so it would be prohibitively expensive to give each user their own. (I hear they're planning on transitioning from "cloud" to on-premise hosting, so maybe they'll get the chance to give each user their own keypair then?)

Anyway that's the quote and presumably this must be changed. I haven't looked, but I can't imagine they're still doing this today (are they?) but the fact that only one key was ever used in production for expense purposes is a strange decision

At any rate, that decision was used to create a kinda confused deputy-ish attack, which is why it came up in the blogpost, and anyway, hi, I'm not a cryptographer, momentary reminder that I am not a cryptographer, but I have designed cryptographic certificate chains and I was pretty shocked by that

At any rate, one way or another, you can presumably use did:plc to move yourself from one server to another so in the interest of "credible exit" this is a good choice

Though, one might take a moment to ask: who controls the keys if you *do* want to move?

Bluesky has identified, I'd say correctly even, that key management for users is an *incredibly* hard thing to do.

But the solution, once again, ends up pretty centralized: for all users on Bluesky's main servers at least, Bluesky generates and manages the keys for them.

I am, once again, kinda sympathetic and kinda unsettled simultaneously.

- Sympathetic: key management *is* hard and we just don't have the UX answers to solve that, and Bluesky is once again trying to deliver to Twitter refugees
- Unsettled: it's centralized, but... there's something *more* troubling

The big promise here, the "credible exit" side of things is that for most users, the vision they have is that if Bluesky gets bought by a big evil company, no problem, move somewhere else

But for those same users, Bluesky still *controls their keys* and thus *controls their destiny*

Regardless, Bluesky has this "your domain is your id!" thing, and that's pretty cool, the domain maps to your DID and your DID maps to your domain

Well, I'm not gonna get into this in detail here, I do on the blogpost if you wanna read it but, the cyclic dependency might be an actual cycle

tl;dr on that UX part:

- users only know domains, they don't know the DIDs
- turns out that's a phishing attack when those can change at any time
- if bsky.app ever goes down how do you actually know I *really* mapped to that name
- and a whole lot of "liveness" problems that enter there

in addition to this long-ass thread there is a long-ass article and if you care about things like "zooko's triangle" maybe read that version, the rest of y'all can move on we've got other stuff to cover here

It is time for TEA BREAK 2: THE REHEATENING

I will also go to the bathroom

TMI? If you've read this far into this weird thread I am already giving you too much info

=== TEA BREAK 2 ===

"Where are we going with this Christine?"

Well you could have just read the blogpost but 3 more sections remain, we are approximately 2/3 there

I know, bear with me, what is left is:

- What should the fediverse do?
- Preparing for the organization as a future adversary
- Conclusions

Yes, I changed the order of the remaining sections, not from the blogpost but from the last time I said what was left on this thread

pray I do not reorder them again

Before we get into the next section, earlier I left an easter egg, which you could reply to and say "I found the easter egg" or something

Now you can put 2 eggs

I 2 was once an egg

(Look I specifically transitioned so I could never be accused of making dad jokes again so that does not qualify)

Alright you've heard enough critiques of Bluesky for a bit and I SAID I was gonna critique the fediverse and I am a WOMAN OF MY WORD

So let's get into it!

I have actually critiqued ActivityPub and the fediverse a lot! I have kind of never stopped critiquing it, ever since the spec was released. There's a lot that can be improved!

I have even gotten criticism from AT LEAST ONE ActivityPub spec author for critiquing AP-as-deployed but I do anyway

Actually something that is funny about ActivityPub is that there's "ActivityPub the spec", which I think is pretty solid for the most part, and "ActivityPub-as-deployed"

Many of the critiques I'm about to lay out we left holes in the spec for which I hoped would be filled with the right answers

One thing we have already discussed so, before I will say anything else, I will repeat: content addressing is really good, and I'd like to see it happen in ActivityPub, and it's *possible to do*, I even wrote a demo of it https://gitlab.com/spritely/golem/blob/master/README.org

Bluesky does the right thing here, AP should too

Content addressing is important. It should not matter where content "lives". It should be able to live anywhere.

A server should be able to go down, and content should survive.

Go content addressing!

Actually with this and several other things I am going to bring up, I actually made sure there was space to do things right: there was a push to make ActivityPub "https-only"

I pushed back on that, I didn't want that requirement, and it was exactly for this reason: enabling content addressing

This isn't the only time I left a critique of ActivityPub-as-Deployed as opposed to ActivityPub-as-it-could-be: see also OCapPub, which critiques the anti-abuse tools of AP as inadequate and leading to "the nation-state'ification of the fediverse" https://gitlab.com/spritely/ocappub/blob/master/README.org

Oh, and ocaps!!!

ActivityPub left giant holes in the spec around two things which sound the same but which are not the same: Authentication and Authorization

Trying to mix these two, you accidentally get ACLs, and then you get confused deputies and ambient authority, plagues of the security world

Anyway, if you know *anything* about me, you know I am a big fan of capability security (ocaps) and that's the foundation of our work over at @spritely

But we will come back to ocaps in a second because it turns out OCapPub is not the only time I proposed AP + ocaps!

The other time I wrote about ActivityPub + ocaps was in a proposal to, yes, Twitter's Bluesky process in 2020 with Jay Graber titled... "ActivityPub + OCaps"! https://gitlab.com/-/snippets/2535398

I think that document laid out all the right ideas for *the fediverse* (not saying bsky, the fediverse)

Now I want to be clear here that I *don't* think that proposal was necessarily the right one for Bluesky, and I *do* think Jay Graber *was* the right person to lead Bluesky

What I wanted to do required a lot more research, and we have done that over at @spritely instead

The reason I bring up the proposal here is that I think it has all the right analysis of *what the fediverse should do*, if it was going to rise to the challenge of fulfilling its true potential

So let me lay out what the things in that proposal were:

Here is your recipe for making the "Correct Fediverse IMO (TM)":

- Integrate ocaps, which is possible because actor model + ocaps compose
- Content addressed storage!
- Decentralized identity (notice the *y*, I did not say DIDs) on top of ~mutable CAS storage
- Petname system UX

(cotd...)

(cotd ...)

- Better anti-spam / anti-harassment using OCapPub ideas
- Improved privacy with E2EE ("encrypted p2p" even a better goal)

Whew! An improved fediverse?

"Uh, Christine, this sounds like a lot, do you think the fediverse can take this on?"

Spec-wise in ActivityPub, I think it's possible. The ecosystem, as deployed? I think the ecosystem can and will only do part of it, if we really get everyone excited, maybe the content addressed storage and decentralized identity parts, in which case the fediverse will also survive nodes going down

The ocap stuff, I tried getting fediverse implementers excited about this and tbh, it's pretty hard to design into a Ruby on Rails or Django style framework and mindset. Backporting the right designs to existing systems is a real challenge.

Especially ocaps need to go bottom-up.

For this reason, @spritely's tech looks like it's very focused on computer science'y low-level BS, but that's actually because it's *too hard to build the systems I want right now on top of current technology*, we need stronger foundations

But people have to build for today too

@ColinTheMathmo

Your chart is ready, and can be found here:

https://www.solipsys.co.uk/Chartodon/113528811692603804.svg

Things may have changed since I started compiling that, and some things may have been inaccessible.

In particular, the very nature of the fediverse means some toots may never have made it to my instance, in which case I can't see them, and can't include them.

The chart will eventually be deleted, so if you'd like to keep it, make sure you download a copy.

@fanf42 @soatok It's linked in the blogpost!

@cwebber @soatok :) I confess I didn't read the blog post yet :)

@erlend @cwebber This is actually the one thing that I hadn't figured out how to do on top of the #willowprotocol yet. but I really want to find a way to do it eventually. I think it's tricky so we'd need a good protocol / algorithm for it I think.

Currently we're just using public keys as identity which can be resolved through domains.

The rest of it is all stuff we've already got or that we're working on, other than the fact that we aren't using OCaps exactly because Willow has Meadowcap.

@zicklag @erlend @cwebber

Erlend and Zicklag, you both know already that @nextgraph is implementing just that (Decentralized identity on top of ~mutable CAS storage) among other things, and will be compatible with ActivityPub thanks to the collab with @activitypods .
So at some point it would be nice to recognise the efforts done by others, specially since I am trying to reach out to everyone in the field and build cooperation and collaboration (and I am mostly ignored so far)

@nextgraph @zicklag certainly!

Zick is currently in the process of drafting a blog post in response to Christine’s ‘Correct Fediverse’ outline in the context of Leaf.

You’re in a great position to do the same for NextGraph, with the added bonus of being innately AP compatible!

Nomadic Identity is complicated and many separate ventures are saying ‘we do this’. Such statements need to be accompanied with explanations of the flows and trade offs involved, as that makes all the difference.

@slothrop @cwebber Well, she has insider knowledge and must be using the secret hidden deluxe threading proto.

@dottorblaster yes the agent and the book are both called "my blog"

@Canageek yes

@cwebber That was 100% a Mom joke then