Radicle demo by Daniel Norman

do that. All right. So, what we're going to do is I have just an empty repository. There's nothing in here. And we're going to just start off by initializing a Git repository.

That's great. You know, I have a Git repository, but has no history. Um, you know, I'll I'll just initialize a readme and, you know, maybe we'll just say, you know, just start with something. Um, and this is our repo, right? It's just uh it's going to be a list of uh good Duna places.

Um, I hear there's actually one, it's not strictly Duna, but there's Air Bill. It's a great uh Kurdish restaurant just around the corner from here. Um, yeah, for the lovers of grilled meats. Yeah. Okay.

So, we've initialized this repository, but now we're going to make an initial commit. Um, and I have to stage files. You see, I'm already used to jiu-jitsu. Um, okay. And we're going to commit this.

Uh, right. Should we throw in some emojis? Why not? Okay. So we have this initial commit and that's just a standard git repo.

You know the standard procedure would be now to maybe create a repo on GitHub and you know add it as a remote but we're doing things differently here. And so the radical way to do things is to use this radical init command. And what rad init will do is it'll ask me it'll you know prompt me for some you know some information about the repository. Um and uh this is a public repo, not that the private is private. And uh now we have this repository ID.

And so I'm just going to like open up a new tab here. And I want to show the like some of the CLI commands. So when I do radical ls, I get all of the repositories that I'm seating. And uh what was it called? Cbase demo.

And so what we have here is a repository ID. And this is a an immutable identifier for the repository that remains stable as the repository evolves. So for example, the um the Hartwood repository. This is the radical protocol implementation. This is the uh radical ID of this repository.

And we'll also see it here on the list. So I'll make this a bit bigger but you can see it ends with V5 and uh this is a selfcertifying identifier from which all of the changes can be verified. And so it's it's quite an important concept because when you clone repositories what you're cloning is actually the sort of the identifier that you use is that repository ID. Okay. So let's go back to the CBase demo.

Right. I'll uh get again this rad identifier and what I think it would be nice to do is to show some of the other uh uh front ends like the UIs that we have. So obviously we have the CLI and I can you know I can open up issues from the CLI but uh not all of us live in the terminals. Some of us live in the browser and um maybe I can open up an issue with the desktop app. So right here I have the desktop app for radical but actually before I do that I want to show one more thing.

So I want to show what how this identity is derived. So when you initialize a repository how do we get this identifier that as I mentioned is immutable? What we do is we actually create this identity document which is all of the information you need in order to identify a repository and it's like you can think of it as like the beginning of the chain. So like the origin um commit and we hash this um identity document and then the hash becomes the uh repository ID and what you might see here is this delegates list. So delegates are the radical sort of concept of uh repo maintainers.

So delegates can make changes to the repository. They can update the identity document and you can obviously have multiples of them. What you see here is a did key. It's an ED25519 key. And uh I could, you know, um I could do an update to this and add other delegates here.

Um the other thing you see here that's probably relevant is the threshold. The threshold, you can think of it as like the uh multi-ig m number, m ofn. you know, you have like the number of signatures that you need for a um for well for a transaction to be considered legit. But in this case, for a a change to the default branch. So, you know, we have this idea of canonical branches and uh I'll just show what a little bit of what that looks like.

So you know we have for example here you have a more complex identity document but what we have here is a rule that says that for the releases tags you need to have uh the delegates a threshold of two delegates agree on a tag for it to become canonical. And so what that creates is a cryptographic mechanism by which we can uh verify that multiple maintainers signed off on a release or on the canonical branch which in our case is just the main branch. So that was just a little bit about how we derive this uh immutable repository identifier. Yeah. Go on.

Do you want the microphone just for the recording and for the people on the interwebs

to the threshold thing again? [clears throat] Was that frost or what thresh?

Oh, that's a great question.

