Radicle (stack) as a platform

Breaking this discussion out from the Radicle Social Model thread

I love this community model and have been watching various p2p platforms and libraries in hopes that even just one of them abstracts the p2p stack from the product stack.

I think Radicle solving p2p collaborative coding is fantastic. I love it and it is clearly the killer app that is propelling Radicle forward. Love it. That said, I don’t work much in git but I have written apps and products before that work in the traditional manner (cloud server back end, mobile app front end, local app front end, etc) but I hate the cloud. I don’t like spending on server costs and I don’t even want to host data so I dream of a flexible p2p backend.

A lot of the focus seems to be on building p2p alternatives to existing successful walled gardens. Reddit / Facebook / Instagram clones built on gnu social / federated things, but I care more about private personal communication which has less to do about finding swarms and peers and more to do with just two nodes being able to interact without a middleman server in the cloud.

The Radicle Social model philosophy is wonderful, and as I was reading it I was replacing “the project” with “thread”, “group”, “channel”, “topic” and love it even more :slight_smile:

I’ve yet to see (, and if one exists, please link me up,) a stack or library that helps facilitate the foundations of p2p – and I think Radicle might be the closest I’ve seen.

I’ve seen a number of p2p groups online seemingly all working on p2p libraries and p2p versions of existing products and services but none really working on building p2p as a platform or stack. The ideal would be a world where instead of spinning up a docker image on a vps, we can simply build our applications / front ends / ux & ui while plugging it into a p2p layer that handles NAT hole-punching / routing, Identity and discovery or the ability for nodes to establish connections with one another – either directly or indirectly via swarm or gossip protocol or whichever makes most sense. Bake that into an api or protocol and suddenly you can make really lightweight p2p applications without having to rebuild the wheel each time.

I love how SSB works and would love to be able to plug in to a backend that works just like SSB or Radicle.

Thank you for your time and thank you for your contributions in this space. I wish the internet wasn’t kidnapped by wall street and we could go back to building protocols instead of niche gardens and ecosystems.

1 Like

From my reading of the field there are a number of technologies emerging which handle the kinds of problems you are talking about.

On the networking side libp2p seems to be emerging as a your “p2p layer that handles NAT hole-punching / routing, Identity and discovery”. I’ve not built anything on it yet so I can’t speak directly to how mature it is but the experience of most people I know working with it is that it’s still pretty early and has a lot of sharp edges.

After this basic networking step there are two problems which interest me personally: how do we manage identity and how do we replicate data?

To the first question I am very hopeful about the DID standard (and associated things like verifiable credentials). These are actively being built on in projects like 3Box.

To the latter, once you remove a central server but you still want to collaborate on data, you either have to build application level merging (a la git) or you build a CRDT. There are a whole load of efforts to build general, reusable CRDTs (such as Automerge, which I contribute to). My feeling is that we will see different implementations emerging for different usecases as there are a bunch of tradeoffs involved in designing a CRDT and they won’t be the same for every application.

Once you have all these ingredients I think it will be viable to start packaging things up into an SDK that insulates the application developer from all those concerns so they can just write UI and application logic and magically build a local-first p2p application, at this point we will unlock the true power of computers and transcend this earthly realm.

IMO the reason such SDKs don’t exist yet is that most of these questions around networking and data and identity are still open problems. I expect to see common solutions to different problems emerge over the next few years and start to be packaged up into more abstract libraries and platforms. Right now if you’re building a decentralised p2p application you are basically taking on one or more of those open research problems. It’s the fun part basically :).

:heart_eyes: :heart_eyes: :heart_eyes: yes, what a dream it will be

Definitely agree with your points and that’s likely why all of the implementations simply have their own custom built p2p layer specific to their application.

I sort of like the keybase approach where you can link your various accounts as proof of who you are and link your identity. You just are what you claim to be and as you make connections / links, you sort of authenticate it all yourself. Not a fan of keybase selling to zoom though.

Does identity get easier to manage if you’re simply trying to have a one to one application experience? eg, if you’re not looking to post to a public square but simply direct message.

I’m not proficient enough at the networking layer to build the right solution. I’ve used libp2p’s go library to do NAT hole punch which works and is relatively easy, but the identity part is missing from that stack.

I could fall back and just write something that just let’s you manually link known nodes (maybe friend A texts you a qr code or a link to establish a handshake) then the apps sync any data / messages / posts between user A and user B.

I lean towards wanting to use p2p libraries as I do feel someone is going to solve identity, data syncing in a way that’s abstract for people to build both simple and complex applications on top of. Also p2p makes sense because even in personal communications often people want to have a group discussion. (This is probably where CRDTs begin to get problematic?)

Thanks for entertaining the discussion and again thanks for contributing to these open protocols and ideologies. It all adds up and benefits everyone so thank you.