I have returned, with tea

[cwebber@social.coop]

Anyway, if you know *anything* about me, you know I am a big fan of capability security (ocaps) and that's the foundation of our work over at @spritely

But we will come back to ocaps in a second because it turns out OCapPub is not the only time I proposed AP + ocaps!

[cwebber@social.coop]

The other time I wrote about ActivityPub + ocaps was in a proposal to, yes, Twitter's Bluesky process in 2020 with Jay Graber titled... "ActivityPub + OCaps"! https://gitlab.com/-/snippets/2535398

I think that document laid out all the right ideas for *the fediverse* (not saying bsky, the fediverse)

[cwebber@social.coop]

Now I want to be clear here that I *don't* think that proposal was necessarily the right one for Bluesky, and I *do* think Jay Graber *was* the right person to lead Bluesky

What I wanted to do required a lot more research, and we have done that over at @spritely instead

[cwebber@social.coop]

The reason I bring up the proposal here is that I think it has all the right analysis of *what the fediverse should do*, if it was going to rise to the challenge of fulfilling its true potential

So let me lay out what the things in that proposal were:

[cwebber@social.coop]

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...)

[slothrop@chaos.social]

People complain about threading on Mastodon not working right, and @cwebber is just out there like

[cwebber@social.coop]

(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?"

[cwebber@social.coop]

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

[cwebber@social.coop]

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.

[cwebber@social.coop]

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

[cwebber@social.coop]

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

[cwebber@social.coop]

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

[cwebber@social.coop]

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.

[cwebber@social.coop]

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.

[cwebber@social.coop]

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.

[cwebber@social.coop]

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?

[cwebber@social.coop]

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.

[cwebber@social.coop]

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*.

[cwebber@social.coop]

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.

[cwebber@social.coop]

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.