So, no, it's not a frost. Um, so Frost signatures are amazing and I think they're like a worthy area of exploring, but no, these are just it's just a rule that says, hey, you need to have two maintainers actually sign off on a commit or a tag uh for it to be considered canonical. And I can show just a little bit more about how that actually works so that it makes sense. And that is using where things live. Yeah, I think where things live might be the thing.

So the way that um things are stored in radical is that we have this radical storage and all of the things that you do are namespaced. So git has this feature called git namespaces and we actually leverage git namespaces in order to con in order to contain all of the user like did specific keys within a namespace. And so what happens is that when two maintainers push to their special RAD remote which again we can look at this in a moment um the signing happens and so there's like explicit signing there's no frost magic happening here. Go on.

Um do you have any uh cipher agility in the protocol? So let's say in five years or 10 years ED25519 becomes practically too weak be that through just crypto analysis or some cryptographically relevant quantum computer or something are you prepared to migrate to some new signature scheme?

So there's two sides to this question a great question too. Uh the first one is uh the sort of the malibility or the flexibility uh of the signature scheme and then the second thing is uh how we use these keys in terms of like uh where are we using these keys for cryptographic purposes. Um and there's two parts to the latter question. So the first question is is there flexibility? Not right now as part of 1.

0 but this may be uh part of the 2.0 with O release that uh LA discussed. As for the latter question, um so you can today even if you're using say an ED25519 key, it doesn't mean that you are strictly bound to using a specific cipher for the transport encryption. And so obviously we're looking into IRO and IRO actually supports some quantum resistant ciphers and you can actually derive the sort of the symmetric encryption key. I mean with TLS um using an ED25519 key um for uh whatever cipher symmetric cipher you want for the transport.

So for the transport encryption once we move to something like IRA I don't think it's a problem but uh we do want to like have that kind of flexibility as a first uh class citizen in the protocol. Cool. I think I can continue a little bit. Okay. So, I showed a little bit how we have this like rad remote and you can push to it and it does the signing for you.

I mean, at least I showed this nice illustration. Um, now let's go into the desktop app and show a little bit what it looks like. Okay, so I have a bunch of repos here. Uh, we're going to look at the Cbase demo. In fact, I'm going to pin it so that we have it nicely here because I'm going to be working a lot on this repo.

You're going to all submit your favorite Duna places. And we're going to open up some issues here. Um, need more um,

more

RAM. Yeah, I do need more RAM. You know, all the boomers are like sending videos eating up all the RAM. Okay. Yes.

Yes. Okay. That that's going to be a good starting point, but we're also going to need some Duna places. Sorry about the lack of umlout. Uh there we go.

Look at me. Um places in. And uh hopefully someone is going to submit a patch at some point. Um and then we can close this issue. But of course, I can do all of this, you know, while being offline.

Um and I'm just going to stop my node. This is something that I didn't show but maybe I should show which is that as I mentioned. All right. Rad self. Okay.

So this is my uh dead key and this is the ED25519 key that I mentioned. And I'm going to start the node. These are some of the uh you know commands that you end up interacting with. And you know you can you also have this status command that allows you to see who is your node connecting to. But basically when you create a repository uh it uh usually gets picked up by what we call permissive seed nodes.

These are nodes that will just have a permissive node policy, a replication policy where they just sort of see sort of what propagates through the network and they'll replicate it because uh it is a peer-to-peer network and um we have um let's look at the network and how it it works. So when you make a change to your repository, you basically make this really cheap sort of uh uh gossip announcement about, you know, where your refs are at. Um these are the signed refs. These are like all of the git references that are signed off by you. And uh other nodes will then pick it up.

And in fact um what actually sort of naturally emerges in the network is a basically a rooting table for repository ids mapped to nodes that are seating them. And uh that's how we're able to say determine in the UI. I'm looking now at the radical desktop. This is how we get this number here that we see 112 nodes sitting these repo. That's because they're actually announcing that they're sitting this in these uh uh node announcements.

