How Decentralized Is Bluesky Really? https://dustycloud.org/blog/how-decentralized-is-bluesky/
A technical deep-dive, since people have been asking me for my thoughts. I'll expand a bit on some of the key points here in a thread. 🧵
How Decentralized Is Bluesky Really? https://dustycloud.org/blog/how-decentralized-is-bluesky/
A technical deep-dive, since people have been asking me for my thoughts. I'll expand a bit on some of the key points here in a thread. 🧵
I participated a bit in the process of when Bluesky was Jack Dorsey and Parag Agrawal's personal project. I also believe Jack and Parag were sincere about Bluesky as a decentralized social network protocol that Twitter would adopt, which is the directive that Bluesky was given as an organization.
When Jay Graber was awarded the position to lead Bluesky, I was not surprised. To me, Jay was the obvious choice to deliver what Bluesky was being directed, and I do think Jay is an excellent leader
On the fediverse we also see a lot of accusations of Bluesky being owned by Jack Dorsey, and this isn't true. My understanding is that Jay performed an impressive amount of negotiation to allow Bluesky to receive funding independently.
These days Jack Dorsey is instead focusing on Nostr, which I can only describe as "a sequel to Secure Scuttlebutt with extremely bad vibes where bitcoin people talk about bitcoin"
Furthermore, I think Bluesky is providing something valuable: a lot of people are trying to leave X-Twitter *right now* because it has become a completely toxic place.
The fact that Bluesky's team has managed to scale to receive such users is incredible, nearly feeling miraculous.
That said, let's get to the summary: Bluesky / ATProto are not decentralized or federated, according to my analysis.
However, the "credible exit" goal is worth perusing, and does use decentralization techniques! But it is not decentralization/federation without moving the goalposts on those terms.
There is also something which Bluesky gets right which the fediverse does not. I mentioned that Bluesky uses decentralization *techniques*, and the most important of those is content-addressing. This allows content to exist even when a server goes down.
This is a great decision and I have advocated that the fediverse do so as well. In fact several years ago I wrote a demo in @spritely's early days showing off how one could build a content-addressed ActivityPub in a spec-compatible way.
First of all, before I say anything else, my goal here is NOT to be mean to Bluesky's devs. I know there's a lot of fediverse-Bluesky rivalry, but I have enormous respect for Jay Graber and her team and I know they believe in their vision!
This started because I got some very kind encouragement by @bnewbold to write something. I'm trying to be technical in my analysis, not unkind. I hope that can be recognized, really and truly.
Hey, Christine.
Did you consider that it's in Brian's and Bluesky's interest to position the difference between ActivityPub and AT Proto as one of technology and not of governance?
Also, did you think about getting your hands dirty with a proprietary protocol that has no patent or other licensing grants?
I intentionally have not done either of these things. I think Brian encouraged you to do this for his and Bluesky's own benefit.
@cwebber @bnewbold I hope Bluesky Inc. made a big donation to the Spritely Institute for this huge amount of work you did.
Calling @Chartodon
@cwebber I've read your entire article, thanks so much for such a detailed & thoughtful writeup. It was very illuminating as I had not come across any discourse yet that really got into the weeds about DID implementations and so forth. I was also not aware of your proposals regarding Ocap. This is interesting stuff I want to try to understand further. I am glad that you are thinking about these pain points with current fedi implementation, we're all feeling them and I hope they can be addressed.
@cwebber omg, I skipped all the way to the end and OBVIOUSLY you look at this situation from every conceivable angle, including governance, because it wouldn't be a Christine Lemmer-Webber post without it.
I appreciate the depth of analysis. I do still think that Bluesky should make a donation to Spritely if @bnewbold asked you to make a 25-page report, though.
@cwebber I also don't share your optimism about cross-pollination. There's a reason that W3C specifications have to only have normative dependencies on specs from recognized standards bodies. Too many minefields unless you have a clear license.
I'm glad that @bnewbold is in the SocialCG and I hope we can find some opportunities to publish reports with some or all parts of the AT Proto stack.
@evan @cwebber @bnewbold they said the big novelty check is in the mail
@evan I am glad you liked it after reading the whole thing :)
I absolutely would not turn down a donation from Bluesky to Spritely should they want to ;P but also @bnewbold welcomed and said he would be "honored" to see me write something, but absolutely did not ask me to write a 25 page document, that's just me lol
But there was too much to cover, and I felt I really could not do the issue justice without covering it from every important angle, so I did. Glad it was well received. <3
@cwebber @bnewbold I didn't read the whole thing. ☹️
Since I actively work on ActivityPub, I can't afford to introduce patented ideas into our specs or extensions, even accidentally or unconsciously.
So, I avoid reading any technical discussions of the BS protocol. I've asked Brian and Mike to offer a public patent license or to release their work through W3C or IETF which also uses a patent license. No luck so far.
Anyway, I'm glad you had fun.
@cwebber @bnewbold Anyway, I just set up my own personal monthly donation to Spritely Institute. It was a good reminder!
@cwebber @bnewbold i think stating upfront that you are trying to be kind and objective in your technical analysis, before your technical analysis, is important, because its so easy for readers to take things personally when you arent intending to do that.
it's also great for your mental health, where if someone does give u an earful, its kind of on them to realize that you put in an effort to try and be kind, and that you even considered it in the first place.
@m455 it was good!
@cwebber @bnewbold sorry for the long ridiculous reply in retrospect--my meds are most effective in the morning and it's the small fraction of the day where i dont get too much brain noise and things are clear, so im able to actually express what i mean coherently lol
@cwebber This is excellent, thank you for writing it up. It roughly matches my gut feeling from the little I knew about BlueSky's architecture, but of course with much more expertise and detail
@VamptVo 💜
@aeris if every PDS queries every PDS, that's quadratic cost on scaling
@cwebber@social.coop I read many time the paper to be sure to not miss that point, but it seems you never consider the fact that a relay is not needed and that's explicit on the AT proto documentation here
https://atproto.com/guides/glossary#relay
Relay is only optimisation a huge appview want to use, but smaller appview can directly query PDS, avoiding totally the relay cost.
" Then along came Google Reader and... friends, if you are reading this and are of a certain age range, there is a strong chance you have feelings just seeing the phrase "Google Reader" mentioned."
You got me. Great read, thank you.
@evan I am reading backwards in time but @bnewbold encouraged me to speak after I had expressed frustration about biting my tongue about things. I don't think this was for Bluesky's benefit at all and, I think you recognize this later but, tbh my article was *extremely* critical, even if polite
Bluesky folks have received it very thoughtfully but trust me I did *not* take that as a given and it could have very much so have not gone that way. I'm glad it did tho
@dthompson @evan @bnewbold lmao
@cwebber @bnewbold it's like living in the movie Memento!
Anyway, good work.
@cwebber Some notes:
(Also choosing sha256 over sha256d, there’s maybe the question of length extension attacks, but I suppose the parsing of the document means this is maybe not a problem, I’m not sure.)
So a fun thing amout merkle-damgård hash functions is that they’re only subject to length extension attacks if used at full length. If truncated they’re not vulnerable. So SHA-256 and SHA-512 are vulnerable, but SHA-224 (which is SHA-256 with different constants and truncated to 224 bits) and SHA-384 (which is SHA-512 with initial different initial constants and truncated to 384 bits) are not. Back in 2012 NIST standardised SHA-512/224 and SHA-512/256 which are similarly truncated versions of SHA-512 with different initial constants which also sidestep the length extension attack issue.
Anyway this is to say that because they truncated the hash in did:plc identifiers (to a level which feels unwise to me too!) they’re immune to length extension attcks.
@cwebber how mobile friendly is this article realy?
@perina I proofread it on my phone?
@aaravchen fixed, thx!
@cwebber FYI your mastodon account link from your blog website is still to the octodon instance.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.