Gregory's ServerYes, I changed the order of the remaining sections, not from the blogpost but from the last time I said what was left on this thread
pray I do not reorder them again
|
160 comments
 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!  @cwebber <grabs popcorn> :) No but seriously this thread is great, thank you so much for writing this! I'm learning a lot 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 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 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 Content addressing is important. It should not matter where content "lives". It should be able to live anywhere. A server should be able to go down, and content should survive. Go content addressing! 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 This isn't the only time I left a critique of ActivityPub-as-Deployed as opposed to ActivityPub-as-it-could-be: see also OCapPub, which critiques the anti-abuse tools of AP as inadequate and leading to "the nation-state'ification of the fediverse" https://gitlab.com/spritely/ocappub/blob/master/README.org Oh, and ocaps!!! 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 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!  There is value in invoking the charting 'bot thusly: Calling @Chartodon spine ... 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) 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 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: Here is your recipe for making the "Correct Fediverse IMO (TM)": - Integrate ocaps, which is possible because actor model + ocaps compose (cotd...) (cotd ...) - Better anti-spam / anti-harassment using OCapPub ideas 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 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 == @cwebber Oooh, E2E encryption for fediverse! 😻 I've been thinking about that sort of things recently and I was wondering what experts have thought about them. It would be so nice to have a smoother gradient available between public and private visibility, instead of the current binary choice of either being almost completely isolated and unseen by new people or fully open to content scrapers. And there would be some extra protection against privacy leaking bugs, too.  @cwebber can you go into more detail about petnames or as I like to call it local names ..don't you think people will talk at the idea of a non global namespace for a global network ? Is there something with petnames that we've all missed ? What do you think about the idea that naming in general is just a simplistic version of a search engine ?  People complain about threading on Mastodon not working right, and @cwebber is just out there like  @cwebber At some point I'd really love to get an explanation on content addressed storage. At the moment I imagine something like a cross of git, IPFS and BitTorrent.    @cwebber did you already get yourself an agent to turn this into a book?  My constrained executive function demands moar! Translation: thank you for your clear and interesting deep-dive into federated software and the problem with Bluesky retaining control of relays by choice of architecture. I'm going to sleep now, but would love to read more whenever you have time to write. |
Before we get into the next section, earlier I left an easter egg, which you could reply to and say "I found the easter egg" or something
Now you can put 2 eggs
I 2 was once an egg
(Look I specifically transitioned so I could never be accused of making dad jokes again so that does not qualify)