|
Top-level
 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 126 comments
 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 I've bookmarked more posts today than I have in weeks. Will definitely be reading over all of this. 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.  Before we go any further, earlier I mentioned the US House of Representatives, and here I am giving a MASSIVE content warning for transphobia But @evangreer is the coolest fucking person for standing up to Rep. Mace at the Project Libery summit https://www.fightforthefuture.org/news/2024-11-21-transgender-digital-rights-activist-confronts-hate-monger-rep-nancy-mace-at-internet-summit/ 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.  @cwebber good work here. i *really* detest the seemingly objective fact that a google can't be p2p, but i can't crack it either. though considering the SEO vulns that google has, i wonder if even google "works" 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. @cwebber FWIW, I'm not interested in anyone's proprietary platform, ever again. I will revert to emails and text messages and Signal. But Mastodon instances are the best response I've seen.    @cwebber You have given me - and all of us - an excellent exploration of ActivityPub and Bluesky. For me, it’s the best one I’ve read on here, period. So no, you haven’t “missed a day of work”. Quite to the content, you’ve done a good day’s work, and then some.  @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  |
Gregory's Server
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!