social.coop is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Fediverse instance for people interested in cooperative and collective projects. If you are interested in joining our community, please apply at https://join.social.coop/registration-form.html.

Administered by:

Server stats:

490
active users

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

(cotd...)

(cotd ...)

- Better anti-spam / anti-harassment using OCapPub ideas
- Improved privacy with E2EE ("encrypted p2p" even a better goal)

Whew! An improved fediverse?

"Uh, Christine, this sounds like a lot, do you think the fediverse can take this on?"

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.

Especially ocaps need to go bottom-up.

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

But people have to build for today too

Let's leave the ocap stuff to the side for now, then. Let's focus on what Bluesky and the fediverse have to learn from each other.

- The fediverse should adopt content-addressed storage and decentralized identity
- Bluesky should adopt real, actual federation and decentralization

For this reason @blaine says of both ActivityPub done right and Bluesky done right, "they're the same picture" (The Office meme goes here, yes)

To a large degree, I think @blaine is right

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.

"Tech problems/social problems": false dichotomy.

It's for that reason that @spritely, 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.

The vision laid out for the fediverse, both independently in my writings and even in Jay Graber and I's joint proposal... well, it's a big lift.

@spritely would like to see if we can retrofit our version onto ActivityPub. Time will tell if that's a separate thing.

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.

Maybe.

== TEA BREAK THE THIRD: BEVERAGE TRIFORCE ==

Hello, I am back again. Did you miss me? I still am not reading notifications.

Help I started writing this summary at 11am and it is now 6pm here I have wasted a whole day of work

But I have tea, and I also flossed my teeth, and it is time to resume this thread. If you are here, you know why.

What I am trying to say is I don't have many heroes but @evangreer is absolutely a heroine of mine

You should donate to @fight they are some of the only people doing sensible advocacy against terrible internet laws

Also fuck TERFs

But anyway

Also you have reached it: the third secret egg

You have now collected the egg triforce and can defeat Gender Ganon

If you want to

The power was in you all along

But let's continue.

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.

I am pro-Bluesky-credible-exit.

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.

Again, this is all tuned to "What is Bluesky trying to build?"

Bluesky might not be a good "decentralized Twitter replacement", but it is a good "Twitter replacement" with the possibility of "credible exit"

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*

What I will *not* accept is the goalposts being moved on decentralization and federation. Bluesky is neither decentralized nor federated.

If Bluesky wants to become so, it has an enormous amount of work to do, particularly in terms of architectural design.

Blogs are decentralized, Google is not.

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?

And here it is. We have reached the final part.

I am not even going to take a tea break. I am not even going to go to the bathroom. I kinda have to, but we are powering through.

We have reached the conclusion of this megathread, and "summary" of an equally long article.

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.

Christine Lemmer-Webber

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.

The infrastructure we build reflects our social dynamics, and our social dynamics are made possible by our infrastructure.

This thread has been long, and I have said everything I have to say. Thanks for listening. I hope we can build a good future for each other. 💜

@cwebber beyond epic. Thanks for everything you do!

@cwebber People build infrastructure. For example, my grandfather helped build Rt 128 near Boston, MA as a civil engineer.
People build the internet too. I'm ready to help.

@cwebber I am very much looking forward to reading this thread in full with my morning coffee tomorrow. thanks for putting in the time and energy to clear up the misconceptions around these topics. 💜

@cwebber great thread, it was an experience seeing it update in real time!

@cwebber This was a fun read over the course of the day. I would check out with your breaks and come check back in an hour or two later to continue.

Great analysis and I think you did a good job to be fair to the Bluesky folks and evenly critical of the many challenges we have here on the fediverse side.

Thank you for writing it all up.

@cwebber

many details I don't know and would take me long time to understand in detail.

The problem with collisions because of shortened hashes I know from another system too, it's indeed a bad idea and leads to problems.
Fun-fact is that different content can lead to the same hashes even in full length, when md5 is used. In general I'd assume that problem exists with sha256 or sha256d too, just with lower probability, but I'm not sure.

