For this #GivingTuesday I'm going to make the (biased) argument for why you might consider donating to @spritely, especially if you care about a healthier future for the internet! https://spritely.institute/donate/
Here's a little thread explaining more... 🧵
@spritely is developing some damn cool tech: Distributed programming! Leading the way on a secure P2P protocol (OCapN)! A WebAssembly toolkit!
But: is "cool tech" what matters? *Why* are we trying to make cool tech? What are the *social implications* of making this technology?
I gave a talk on this recently: "Protocols and Purpose in a Global Democratic Crisis" https://c-tube.c-base.org/w/f9pF5pwxX8mVkmW2i3dU1M
*None* of the decentralized social networks today are robust enough to handle the threats facing vulnerable people and activists today. Not the present-day fediverse, not Bluesky/ATProto. What can we do?
What can we do? Is there hope? Is it possible to build something better?
Spritely was born out of this work, and the strive to create infrastructure allowing for "Networks of Consent". More on that here: https://spui25.nl/programma/we-can-change-the-defaults-building-networks-of-consent-and-spaces-of-joy-in-the-ruins-of-social-media
Christine Lemmer-Webber, best known as co-author of ActivityPub, the decentralized social networking protocol, will speak about the crisis technologists face. Why must we revise the default assumptions of the web 2.0 era? She will introduce the work the Spritely Institute is doing to make a positive future possible.
I love computers. When people say "Computers were a mistake!" it makes me sad.
But it's had to blame people. The direction computers have gone in, the experience people largely have had, is a loss of agency and empowerment.
How do we bring that back, and do better than ever even?
User-empowering technology is a lot of work, corporations aren't motivated to build it. We need research and development of new tech that changes the game from an org that isn't bound by pushing profit.
And that's why @spritely is a nonprofit research lab.
So... what are we doing?
We're building cool tech:
- Goblins, p2p distributed programming: https://spritely.institute/goblins/
- Hoot, a WebAssembly toolkit (and Scheme->WASM compiler) https://spritely.institute/hoot/
- OCapN, a secure distributed p2p networked protocol https://ocapn.org/
But... what are we *doing* with these things?
We're big believers in having tangible examples of tech so people can understand and it's not just vaporware. Sometimes that's challenging to do with low-level tech in development. But games are a great way to show things off!
Unusually, Spritely has a whole arcade page! https://spritely.institute/arcade/
These games are fun and great at showing off ideas of otherwise hard-to-explain concepts. And more, in a moment, why fun and joy aren't small matters.
But... is it all just fun and games? What about actual everyday tangible use?
We're getting close to that point. Here's what we've been up to.
It's the year of dogfooding and Spritely has been using its own tech *every day* this year with a project called Pumpkin Chat https://codeberg.org/spritely/pumpkin-chat/
Alas, it's what's called "dogfood". Not fit for human consumption. But it's possible to use this tech every day, and we are. We're working on getting it out to others too.
@dthompson @cwebber @semitones How do you manage the conflict with Brassica?
With Git, we agree on a main server that acts as the authority when the synchronization between peers fails (history rewrite, conflict, etc.).
How does Brassica manage when two or more users rewrite their history of messages? Does Brassica have a kind of mechanism for consensus?
@zimoun @cwebber @semitones brassica chat uses CRDTs (https://crdt.tech/) which are data structures designed such that all conflicts are resolved automatically and deterministically. they handle conflicts but not history rewrites. those are two separate issues.
exactly how conflicts are resolved depends on the app you are building. for brassica chat it's fairly simple and the "last write wins" strategy works fine for things like editing messages but a lot of the work in CRDT development is handling concurrent, conflicting operations.
in git, the set of commits is append-only and the commits are immutable. in other words, the commit graph is monotonic. the data inside a CRDT must also be monotonic. in contrast, refs (branches, etc.) are mutable and nonmonotonic. rewriting history is simply mutating a ref to point at a different commit. CRDTs cover the append-only, immutable log part but not the mutable pointer part. anything that is not a monotonic operation requires coordination. the general idea is that using CRDTs reduces the number of things that require coordination in your system so that more of the app works offline/during a net split.
@dthompson Thank you! Great explanation. That’s super interesting!
And thanks for the link… Yet another content on my pile. 😁
Christine Lemmer-Webber
Semitones
dave
Simon Tournier