How Decentralized Is Bluesky Really?

[cwebber@social.coop]

If "message passing" is like "mail comes to your house", a "shared heap" system works differently

In a "shared heap" system, all the mail gets dumped at the post office, and in the most naive version, you go over there and read through every single piece of mail to see which one is relevant to you

[cwebber@social.coop]

There is no "directed delivery" in a "shared heap" system, which means you are stuck with two things: either a "god's eye view" (Bluesky) or "even lossier about replies than ActivityPub" (Secure Scuttlebutt/Nostr)

[cwebber@social.coop]

The Bluesky approach to the "shared heap" is that *everything* goes into the big, centralized shared heap. Bluesky takes a "god's eye" view: it knows everything, and so knows what all your replies are, and can give you perfect search.

Secure Scuttlebutt / Nostr... well long story. Lossier, I'll say

[cwebber@social.coop]

You can imagine the physical world version of "message passing" already because you already live in this world. Messages come to your house or apartment building or whatever

For Bluesky's "shared heap" architecture, you'd have to build a whole addition to your house for everyone's mail

[cwebber@social.coop]

That's exactly why running a Relay or AppView is expensive: you're building an addition to your house for all the world's mail.

Eeep! That ain't cheap. That's why I'm saying: decentralization also means the ability to *scale down*.

[cwebber@social.coop]

Look, I know that I've been hitting this nail on the head for a while but: the web is open, blogs are open, but Google isn't open

But you could run your own Google, in theory. You could index the web. So why aren't you?

Ah yeah. Same thing here. That's what I mean, that's why it's centralized

[cwebber@social.coop]

Now as I have said, this is a *design decision*. And remember: most users of Bluesky really *don't care*. Decentralization is not their focus, they're trying to get the hell off the nazi hellscape that Musk's toxic reign of Twitter has become.

Bluesky's architecture, actually, is great for them.

[cwebber@social.coop]

If what your *goal* is to get off Twitter, then Bluesky has solved it. They solved it by building another Twitter, and this time it's open source, which is cool! And it might have this "credible exit" thing.

But god damnit it's not decentralized and it's not federated stop TELLING people that

[cwebber@social.coop]

"Oh Christine you're being sensitive"

Maybe, but there are real consequences to this. What if Bluesky/ATProto fails? "Oh well we tried decentralization and that didn't work." If people think something is something that it isn't, then that's a real problem.

[cwebber@social.coop]

Users, clearly, think a lot more of Bluesky is decentralized than it is, and realize less of the consequences than they should. This really worries me. Blocks and DMs are both great examples of this.

[cwebber@social.coop]

Blocking first. Bluesky's decision to have *everything* public means that it is expected that every participating node knows *everything* about who's blocking *everyone*.

"This is consistent with how blocking works on Twitter/X" their paper says

But wait, I'm pretty sure that one's not true though

[cwebber@social.coop]

It is ONE thing to be able to block JK Rowling and for you to see that JK Rowling is blocking you.

It is an ENTIRELY DIFFERENT THING for ANYONE to see who is blocking JK Rowling and who JK Rowling is blocking

This one is shocking to me: this seems like a vector for abusive actors

[cwebber@social.coop]

Now to be completely fair this is something that Bluesky's devs are interested in potentially changing: there is an open issue to discuss the possibility of private blocks https://github.com/bluesky-social/atproto/discussions/1131

What I am saying is there are architectural consequences to fundamental design abstractions

[cwebber@social.coop]

Yes, I may sometimes seem silly over here, SICP-hugging fangirl, come on we're just trying to build things that *work* over here

Look I'm a lisp lady, I know the realities of "Worse Is Better" more than most, I now the right CS designs don't win

But Conway's Law flows in two directions!

[cwebber@social.coop]

You know what, we'll come back to "bidirectional Conway's Law", let's talk about Direct Messages for a minute because I think those are telling

Direct Messages in Bluesky, wait how do they work if ATProto is public?

Did you guess?

DMs are centralized! All DMs flow through Bluesky

[cwebber@social.coop]

Now to be completely fair Bluesky is clear about this *in their blogpost announcing DMs*, but just like this thread, I doubt nearly anyone has read that far (am I talking to the void? I don't know, if you actually have gotten to this message reply with "I found the easter egg" or something)

[smallcircles@social.coop]

@cwebber fabulous! Stuff to

You mention "Message passing" vs "shared heap" architectures and it occurred to me how fast this shift to pioneering in "decentralized/distributed solution design" space and entering entire new computing paradigms currently is.

Where once more tech is running way ahead of responsible use. Technically all is possible. Reality is we stumble ahead, no best-practices, impl on-the-fly.

We take as it were big bets on future direction, may overlook externalities.

1/..

[smallcircles@social.coop]

@cwebber

Not only are the implications of the BS shared heap architecture easily overlooked and consequences come later, this has been the de-facto approach for any decentralized web technology thus far, including AP. Where hard-tech mindset and focus dominates.

And yes, the complexity warrants all that attention.

Yet there's less thought and attention payed to how DX, UX system / application / solution design should cope in the higher levels of the stack, and esp. in FOSS circles.

2/..

[smallcircles@social.coop]

@cwebber

Making it extra hard to bridge the technology adoption chasm beyond early adopters, while the decentralized ecosystem suffers protocol decay.

Re:new computing paradigms.

> "local-first p2p social networking at scale"

.. someone said.

That buzzwordy sentence might see us enter a new exciting social web of adventure, if we don't squander the opportunity.

Technical all is once again possible. Martin Kleppmann inspires with generic local-sync protocols, universal back-ends, etc.

3/..

[smallcircles@social.coop]

@cwebber

But thinking about exploring technical possibilities is way out of lock-step again, speeding ahead of how one would use this shiny technology to build useful things on top of in the best possible way.

I have difficulty wrapping my head around picturing a local-first social network at scale where CRDT's p2p synchronise application state and data of all actors - people, apps, services - in the social graph between 1,000's of peers. So many options, what approach is even feasible?

4/..