They contend they basically uh propagate they emit their um inventory which is just a list of the repository ids that they're seeding. And so that's how we achieve this redundancy and resilience in the peer-to-peer network that is completely emergent. Does that mean that many nodes know the metadata or do they have a deep copy of a repository? So, do they have the the metadata or a deep copy of a repository?

Yeah, that's a great question. Uh, as a meta comment, can you come to all of my like uh following talks just to ask good questions? Um, so uh I thought it's maybe go good good to go back to uh Ellie's talk. So in Ellie's talk, you know, he talked about how, you know, we have GitHub and um, you know, all of these like centralized uh, forges and, you know, if you think about what GitHub is and GitHub is so git on its own is already a database, right? Let's start with that.

You know, we can have a debate about what's the meaning of a database, but you know, there's a lot of database engineering that went into making Git work as it is, and it is in fact a database. But what a lot of the forges like GitHub do is they add another database that then stores, you know, your metadata, your social artifacts like pull requests and issues and whatnot. And what Radical does is it stores everything in your repository. So all of these uh you know social artifacts are really just uh what we call them collaborative objects, but these are effectively CRDTs. uh they're opbased CRDTs whose operations are stored in a git repository and then signed off by your identity.

And so obviously every operation is tied to a user who signed off on it and you know that they're eventually consistent. Um so does I guess that answers your question, right? So when we uh replicate a repository, we replicate the code and all of the social artifacts in it. However, well, not however. This is not a caveat, but um because all of the social artifacts are namespaced, including the code, that means that the canonical state of a repository is effectively derived by looking at the identity document.

What are the rules that are defined in that identity document? And then we sorry syn syn sorry sorry sorry sorry I had a a tooth operation synthesize um the canonical state from all of these namespaces based on the rules in the identity document. Does that answer your question?

So you only replicate the name spaces you need. It's not a complete copies. For example, if there are eventually release artifacts in there and big blobs, not every node will replicate those.

Yeah. Yeah. Yeah. I can maybe get into artifacts in a moment.

You're computing the transitive hull of what you need.

Exactly. Yeah. But we generally replicate I mean you can have so for a repository um that you're seeding locally uh rad seed you will see here that we have this scope and what the scope does is the scope is like the seeding scope we call it which means uh whose name spaces are you um replicating? Are you replicating your followed and the followed set includes the delegates plus all the dids that you explicitly follow locally [snorts] whereas all is literally replicating everything. Um so that's it and and by the way this excludes artifacts.

Um we can maybe look at in a moment at artifacts. Um okay so we looked a bit at repository identity. We have these social artifacts. Um, we call them cobs, collaborative objects. These are issues and pull requ patches we call them.

And I think maybe it's worth looking at a real world example cuz we're using Radical. We're dog fooding this to build Radical. [snorts] And so what we're looking here is the Radical Explorer. Uh, the Radical Explorer is the web UI for Radical. It's read only.

So as part of RAD 2.0, O we obviously want to have rights via the web but for now this is a readonly UI and what you're looking here is at a patch now very much like in tangled uh you know ligi showed us you have this idea of rounds uh similarly we have this idea of revisions and basically every time you make changes to a patch you can push it and uh it will create a new revision and you can also do you compare uh you can compare revisions to previous revisions So you can see what changed. This was probably just a rebase. I like to make small incremental commits. Yeah, there we go.

Now we're basically comparing these two revisions. And um we can obviously see the review uh comments. You can leave reviews on a specific revision. And um we can also look at this from the desktop. Now, this is interesting because the desktop also gives you the ability to do rights.

So, if I go back to this uh uh this patch, you can see it here. And I can actually look line by line and I can see all of the commits. Obviously, I wrote them, so you know, it's it's it's nothing too surprising here, but I can actually just like scroll through this and I can see the inline comments that have been left on some of this. And you know I can reply you know on this and uh I can do all of this offline. This is the the really neat part of it.

