Radicle for Resilience: 5 Things You Didn't Know (But Should)

Hi, hello. Can you hear us okay? Yes? Awesome. So, you see two of us on stage today because we will actually do a live thing.

So, give us a few seconds to set up. Today we will talk about Radical and what does that mean for code collaboration and resilience. How many of you have you heard about Radical out of curiosity? Okay, almost half. Amazing.

Okay, so let's do this. So, we started working on Radical in 2018. The main belief we had back then was that things were about to get weird in the world and unfortunately in 2025 things are already weird in the world. And we really value open source. We think that it's one of the digital treasures of the world, a symbol of global collaboration like no other.

And we thought that everything that's happening on the geopolitical landscape will actually impact negatively the thing we love. And we are already here. I believe that many of you are familiar with that, but in 2025 the openness in open source is to be challenged depending on where you live in the world, depending on which countries you visit, and many more weird things. So, we started working on Radical. Radical is a peer-to-peer protocol for code collaboration.

You can check it out on Radical.xyz. And today I want to share five things that I think are interesting and exciting about it that you should know. So, the first one is that Radical is 100% Git compatible. Fundamentally, Radical extends Git in three interesting ways.

The one is it adds a cryptographic identity layer, and we'll talk about that. The second thing is that it actually brings the social artifacts within the Git object. The things that became familiar with things like GitHub, GitLab, now you can have them in a sovereign, truly peer-to-peer environment. And then lastly, Radical extends Git with a Gossip Network, and I will explain why that is. So, let's start with cryptographic identities.

So, within Radical, we use cryptographic identities across the board. You can create them locally. We're using ED25519 keys that are also DID compatible, and we already support DID keys. Now, we can actually show you how easy it is to get started, and I'm going to pass the ball to Fintan. Fintan, can we hear you okay?

Yeah, yeah. Hello, hello. Cool. Yeah, so I'm going to take over and show how you can get started off of GitHub. So, I'm going to clone an old repository of mine called Dalbash.

So, let's clone. And we started with GitHub just simply to show you how you can actually go from a GitHub repo to a sovereign mode of Radical. Yeah, and we're still Git compatible. So, okay, I'll rat in it, and that brings up a wizard. Dalbash, I'll skip the description, default master, and I'm going to create a public Visibly repository.

So, here we see the repository being created. It's got its identifier, and it's synced up with the network. At this point, I can actually click this, and we see the repository in our web app view, potentially. Yeah, there we go. And so, it's like a fresh Radical repository.

As well as this, I can actually go over to the desktop, and... Okay, it's not showing up. Did this refresh? Yeah. But, yeah, I'll show you a little bit how it's Git compatible.

So, as I said, we have the repository identifier here, and essentially, your forge is locally on your computer. So, here we have Radical storage, followed by the identifier, and I can actually the refs, and all the Git references are in there, sitting in there, including the identity. So, that is also part of the social artifacts. Yeah, amazing. So, yeah, and as you can see, for the ones of you that are familiar with Git, the storage model here is very, very similar.

So, that's the first thing. Radical basically means Git. You don't need to go into a completely different workflow. The second point that I would like to talk about is that Radical effectively extends Git with social artifacts, and what's exciting about this, beyond the security properties, then, that everything is actually graphically signed, you can address anything. Additionally, everything is also local first, which is something that gives you really nice performance and really nice experience.

It's something that also surprised us, being used to the cloud model versus actually having everything on your device. So, let's actually look at this. So, at first, all right, I'm going to try to find it on the desktop again, maybe by restarting. If not, I will drop back to, there we go. I'll drop back to CLI.

Okay. So, here we have tabs for issues and patches. Let's create an issue. So, I'll start off with the title. Let's move this off of GitHub entirely, create.

github readme to point to Radical instead, to point users to Radical instead. Actually, before I do that, before I create it, I'm going to stop my node so that I can show you it is offline first, not only local first. So, I'll jump back to this repo here on the web view. There's no issues. I'm going to save this.

Let's refresh. Nothing. Let's rad node start. Sorry, my band got in the way. So, we started my node again, and I'm just going to hop into that repo and call rad sync, and I'll go verbose.

So, got to wait for the pipes to clear out and let the information hit that peer-to-peer network. Apologies about our janky spinner. So, I refresh again. There it is. All offline first.

You can work on the airplane or answer your issues, make pull requests or patches as we call them, and sync back up with the network when you're back online. If we can go back to the desktop app as well, we can just navigate there so you can see how instant everything feels because it's literally on your computer, right? So, yeah, some really nice performance that you get out of the box. I think many engineers in the room will probably appreciate that. Awesome.

Okay, so that's the second thing. So, first thing, radical means 100% Git. Second thing is you have this locally signed, local first social artifacts. And this, of course, extends to everything, right? Things like issues, things like comments, things like patches is our equivalent of PRs.

All of those are locally on your computer, cryptographically signed, and you can interact with them instantly. So, now let's move to the third thing. So, one of the things that many decentralized protocols actually don't get to is some degree of privacy. But when it comes to open source and specifically the state of open source, we think that privacy actually is extremely important. Both privacy with regards to how you reveal your work in the open, how do you go from a private repository to an open source repository, but also with regards to how you protect yourself when you're contributing to challenging projects with regards to power.

So, radical comes out of the box with both private repos and a Tor integration. Maybe we can show a little bit about how a private repo looks like. Sure. I'm going to take a really old repository that I call talks. Apparently I only made two talks.

