How Decentralized Is Bluesky Really?

[cwebber@social.coop]

So hold on, let me set some terms for "decentralization" and "federation" that I think are reasonable.

> Decentralization: the result of a system that diffuses power throughout its structure, so that no node holds particular power at the center.

Pretty reasonable. Do you agree? I hope so!

[cwebber@social.coop]

Okay how about "federation" now because this is a *technical term* that the *fediverse has established* and I'm kinda PO'ed about the goalposts being moved on this one.

A lot of people coming to Bluesky have never heard of "federation" before in a social network so listen up this is important!

[cwebber@social.coop]

Here's my definition of federation:

> Federation: a technical approach to communication architecture which achieves decentralization by many independent nodes cooperating and communicating to be a unified whole, with no node holding more power than the responsibility or communication of its parts.

[cwebber@social.coop]

Now historically, federation has been achieved on the fediverse via "message passing". Actually, this is to the degree where I just always associated message passing with federation, but really, federation is about the distribution of power, creating an abstract whole in a sea of autonomy.

[cwebber@social.coop]

Maybe there is another way to achieve federation, but it's about the power dynamics. It's a technical immersion of power dynamics, the flow and interchange of cooperation between many parts.

So you may say, well, doesn't ATProto have that? After all, messages flow through the different parts!

[cwebber@social.coop]

ActivityPub, as it turns out, follows the actor model of computation. Okay, many people implementing the fediverse don't know about the actor model aspect of ActivityPub but I am here to tell YOU, dear reader, that it is an important thing, not a detail

[gaelan@cathode.church]

@cwebber I question the assumption that a relay needs to store the entire network to be useful. Just gathering every reply/like/follow/etc that mentions one of my posts (and perhaps the posts of people I follow), and throwing everything else to /dev/null, would already be hugely useful, and if things are storage-bound (as sounds the case) might be dramatically cheaper.

(To be clear I broadly agree with you here, but seeing as all my friends seem to be ending up on bluesky I've done a lot of thinking about how I can be On There as independently as possible)

[cwebber@social.coop]

I'll take one more note about federation which is that often time the message passing mechanism of the fediverse is often called "federation", but theoretically another mechanism could exist, but I'm actually not so sure of that.

There's a reason the actor model and the lambda calculus are undying

[cwebber@social.coop]

Oh god Christine said "the lambda calculus" did you know she's into lisp and functional programming, what's she going to talk about next monads?!?!

I am not going to talk about monads. Not TODAY

But we do need to get a better architectural idea of how these systems work because it matters a lot!

[cwebber@social.coop]

So let me introduce two models of communication which we can use to analyze these two systems. It's important!

- Fediverse/ActivityPub: "message passing"
- Bluesky/ATProto: "shared heap"

Okay, cool, terms established, let's talk about them and why they matter because they matter A LOT

[cwebber@social.coop]

"Message passing" is what ActivityPub uses. It's "like email", people say, and that's true.

Actually it's even a lot like physical mail. You write a letter, you say where it should go, it gets delivered to your house.

Message passing. The world runs on it.

[cwebber@social.coop]

Now I can use message passing to send a message to you *directly* and indeed, that's "like email". For one-to-one correspondence, that's enough.

But it's not enough for a followers/following type mechanism. But we can build it on top! Thank *you* computational abstractions!

[cwebber@social.coop]

On top of "message passing" we will build "publish-subscribe" as a second-layer abstraction

"Your ideas are interesting and I'd like to subscribe to your newsletter."

You send me a letter saying you'd like to hear the things I have to say, okay, you're part of the reader list. That's how it works.

[cwebber@social.coop]

On top of that we can build even more abstractions and the net result is that this is how federation works in pretty much every "federated" system I know.

ActivityPub does some extra work to help you see replies on a thread, think "letters to the editor". This is a bit lossy sometimes though

[cwebber@social.coop]

It's true that sometimes users click over to a thread and see some replies but not all on their instance's UI. There's things that could be done to improve it, but it's sometimes mildly confusing, but not so bad, and you can click over typically to see whatever else is happening, and people learn to

[cwebber@social.coop]

I actually think this is improvable but I mostly don't care because this isn't as big a complaint as people tend to think it is on the fediverse, the other concerns like "what instance do I pick" tend to be bigger and "oh no my server went down"

That can be improved, we'll talk about that later

[cwebber@social.coop]

So okay, the federation is "message passing" and like email, or physical mail. You have an idea how it works.

Now we need to get to that other thing, a "shared heap" architecture. What on earth does that mean?

[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