It's all cached locally and when I go online it'll get synced. Um okay back to the uh our demo repo. So I have this repo. I just want to show a quick uh small thing. So we have this radical garden service.

Um, and basically this is like a paid on always on node. I think we charge something like5 a month for it. But I can basically now tell this um my garden node, hey please replicate my uh repository and then it will basically keep it online and seated at all times. Um I also have my local configuration configured so that uh it uses this seed. Now this node is also using my custom domain.

So there's really like not that much vendor lock in. You know it's just a my domain and it's just basically a hosted node. Um and yeah, we looked a little bit at patches and revisions and the common system. Um, is there anything else that is maybe worth

about CI?

CI. Yeah, go on.

Artifacts. Yeah, maybe we'll do artifacts and then CI and then I can wrap up. Um, artifacts. Okay, so as I mentioned, we have these social artifacts. And the thing about Git is that Git has a number of solutions for managing large files out of Git.

but in git kind of thing. So, git was never really built to handle large files and it sucks at it. And so, a number of solutions have emerged. One of them is git lfs. One of them is uh git annex.

Another one is uh part of the core git protocol. It's called larger large large object promises. And the problem with all of those solutions is that while they embrace the sort of the content addressed nature of git where you address things by their hash, they're very much tied to this idea of having a definitive origin that then resolves that. Git annex is actually different in that it supports multiple backends. It's much more flexible in that sense.

Um and so actually when we approached this problem we were like okay how could we take the best things that exist out there but then do them in the radical way and and it was obviously heavily inspired by you know I I worked on IPFS I still do um and so it was heavily inspired by my work on IPFS but also uh you know existing projects like git annex and so radical artifact has two parts. It has the cobb the collaborative object where effectively all of the metadata about artifacts is persisted inside the repository. This is like things like uh the commit that a specific release is tied to. Um the uh number of loca like the all the different locations it has uh who signed off on it. And so basically radical artifact from a high level is our approach to sort of secure um distribution binary distribution with radical.

And uh the way that we do that as I mentioned is with this uh radical collaborative object. And then the second part is the node process that actually um helps with the peer-to-peer distribution. And so um here I'm looking at a repository radical artifact. And if I we also have a CLI for it. Um and I can list all of the different releases that have happened.

And uh what we'll see here is all of the different actually maybe it's better to open this up in radical explorer. Um so we have also search as of recently and um here we have these releases and 3 days ago uh I released radical artifact 0.21. Okay. So we have a bunch of um binaries here.

These are for different platforms. So you know uh arch 24 we have two processes there's two binaries as part of radical artifact. So that's why you see uh these two and for each of these we have multiple locations and this is where it gets interesting because we address everything by a blake 3 hash. We use like SIDS we wrap it in a SID but we use Blake 3. And the reason we use Blake 3 is because it allows us to do nice things like incremental verification when we're fetching it in a peer-to-peer fashion.

Um, so that's kind of like a very very high level overview of what radical artifact uh is. But the nice thing about radical artifact is is that allows you to do things like attestation and multi-party uh verification of binary. So you can really if you're using something like reproducible builds in your repository, you can have basically multiple maintainers attesting that uh you know they uh are resulting with like when they're compiling they have the same uh content ids for their artifact. And so that was a little bit about that. Um you know we have uh you can use obviously radical artifact.

um you have a separate node processor for it now but hopefully as part of 2.0 0 this becomes integrated into um the single radical artifact and you know we can see our status here and you know I'm seing a bunch of artifact and um let's um let's try just to show you so I can just you know sort of pick the binary that I'm interested in and basically it's going to try downloading this from two different locations. So that's where we get that resilience uh from. And while that's doing, I think we can maybe while that's downloading, I think we can maybe look at CI a little bit. Okay, so as I mentioned, right, we have this all these different cobs, right?

