What is Hackers' Pub?

Now you may be saying, "Christine, this is really unfair, because you're looking at ActivityPub servers which are only dealing with a small amount of the network, what if it were an ActivityPub mega-node? What are the costs THEN huh?" and "What if we hosted just PART of ATProto?"

What then INDEED

ATProto is not designed for the Relay and AppViews to only hold part of the network, not *really*, and ActivityPub is. We'll get to this in a moment.

But Bluesky actually has good justification for this! I will defend it insofar as Bluesky was making a serious *design decision*

Actually all these critiques of the fediverse are TRUE, these are known challenges, and actually it's not really so bad, but it could be better, and at any rate, Bluesky made a major decision to simplify a lot for new users, and they have. Things seem to just work for people! Incredible!

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.

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

Now yes, they are using decentralized techniques. Remember when I said content-addressed storage is a good idea and the fediverse should do it too? IT IS! (And as I also said, it's actually fully possible for the fediverse to do, more on that later.)

But the reality is, it's still *centralized*

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

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

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

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

I said we are about halfway through and criminy we're halfway through the afternoon, I need a break to get some tea

We have a few big topics left:

- Decentralized identity, how does it work (magnets too, yes)
- The Org is a Future Adversary
- Christine critiques the fediverse
- Wrap up

갑자기 저렇게 이쁘게 그리시는 분한테 내 병아리 캐릭터 보내면서 그려달라고하면 당황해하실까 상상해봤다.

On that note, again, I am not reading the replies right now because I am (a) afraid to and (b) I'm never gonna finish this and we are a bit over HALFWAY THROUGH the analysis but I have this fear that EVERYONE is mad at me, Bluesky fans, fediverse fans

I am trying to be analytical. I am trying!!!

Actually something that is funny about ActivityPub is that there's "ActivityPub the spec", which I think is pretty solid for the most part, and "ActivityPub-as-deployed"

Many of the critiques I'm about to lay out we left holes in the spec for which I hoped would be filled with the right answers

Actually with this and several other things I am going to bring up, I actually made sure there was space to do things right: there was a push to make ActivityPub "https-only"

I pushed back on that, I didn't want that requirement, and it was exactly for this reason: enabling content addressing

I have actually critiqued ActivityPub and the fediverse a lot! I have kind of never stopped critiquing it, ever since the spec was released. There's a lot that can be improved!

I have even gotten criticism from AT LEAST ONE ActivityPub spec author for critiquing AP-as-deployed but I do anyway

I have returned, with tea

I am still not reading notifications. Well, I have seen a few fly by on the fediverse which is blipping and blooping nonstop in the Mastodon UI so people are clearly reading it there

Bluesky says "30+". How big is the +?? I will resist temptation to look and assume "31"

Alright you've heard enough critiques of Bluesky for a bit and I SAID I was gonna critique the fediverse and I am a WOMAN OF MY WORD

So let's get into it!

"Where are we going with this Christine?"

Well you could have just read the blogpost but 3 more sections remain, we are approximately 2/3 there

I know, bear with me, what is left is:

- What should the fediverse do?
- Preparing for the organization as a future adversary
- Conclusions

One thing we have already discussed so, before I will say anything else, I will repeat: content addressing is really good, and I'd like to see it happen in ActivityPub, and it's *possible to do*, I even wrote a demo of it https://gitlab.com/spritely/golem/blob/master/README.org

Bluesky does the right thing here, AP should too

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:

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

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

ActivityPub left giant holes in the spec around two things which sound the same but which are not the same: Authentication and Authorization

Trying to mix these two, you accidentally get ACLs, and then you get confused deputies and ambient authority, plagues of the security world

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

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

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.

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

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.

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.

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.

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?

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.

@spritelyThe Spritely Institute 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.

Unfortunately it's not feasible or easy to do everything we'd like in decentralized social networks today... not on the fediverse nor anywhere!

The vision of Spritely is "secure collaboration". Finding how to do it was a four-year research project before the Spritely Institute even launched!

Spritely is built by people who know and understand decentralized (social) networks and their strengths and weaknesses today very well: @tsyesikaJessica Tallon and I, two co-founders (and the first two working on Spritely's engineering) are both co-authors of the ActivityPub spec powering the fediverse!

“This is really a turning point and we’re in a historical transition at present.”

https://www.404media.co/at-the-worlds-largest-general-science-meeting-surviving-trump-is-the-topic/

One of the things I'm most proud of about the fediverse is that it owes its success to a lot of queer people working on it. This lead to the fediverse being very queer itself. I'm proud of that.

Maybe it's weird to say, but that seems to be happening again with Spritely.

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.

This is pretty broad but thank you every open source developer who makes my computer awesome

​​​​​​​​​​​​
​​​​
明日早いかもだし​​

으흐흐흐

RE: https://tldr.nettime.org/@tante/116102639569199871

Follow up to the article from this morning. In which I argue how @pluralisticCory Doctorow was right in his article: https://tante.cc/2026/02/20/on-alliances/

#ThoughtProvoker

The current fediverse is an evolutionary dead-end for 2 reasons:

1. It has painted itself in a small niche of decentralizing typical social media use cases, by means of post-facto interop and the introduction of protocol decay.

2. Lacking a proper grassroots standardization process, and with the primary mechanism for fediverse extension being only post-facto interoperability, there is no way out.

Congratulations to the early adopters, who managed to "cross the chasm" with their own app platforms. It took true grit to become deep #ActivityPub experts, and plug holes needed for your app, but you have made it. Post-facto interop works in your favor now. You are unrestrained to productively add more features in your app, and put them on the fedi wire for others to deal with.

To avoid fedi to become less and less attractive to newcomers, we must now consider:

“Why do we want to grow the open social web, and for whom?” -- @benBen Werdmuller

http://coding.social/blog/shared-ownership/

My bank wants me to rate them on a scale of 1 to 5

おくすりのんだしがんばって​​ます​​​​
​​​​

The EU moves to kill infinite scrolling

nooooo my niri :(