@DavidBruchmann A hash will always have collisions, because its output (the hash string) is much smaller than its input (binary data of effectively arbitrary size). If a hash function did not have collisions it would be a one-to-one function, and that would mean that the set of outputs would have to have the same size as the set of inputs (so they'd need to be the same number of bytes).

This is only a problem when it becomes computationally feasible to find a pair of inputs that collide (especially if you can take one given input and find a second input that collides). md5 is an example of a hash where weaknesses in the algorithm make it computationally feasible to find collisions (which it would not be if you had to guess at random). It's not my area of expertise, but I believe that no such attack is currently known for sha256 (certainly nothing remotely as effective as for md5).
@cwebber

@internic @cwebber

assumed we call archive files being hashes too, you're mistaking, as they are able not only to change the content in the kind that it's unreadable, but also to restore the initial format, despite the smaller size when it's archived.
Beside that hashes could just be a result of some cryptic algorithm, but in contrast also include additional info like length of the original content, further details in the hash would be possible to make collisions less probable.

@cwebber 🍻 cheers. This was an enjoyable read. Perfectly distracted me while I waited for my wife to finish their appointment. 😊

@cwebber This thread was the best part of my day. Thank you so much, Christine!

@cwebber thank you for taking all this time to explain 💜

@cwebber Woohoo, I made it to the end!!!
Thanks for this summary. It was a good read. 👍

@cwebber Thank you for taking your time to write this amazingly elaborate and informative thread. It helped me understand the Bluesky/Fediverse discussion a little better 👏🤩

@cwebber Thanks for such a very helpful thread. I generally prefer blogs to long threads, but I suspect the long thread was really necessary this time. I can now read the blog if I want to.

Please advise: does the blog have anything significant beyond the thread?

(I'm particularly interested in content addressable storage and decentralisation, having spent over a year on docker/OCI image relocation. We don't want CAS to be another "Google" design decision.)

@cwebber thanks for all your work here. Informative and entertaining 🙏

@cwebber now refill that cup of tea now and do nostr 🥺

Joke aside, thanks for this thread 🙏 I think the whole debate is spoiled by the lack of vocabulary, we should stop using "decentralized" and coin some more strictly defined terms 😔

@cwebber

That was a long read and i have learned a lot from it. Thank you.

@cwebber I really enjoyed this thread, including the interludes. Very much appreciated. Always Conway’s law. 💯

@cwebber Your fine thread brought this quote to mind, even before I read your concluding statement. It seems to be relavent on multple levels:
“On the night of 10th May, 1941, with one of the last bombs of the last serious raid, our House of Commons was destroyed by the violence of the enemy, and we have now to consider whether we should build it up again, and how, and when. We shape our buildings and afterwards our buildings shape us. Having dwelt and served for more than 40 years in the late Chamber, and having derived fiery great pleasure and advantage therefrom, I, naturally, would like to see it restored in all essentials to its old form, convenience and dignity.”
Winston Churchill, U.K. Prime Minister, speaking in the House of Commons, October 1943.
See the whole duscussion here, with details on how he experienced the shape of the chamber influencing his own career: (note also that he was speaking during the war, in a temporary meeting space.)
api.parliament.uk/historic-han

thank you

api.parliament.ukCommons Sittings in October 1943 (Hansard)Commons Sittings in October 1943 (Hansard)

@cwebber As a spontaneous comment to your original post: the infrastructure also shapes the social dynamics. Things we create can be actors, tying us up in networks, just like any old institution -> ANT.

@cwebber Christine, thanks for taking the time to write this thread. I read your post back when you published, and for me it solidifies that focusing on tech here might be a fool's errand (not to disparage what you're doing at spritely, which I think it is incredibly interesting).

I keep going back to your point you made above: "The tech flows from goals. So too does the social structure flow from the tech." And I'm thinking, does it really? I keep going back to the idea of separating decentralization at a technical layer from decentralization at a power level.

The parallels with email have been done to death, and you could also consider the web _itself_, and how big companies coopt standard bodies and make things like building alternative browsers a moving and very difficult target.

If power is the one thing that matters, why focus so much on the technical aspects? We have a few examples of how focusing on decentralizating power could work, like Wikipedia, or the number of Mastodon instances that operate like a cooperative.

For me it doesn't really matter if the underlying infrastructure is decentralized (which could give me an "exit" strategy) as much as the ability to collectively decide how a given service is being run ("voice" strategy).

@cwebber

Wow, Christine!

That was something!

I absolutely love your approach of appreciating the efforts of all good and capable people, despite them pulling partly in different directions.

@cwebber oh no. I only saw the end of this giant thread… I might need to read everything from the start

@cwebber I love this thread, but I do not assume Bluesky, or any effort, is built by good people trying their best. If there is one thing the past 30 years in tech have taught me is not to assume good faith, and there is plenty about Bluesky's design and it's creators, founders, investors and leadership that make me wary.

At this point all tech deserves skepticism, including in FOSS spaces, until the goals and roadmap are clear and the leadership has a track record so decisions can be made.