collaborative object and they allow us to use git as a database to sort of propagate these artifacts about the code. One of those cos is issues. One of the other one is patches. The other one is artifacts. Um and we also have this one called job a job cob and the job cob is really just for CI runs.

So the way that you approach CI with radical and it's still obviously liinal. We're like really working on polishing this, but we want this to be extensible and pluggable. And so we have this job cob which allows you to encode runs associated with commits. Obviously everything is signed and uh you can have a URL that is uh assigned to these runs. And so you know we can look at a commit here and maybe this one didn't have a run because it was part of like a big commit.

But here we have this one and this one was running on build kite. The build kite integration is right now something that only exists in radical garden uh the hosted service that I mentioned before that we're running where you can get an always on node. Um and as you can see I'm you know doing some standard sort of rust CI stuff. So you know running some clippy tests and you know running a rust doc and building the docker image and the standard CI stuff. Um but obviously this is not the only way to do CI.

So in Radical Garden we support web hooks and uh so you can plug this to something like uh let's see where the web hooks. Um oh yeah they're here. Uh radical. Yeah. So in the integrations, yeah, we have the build kite, and this is where I have all of the configuration, but you can just set up a web hook here.

This could work, you know, with things like uh Jenkins or like with Woodpecker CI, like if you're doing self-hosted CI. Um, there's also another sort of like a more, how would you call this, a bit more of a Gonzo styler CI integration where we're like basically leveraging GitHub um to do the runs and we're like basically syncing the repo um to GitHub to just like get yet another sort of source of signal about how CI is looking. Um, but this is just to demonstrate that really like you aren't tied to one CI solution. And we also have ambient ambient CI and that is a sort of uh one of the projects within the radical ecosystem built by L. Um, and that is uh aiming to be a very very sort of uh uh opinionated but also very safe CI system.

And so I think uh we're using this also for radical artifact. So I can maybe show you what a run looks like. I'm kind of surprised. Maybe we'll look at Hartwood because Heartwood uses it too. And while that's okay.

Yeah, there we go. Actually, I think this is someone else's ambient run. Yeah. So you can see it looks uh uh very very uh 90s, but yeah. Um, okay.

So, now I managed to download this. That's great. I have it here locally, but this is obviously a Linux binary and I'm running on uh one of these uh Apple computers, so I can't run it locally. But what I can do is now that I've downloaded this artifact is I can actually you know what I'm going to try to uh rad artifact and then I'm going to try to seed uh and I'm going to try to seed this and what that will do is that will register yet another location for this so that there's now four locations for it and so if I go rad artifact show and I'm going to wrap up in a moment. Uh I think it's releases release releases.

Yeah. Um we'll see that one of them has three. Yeah, there we go. This is the one I believe. Was it?

Yeah. Unknown x64 for Linux. Yeah, I think this is the one. No, this is the one. Rad artifact node.

Yeah. So, if I paste that here, I should see it somewhere in that list. There we go. Yeah, that was the one. And so, now we basically have three locations for that.

And if I do a list, it will seem more obvious. Um, there we go. We can see that this one has three locations and that seedling that you see here is indicating that I'm seeing it too. And so that's how you can sort of in a very participatory way uh help by seeing artifacts that you care about. And this is where it's interesting because it's like very selective about the binaries or the blobs that you care about without having to it's not like an all or nothing type situation.

So with that I'll wrap up. Um if you have any questions I don't know if we have time but

um you already used all these dead primitives and crypto primitives in in general. So I've been wondering can I uh use my uh EVM identity ideally in a browser wallet or something and uh carry it all the way through to which ironically your your uh colleague before said uh companies don't care about this stuff. they very well care about this stuff especially since the cyber resilience act and all these type of things are coming up and this is very much a consideration because in in even in a corporate enterprise environment you still have the admin key problem that someone has access physical access to the machines and can manipulate uh your your local git instance and and do something about this right and so Um, I've been wondering if you can use all of these primitives and carry them through um, and anchor them, for example, on a on a stateless ledger and build the trust from there. Anchor the trust there.

