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 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
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
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
Shouldn't this be 20 bytes? There are 32 characters, and each character is base32, or 5 bits. So 160 bits?
I don't *think* there's a huge concern over this, because while maybe you could do a birthday collision attack in 80 bits, this wouldn't really get you much and wouldn't let you take over someone else's account. For that you'd need a pre-image attack on the whole 160 bits.
> 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*
- 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
I am still not reading notifications. Well, I have seen a few fly by on the fediverse which is blipping and blooping nonstop in the Mastodon UI so people are clearly reading it there
Bluesky says "30+". How big is the +?? I will resist temptation to look and assume "31"
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
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
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.bsky.team 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
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.
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
Of course, adapting an existing system as deployed isn't easy.
I will say though that I think if Bluesky were to become *actually decentralized* it would look a lot like ActivityPub in terms of having directed messaging. This will also introduce similar challenges around eg replies, etc.
To the end of the fediverse, perhaps I sound bitter, "they didn't adopt ActivityPub the way *I* saw it!"
The truth is that Mastodon didn't, but Mastodon also saved ActivityPub. It then painted a vision of the future that wasn't, at least, what Jessica Tallon and I expected of it. But it saved AP.
The fediverse and Bluesky, at great effort, could learn a lot from each other in the immediate term.
In the longer term, neither is implementing the ocap vision I think is critical for the big vision, and in a way, I think maybe neither can be easily rearchitected to achieve it. Well, not yet.
When I laid out the ideas of OCapPub to various fediverse developers, the response was "this sounds cool but I have *no idea* how to retrofit a Rails/Django app for this kind of actor-oriented design".
And they were right.
Remember when I said Conway's Law flows in both directions?
Conway's Law says that a technical architecture reflects the social structure under which it was built. But the reverse is also true. The social structures *we can have* are made possible by the affordances of the tools we have available.
It's for that reason that @spritelyinst.bsky.social, while aiming for a *socially collaborative* revolution, is first focusing on a *technical* revolution.
It's too hard to build massively, securely collaborative tools right now. With Spritely's tools, p2p ocap secure tech is the *default output*.
Remember when I said that IMO @jay.bsky.team is the right person to lead Bluesky and that I am sympathetic with many design decisions of Bluesky (even if critical of them for being non-decentralized)?
Bluesky is building what they can for a scale big objective. The tech flows from goals.
So too does the social structure flow from the tech. It does on Bluesky, and it does on the fediverse.
I won't elaborate further on this, I actually would like you to pause and think about it. In which ways are tech and social systems bidirectional, here and otherwise? It's important.
And perhaps this is all my *massive* Cassandra complex speaking. I won't deny that I have one, for better or worse
Still, despite all I have said about both Bluesky and the fediverse technically, it is because I want a hopeful direction for all of us. Secure collaboration. More important than ever.
Let's take another tea break. (And another bathroom break. This teacup is massive.) We're getting close to done, I promise. Just two sections left, they're both much shorter.
Then I can finally brave reading my notifications.
It's time, we have reached the second to last section: "Preparing for the organization as a future adversary."
I love this one because I love that phrase, and the best part is that the Bluesky team came up with it, "the organization is a future adversary". It's genuinely good and self reflective
Occasionally an org creates a phrase like this, and back in the day Google had "Don't be evil"
And yeah, people criticize Google for never having been sincere but it gave an opportunity for people inside and outside the organization to critique Google on its own stated values. That was good.
It was *at least* good insofar as the moment Google retired the phrase as never really meaning anything anyway, as evil as Google may have been before, Google got *noticably* worse.
To Bluesky people internally: keep that phrase going as long as you can, and use it reflectively.
As opposed to Google's "Don't be evil", a commandment for the everpresent, "the organization is a future adversary" acknowledges the realities of the future, that it is uncertain, and in fact, that power-dynamics-wise, there will be pressure to make things worse.
Making design decisions in the present which guard against the future is one of the most important things we can do. It is one of the most important reasons to choose FOSS licenses, for instance, which provide an exit plan and also counterbalance against temptation to enshittify a project.
To this end, Bluesky's goals of "credible exit" are actually very important. It creates a similar pressure for the organization itself to stay true as long as it can, even acknowledging the organization as a future adversary, and actually preparing for it.
And there *will* be a lot of pressure: Bluesky has taken VC money as investments; the pattern of such is that early on, things are very good and flexible, and after some time, the investors start placing pressure to enshittify.
I have seen good peoples' orgs clawed from their hands. It happens.
This happens despite the very best people with the very best intentions. Talk to early Twitter co-founders and they will tell you the org that things became was not the org that they envisioned.
A future adversary indeed. So we should plan for it today.
Before we continue further, I have done about every job imaginable in a FOSS project/organization. Fundraising, by far, is the worst, and the most stressful.
It's incredibly hard to raise anything to do anything. I think that's worth acknowledging.
The structure of an organization does matter. There's a reason that @spritely is a 501(c)(3) in the US. Any money we take in is a donation: we aren't "delivering on an investment" (though we must deliver on *results*)
Bluesky is a Public Benefit Corporation, also interesting
A Public Benefit Corporation has a mission for the public good, but can take investments in the way a nonprofit cannot. This also means it can move much faster. Given the influx of users to Bluesky, taking investments this way may have been the only load handling route available this fast.
That Bluesky is providing needs for many users who are looking for refuge from a white supremacist site *today* is something to pause and acknowledge the difficulty and scope of doing so quickly and in the moment. I'm glad Bluesky is here at this stressful geopolitical moment in history.
There will be a lot of pressure soon from investors: run ads, make premium accounts that do not actually make sense in a decentralized way, so on and so on.
In this way, "credible exit" is the most important thing for Bluesky the organization and its community to push on *today*
Bluesky will face every pressure to be enshittified. Bluesky has even, correctly, acknowledged this. It is up to Bluesky and its community to rise to the challenge of "credible exit" knowing that this is a likely, perhaps inevitable, risk.
The org is indeed a future adversary. So what now?
I laid out definitions of "decentralization" and "federation", and Bluesky meets neither, without major rearchitecting or moving the goalposts on those terms, which I cannot accept.
However, "credible exit" is a good goal for Bluesky. Bluesky created that term and it's a good and feasible goal.
I laid out a strong critique, but let me end on a call to empathy.
Bluesky is built by good people, and the fediverse is built by good people. Neither reflect the designs I presently would like to see today, but ultimately these are built by humans trying their absolute hardest.
its just a question. i have rarely seen such long statements and i just wonder 🙂
i am not disagreeing with what she said, but it is long and way too polite imho.
apart from that, the connection i can see is spritely cofounded by randy farmer, friend of chip morningstar and mark miller and ocap being used in agoric, which is chip morning star and mark miller... built on top of cosmos, which is web3.
Bluesky is web3 as well as stated by the CEO of bluesky, thus - same
Why give them soooooo much space? Why talk soooo much about bluesky?
Did they pay you for it? I havent seen you do this for other platforms, especially when mastodon and even nostr exist that are way more decentralized. It seems kinda weird and unexpected 🤷
@cwebber i skipped replying to the second egg, because I had no idea how far I was going to continue scrolling. Now I still have to roll back to find some links and then on to the 24 page blog post (I'm not entirely certain if that can be a thing)
bluesky can be bought. mastodon cant, but federating with the big corporate backed ones and lobbying, maybe buying big instances allows big money to defederate with small instances, cutting off the vast majority of big instance users from the rest.
it is the same power gmail and other big ones have over small email providers.
they can filter/block you from talking to the users on big email providers, making is slightly inconvenient for those, but unusable for independents
@serapath@cwebber The sign in experience and finding or following people on mastodon or fediverse is not a good ux. It’s a subject matter for many people. May be not for you. And you really think mastodon can’t be bought? Hypothetically what happens if musk bought mastodon.social?
@serapath@cwebber Why not give them space? Bluesky is the best social networking site currently for most people. Why are you even thinking that she’s got paid for it?! I use bluesky and it’s a very well designed platform. Most people should use it instead of twitter. No platform on the fediverse that i know has a user-friendly design. For a large flux of users bluesky is best suited for them and its ok to talk about them!
oh maybe because they are run by musk and zuck? ...twitter wasnt until it got bought and that can happen to bluesky as well. they will also add ads, they already announced. enshittification is guaranteed.
UI/UX on mastoson is great. tou say the vluesky one is better? thats really subjective. ...so kinda decentralization matters when it comes to FB and X ...but once it comes to nostr/blsky.. then its UX?
@serapath@cwebber So suppose a journalist or an artist who has thousands of followers and years of content here on mastodon just move? What about the content?
@cwebber Hey, for what it's worth. @bengo and i are working on exactly that for the Fediverse! We've got the FEPs written, a content-addressed zCap powered storage backend MVPd, and are now working on fedi integrations!