How Decentralized Is Bluesky Really?

[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/..

[smallcircles@social.coop]

@cwebber

Meanwhile there are already hundred or more local-first projects and vendors who are independently building "the right way", in other words fragmenting into indvidual explorations with little cross-pollination and co-creation.

Why isn't there already an IETF local-first working group, or something similar?

Well.. someone should step up to the plate to do that, that's the wait now. Lotta work for volunteers and no funding beyond hard-tech. So this is up to vendors then, I guess.

5/..

[smallcircles@social.coop]

@cwebber

Unrelated to this thread it occurred to me how much time and energy we waste by endlessly sifting through untangled mess of complexity with different viewpoints and perspectives leading to Babylonian confusion and overlap all the time in discussions.

Bluesky had a big advantage, in that they could forge ahead, highly focused as a close-knit team exploring greenfield technology. They set sail, just tapping the chaotic information stream for collecting stakeholder feedback.

6/..

[smallcircles@social.coop]

@cwebber

Now if we look at AS/AP ecosystem, there is a problem as the storm of discussion on vNext of the protocol or choosing alternative directions, goes on unabated, and no one seems to be coming to any kind of real consensus.

It almost looks like we once again must leave that to the vendors to sort out, when they enter the 'fedi market' en masse.

Ideally we want to have multiple commons-controlled focused and productive working groups that elaborate various themes of the social web.

7/..

[smallcircles@social.coop]

@cwebber

Thus I had the idea to write a proposal to start, what I call, a fellowship that runs an open social web laboratory, and is able to separate the general discussion to focused input for working groups to quickly iterate on a theme, in a similar way to how BS operates now.

See for info: https://discuss.coding.social/t/proposal-start-a-fellowship-to-explore-the-social-web/571

The idea is follow-up to "Vision for fedi spec" feedback gathering that @helge initiated, as a means to cope with the broad subject area.

See: https://discuss.coding.social/t/wiki-vision-for-a-fedi-specification/563/24

/end

[smallcircles@social.coop]

@cwebber @helge

Tangential, but to add some more spice to this..

We need more fellowships like this, who explore yet other areas together.

Like for object capability social web at scale.

A couple of years ago, when you were still on Spritely Project, you sent out a toot out in which you sighed that once spritely technology would be mature enough for widespread use, it would probably be already too late.

The institute to the rescue, I guess. Valid and prudent choice.

1/..

[smallcircles@social.coop]

@cwebber @helge

It is still hard to hook on to spritely unless you have deep technical expertise. That means most others (large group) are in wait-and-see necessarily.

Choice is perfectly valid, because its the foundation team's own initiative.

Is it the best tech introduction strategy? Best technology adoption model to use?

Your community and ecosystem have to catch up, once you say "it's time for fun".

Randy's community pattern language might serve to unlock upper-stack stakeholders now.

[evan@cosocial.ca]

@cwebber @bnewbold

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?

And to get the editor of AP to do it?

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.