So, let's do the same. Git up talks, git up clone, and we'll do radinit again. And this time we will pick private. So, I'm going to do a little inspect of the repository. So, in this case, radinspect identity shows visibility type private.

Essentially, at this point, I can allow certain nodes in the network to know about this repository. And I will show that flow by grabbing the C.radical garden and rad ID allow and don't need the address part. And in fact, I need the DID key part. So, at this point, I've created a new revision, which should be...

I apologize. Let me see if it just got accepted. Maybe I've done something wrong. Live demos. Yeah.

But fundamentally, you have the possibility to actually specify an allow list. And these are the only nodes that you're actually saving that repo. And then additionally, as I mentioned, there's a Tor integration that you can use. You can route all your traffic via Tor, if you like that, or partly. You can operate in mixed mode and full mode.

So, that's the third thing. Yeah. Let's move to the next one. So, this is one of my favorite ones. So, in Radical, you can have canonical references, canonical branches, and signature thresholds.

Let's break down what that means and what that enables. So, if you think about the GitHub model, right? So, on GitHub, let's say you're interested in a repository. Let's say that this repository is Bitcoin Core. If you want to find that repository, you have to go to github.

com slash Bitcoin Core, you know, slash Bitcoin Core, right? So, that's location-specific. Effectively, you're trusting that location to give back to you the content you want. In a true peer-to-peer network, of course, we can't do that. What we do want to do instead is we want any node to be able to share with you the content that you're after, and you to be able to verify this fully.

And the way Radical does that is by actually introducing a gossip network where, effectively, nodes gossip to each other what kind of repositories they have and what kind of updates within those repositories. And then, for transport, Radical actually uses Git. So, effectively, when you know that a Fintech node has the content that you're interested in, then your node basically fetches that from him. And the thing that actually enables us to do that is this idea of an identity document. And let me explain what's happening here.

So, every repository in Radical contains an identity document. In fact, the hash for the repo identifier is a hash of this identity document. And in that identity document, we codify a bunch of interesting things. The one thing that we codify is something that we call the delegates. You can think of this as the signers, the admins, the governance of that repo.

And then, additionally, you have the possibility to specify what we call a threshold. And in this particular example that you see behind me, the threshold is one. You have one signer and the threshold is one. So, in order for you to change the state of a repo, all it takes is one signature from that node. But what's interesting here is that, of course, you can do many more things around that concept.

You can have, for instance, like five signers, and you can have a threshold of three. And to the ones of you that are familiar with the cryptocurrency industry, this starts to feel a bit like what the multi-fig does for your assets, but actually doing the exact same thing for your code. And the way we're using this within Radical is we are actually going from the trees of the different maintainers into the canonical state of a repo, let's say the master branch. So, the master branch effectively is dynamically derived from this logic and what the maintainers are doing. We're running a little bit late on time, so maybe we won't show that further.

But if we can go to the next slide. So, with this capability, this specific capability, you can think of them as decentralized branches with cryptographic policies enforced. And these, of course, are very handy for us with regards to code collaboration, as they allow us to codify the governance of a repo within the repo itself. But as it turns out to be, this specific aspect is also very interesting and has benefits in more applications. Today, as the last thing I want to show you, is something new that's coming out of our ecosystem.

So, a group within our community has been using the Radical protocol and these aspects of it that I showed you in order to locally verifiable and secure frontends. So, if we can go to the next slide. So, today I would like to show you something new that's coming. This we call the Radworks app for secure and verifiable frontends. It's building on the existing technology, but it's actually a consumer product.

So, up to this point, our ecosystem was very focused on developers, but now we realize that actually consumers need to also enjoy some of the benefits of locally verifiable software as well. So, based on this logic that I described as a multi-fix for code, we're actually planning to introduce to the market a consumer end product. It's a launcher for frontends. In this specific example that you see behind me, you see Uniswap, the Uniswap app, Safe, and Lido. And as a consumer, what you will be able to do is actually you will be able to install those apps and verify them locally.

And as you can see, let's zoom in on Uniswap, you will have also the possibility to see a few more properties about what's happening with that developer team. Are they doing source code signing? Great. Are they doing binary signing? Awesome.

What kind of trust policies do they have? Okay, it's three out of five maintainers. And then finally, if they're doing reproducible builds, even better, although for many of those apps, this isn't the case. So, effectively, you will be able to download frontends locally on your device, verify them, and then consume them, use them, enjoying some of the same cryptographic properties, both on the way you receive content, but also the trust logic, the social policy that I showed behind the scenes. And this, of course, is also building off of the radical network.

And the thing that gives you is, again, you have a local first to consume your favorite frontends. It's uncensorable. It's truly tapping into a peer-to-peer network. And all you need is a single node that has the frontend that you're interested in. It's also chain agnostic.

This can support Gnosis chain and Ethereum chain and Bitcoin DeFi related frontends, etc. And then the last thing, it's building off the idea of reproducible trust. Even a single developer's machine is compromised, as long as the majority of the maintainer's machines are not compromised. Then you actually have secure delivery and consumption of frontends. So, that's it for us for today.

Again, to remind you, we're working on this because we think that open source is at risk. We think that radical is providing a better home for open source today. What you see behind us is actually the pushes to the radical network. It took us a while to get this to a stable state, but radical is stable since September 2024. We've been shipping more software than ever.

So, yeah, we would love to get your feedback. We will be around the conference today. And if you care about decentralization, then you should use a decentralized forge. Thank you very much.