How do you imagine that though looking like from a very high level because what what you're describing is anchoring something on chain effectively

basically. Yeah. as as a trust source like you

I mean okay but then it's like you're just shifting the trust elsewhere so I mean like the way I imagine it is let's say we are as an organization have radical

right as like an ENS name and then in that uh ENS registry we like have a number of records for the repository ids that represent our canonical repository

for example if just asking has anyone ever experimented with this had some ideas around this.

So, so we did in the early in the earlier phase of the project, you know, we did experiment with a lot of that type of stuff. Um, the major problem we had at the time which I think is now solved is that at the time we were using Ethereum. Ethereum was the main thing and Ethereum at the time like line support was not great. So, that was effectively breaking the local first aspect of radical and we didn't like that. Now that has changed apparently and

that's why I added as a caveat stateless not not ether stateless ledgers uh which solves the whole local first approach in general and and it has also an interesting aspect which is coming up uh in in the future with no and and all this type of stuff. um we're moving more and more zero knowledge circuits directly into into um into the local first environment and there are maybe interesting possibilities there.

Yeah, you know that that checks out that that that does make sense and so I think yeah designwise that sounds that is sound I think uh with regards to has anyone done that recently? No, no one of us has done that recently but yeah happy to talk.

Can I add to that? So, I think there's like one one more thing that's worth pointing out is like it's actually quite important in like these self-certifying systems that use just hashes. Like how do you then reference these hashes from an external source that really gives it some weight, some trust weight? And one of the ways to do that, by the way, which we're exploring, is using just traditional domains. Um and so like the fact that you own say a domain like uh you know steve.

com is yet another source and I I understand your skepticism but um the I think the key idea is to be able to do that kind of uh attestation from external systems from which people already derive existing. The problem with with with domains is the base of trust is I can it's a centralized organization at the end of the day and that's not very helpful is it? It is a very high burden to steal someone's domain and if you can have multiple domains in a set like the delegate system uh to lose multiple domains in multiple countries at the same time so that you can't fail over hasn't happened to projects which intentionally work towards antagonizing multi-billion dollar companies and threatening their business model like SciHub still has domains. Lipken still has domains. They cycle first.

So it is a lot better than being making it always paytoplay. You always have to buy cryptocoin first because before you can start an organization.

Yeah.

I I never anything about payments. I said about ledger. I never said anything about crypto.

You want the ledger?

I just make one.

So how Yeah. You could have the own your own ledger just for this purpose. Okay, that would be totally reasonable. But

booting it off Ethereum or some other cryptocoin ledger would mean that you have to pay to build

and I'm very much into ether. Okay, I don't want to turn this into a debate, but I think like I understand both sides of this debate and my my take is like, hey, why not both? Porquo loss as they say. Um or even something like PLC uh like the public ledger of credentials that uh Blue Sky uses. Also a legitimate uh place where you can sort of attest your identity or attest some of your radical repositories.

Yeah. Cool. All right.

Yeah. I mean, yeah, maybe just to add one thing on that one. Yeah, we have spent a lot of time thinking about that and indeed, you know, we end up with this, you know, self-certifying identity is like the simplest scheme because it was just, you know, keeping our properties clean and then letting us grow. Right now we are at the place where we indeed understanding that like oh there are all of these you know identity related problems and you know using external like you know registries of sorts I guess you know solve there are there are multiple you know solutions to that problem as as Daniel said and for us now it starts to be the time to want to prioritize that because you know just the you know 8 to5 519 keys and that's it just that simple thing took us up to this point now we have more users okay like now we need to get a little bit more serious about this. But that's why we didn't prioritize that earlier is the the truth.

We like the simplicity. [laughter]

All right. All right. [snorts] Give a big round of applause. [applause]