Beyond GitHub: Building Open Source on Radicle

Transcript

[music] [music] All right, welcome Mumbai. We're in uh India, the biggest democracy in the world and many other developers of this century are going to come from this country. So let's start with a question to the audience. Who here has used GitHub before? Put your hands up. Okay. Yeah, that includes me. Who has used Bit Torrent?

>> I'm getting arrested. >> No, no, I mean [laughter] only for Linux ISOs, right? >> How do you download Ubuntu otherwise? >> All right. Actually, I have a real anecdote on that. I had one back in 2006 sent to me. They used to send out the CDs. Um, okay. So today we're going to look a little bit at an alternative to GitHub called Radical. And uh I'll give just a brief introduction. So uh here we have my colleague Yoros.

Okay. The clicker isn't working. Okay. Do you want to introduce yourself, Yuros? >> Oh, no. just uh yeah I've been writing software for 20 or so years and I'm really into open source and I thought you know we need a better way of hosting it so I joined the radical project >> and I'm Daniel been building software the last 15 years uh worked on Aragon the DAO platform IPFS lip and most recently on radical and uh with that so the goal today this is a workshop if you have a laptop top that's great. If not, we'll uh recommend you either find someone to pair with or we'll also work

maybe through the workshop um on screen. So, the goal for today is really to get a feel for how using Radical is. We'll first take a look at some of the core concepts behind how Radical works and then we'll actually dive deep and try it out. and uh we're going to look at a radical repository and hopefully you're going to by the end of this workshop actually make a patch and get it merged into that repository. So let's start a bit with the why. So Radical is very much built on the same principles as Git and Git is by definition distributed

and uh in the same way Radical is distributed and peer-to-peer. So there are no central servers. You don't need permission to use it. And uh as long as you have the software installed, you can use radical and you can collaborate and it is sovereign. So uh we have a keybased identity which we're going to look at in a moment. And um that is a sort of foundation for how you collaborate using this keybased identity. Um it is also local first. I think I mentioned that. But you're able to create patches and issues and do everything uh without an internet connection and then you can sync up later with the rest of the network. And

we have this notion of COBS which are collaborative objects. These are like CRDTS in case you're familiar with CRDTS from the local first world, but [snorts] these are all just fancy terms for these data structures that allow you to do operations offline and then reconcile them. So they're by definition they're distributed. So they're distributed data structures that uh allow you basically to make changes and your collaborators to make changes to and then uh consolidate them without any consensus. And there's a nice quote there from Linus towards okay so the first idea is that everyone runs

a node. This is a thing that runs on your computer and um uh when you're online it syncs with other nodes, your changes and uh that's the foundation of collaboration. There's no gatekeepers and there's no central servers. Your identity is an ED25519 key pair. I know that's a mouthful, but it's just a private public key pair. And uh that is the foundation for your identity. And uh we use did keys as the way to represent that public key. That's just a way to uh encode the public key as a string. And

um because of course public keys are not the most human friendly, we have this idea of aliases which are self assigned. So any user can assign themselves uh a an alias and uh that just makes it a little bit easier to uh really find and detect who the users are. Another mechanism that we have to make a keybased identity easier to use is these identicons. And uh the idea is that this is a visual representation of your public key that is deterministically derived. And you know I can generate here different keys and you can see that for every key you

get a different uh emoticon and in fact those are the emoticons that uh you see here [snorts] um for both myself and Yorgos. Yorgos anything you want to add? Um, no. The idea is, you know, you don't need to sign up. Signing up is actually asking permission to do something. You're asking the platform provider or the hosting provider to let you in and let you use the thing. You don't need anyone to let you use the thing. You just run a node, uh, create a key pair, and you're good to go.

>> Are there any questions so far? we can we can make this more interactive than just a talk. So, I mean, I know we're the ones here holding the microphones, but um yeah, in the meantime, if you want to start installing Radical, this is meant to be like a hands-on workshop. Um you can >> you can actually scan this QR code. >> I think you're in the way though. >> Sorry. >> Yeah, you don't want people scanning you. Um, yeah, there's a QR code.

>> That QR code will lead you to a markdown file with the installation steps. But don't worry, we're going to actually have another slide in which um we're going to show it, but it's it's a good moment now if you want to scan the QR code. Um, to those scanning it with a mobile, I'm sorry, it's a markdown file, but I mean the main idea is all the steps there are to be ran in a terminal. So, hence the markdown. So, it's not the most mobile friendly, so to say. Right. So we had this idea that everyone runs a node and that uh key pair the identity is a keybased identity [snorts] and the way it works in terms of networking is that we have a gossip protocol uh that is used to communicate

uh changes that change has happeneds messages are being propagated but they are short-lived and effirmal and uh the actual git repository is synced using the git sync protocol. call. And so in that sense, we're not inventing anything new. We're just using a peer-to-peer TCP connection between two nodes and then running the uh git sync protocol that is defined by the git sort of set of specifications. In fact, we're using under the hood the same implementation that is used by git um in libgit.

>> Yeah. And that's a that's a common thing. You'll see when you use Radical that you're really just using Git um with the same tools that you've been using so far basically uh it because it's all built on top of Git using standard Git features um and then Radical adds some things that are missing from Git. Um for example, when we when you want to clone a repository, you always have to tell the Git, you know, whatever client you're using, you have to tell it where to fetch it from.

you're not telling it what to fetch, but a specific location where it can fetch that. Um, and that's because Git doesn't have any notion of discovery, right? It doesn't know that this is the actual git repo you're looking for and it can go find it from, you know, a list of locations. Radical adds that which git is missing. So with radical you're cloning a specific repository and then you're doing an actual git clone under the hood. Once you found the location you fetch the code [snorts] >> which is what's happening here in the diagram as well.

>> We'll look at that in a moment. But this idea that Yorgos just described is known as content addressing. Has anyone here used IPFS before? Great. So you know in IPFS let's see who can answer this question. How do you address content? What is the thing that you address content by the baffy hash? And what it we we refer to it as a content ID, right? Baffy is actually the base 32 representation of that. But SIDs are content IDs and that's the central idea in IPFS that we address content by what it is, by a hash of the content rather than where it is. And there's a certain trade-off that is made there. But the resilience that you get from it is

because you're not tied to a specific location. You then use whatever content discovery mechanism that IPFS uses. I mean we use a different content discovery mechanism. That's in fact what gossip is for. It's for propagating that content discovery information so that for a given content ID or in our case a repository ID, you can find multiple places to download it. Now collaboration like issues and patches they all live inside the repository using these collaborative objects that I mentioned before.

And uh the key thing to understand is that you can make concurrent offline changes to those and you will have no conflicts. And you can do that offline and everything is signed. And then when you go back online and you're syncing with the peers who are also seeding that repository, those changes are reconciled. And yeah, as I mentioned, every change is cryptographically signed. And now we get into this uh the equivalent of content IDs in IPFS. This idea that every repository has its own identity. This is the identity by which you clone repositories. And so if you

were to clone the radical open-source repository or any other repository on the radical network, there about 15,000 repositories and the network is growing. Then you're going to need a a repository ID which is like this long hash that is derived from the initial identity document. So, Radical is really just building on top of Git. And when you initialize a new repository on Radical, you take a git repository, you run radit. We're maybe going to show that a little bit later. And uh it asks you a question about the name of the

repository, what is the default branch, and the delegates for the repository. Delegate in radical is like the admin of that repository. And when you initialize a radical repository, there's the single delegate. It always starts with a single delegate. The single delegate is in fact your uh identity, your public key represented as a did. As you can see there, this is actually a real repository that if you want, you can already try to clone the steps or in the workshop steps, but I will share a link in a moment uh to when we get into the actual workshop. Um

but the radical repository ID is the key thing that you need in order to clone a repository and that stays immutable that stays the same even as the repository evolves and changes. Do we have any questions before I continue further? >> Okay, that brings us to the second part of this. >> Um, if you can go back, I just >> just want to add like talking about things that are missing from git. Uh, I mean we saw the previous slide said issues.

Issues are not built into git. That's something we get from whichever forge we're using, right? GitHub, GitLab, whatever codeber, you know, forj uh and radical the it's the it's the forge that has these entities like, you know, issues, releases, things we really use and rely on. Pull requests, merge requests, we really use and rely on. They're not built into Git. So, when [snorts] we're thinking about moving away from GitHub, we have to like figure out some way um you know to to still have those. We store these inside the git repo. Um, and then another thing that's missing if you kind of, you know, take a step back and think about like

moving away from GitHub is the settings. And like something that's kind of very different and requires a bit of a mindset mindset shift uh as you move to like the more peer-to-peer decentralized world is like how do we store settings when we don't have a centralized server to log into uh which dictates permissions which is what this identity document does. That's what that allows us to do. Um and because every change is cryptographically signed, we can um see you know who has access to make changes.

Like let's take renaming a repository. >> Can we show a real repository? >> Go for it. Renaming a repository is like typically what you would like you know someone who has admin permissions on GitHub would log in they get you know they go to the interface they change the name they apply they accept. you know this is danger um area stuff and yeah they can do it and that's because they trust the centralized server to rename it for everyone. When we don't have the centralized server uh we have to like everyone else who's participating in the network has to reach the same conclusion about what is the name of the repository.

Um and so in the case of this repository actually we can take this example. So the two dids that you see here, the two delegates, this repository are myself and Yorgos. And you can see that here if I run rad um rad self, you will see this is my did key and that is the same key that we see here. So if I wanted to uh update this identity document and rename it to be um Mumbai guide 2026 I will uh need to give a comment about what is this change about. rename

[snorts] the repository and uh if I go rad ID then you will see that there's these multiple revisions and that the latest revisions revision is active but for it to be accepted ID inspect uh sorry show then you will see that uh Yorgos has not voted on it so we don't have a quorum you need a quorum in order to be able to make these changes because again we don't have a central server that can arbitrate what is a legitimate change. So you need to go through this quorum and uh that requires like a floor of you know a division of the two

basically the number of delegates divided by two floored plus one which in this case is two when you have two one delegate is just 50% and you needed an overruling quorum which is over 51% hence needing two of us that was a bit of a mouthful. >> Okay. >> Okay. Yeah, we went like a little bit into a detail a deep dive there, but um that's just to give you an idea of how like in this peer-to-peer world. Um you have to always remember there's no centralized server. There's no convention unspoken convention that you know GitHub's main is the one we all use, right? which is a convention we've because under the hood it's just git and

there are like just git repositories and there are many main branches but we have this convention that GitHub's main is the one and everyone else needs to reconcile with that here we don't have the centralized server which is what I'm trying to highlight and like the voting [snorts] process shows but um yeah so uh let's try to get a little more hands-on uh those were the slides that's the part of the introduction ction. So from here on it's like meant to be more hands-on and um yeah so people with laptops if you want to participate and if you have trouble setting up I can come over just put your hand up and I'll uh and then maybe for those who don't

>> I'll try to work through it too. One thing I just wanted to point out we had a question here. Do you need help? >> Yeah. Okay. Yos is gonna come over. One thing I wanted to point out, we just literally uh had a security talk and you feel a bit unsafe running a random curl script that I tell you is legitimate, then you can actually go to our quick start guide on radical.dev and you will find all of the links, all of the names of the um radical on different package managers. So if you're on Mac, I see there's a bunch of Mac users. We're on brew, but I mean obviously the easiest way is to just run the script um the installation script. So who here just so I can get a feel already has it installed.

Okay, we have a bunch of hands. Does anyone need help with the installation? Okay. All right. So the first thing after you've installed radical is that you're going to run this rad command. Rad off command is going to create your key. It's going to generate a private key ED25519 to be specific. It'll also ask you to assign an alias so it's a bit easier to know who you are.

Um I'm going to try and see if I can switch to this mic. Uh AV team, is there any chance I can switch to like the stand uh microphone here one? Cool. All right. So, let's get into the terminal and uh rad or off. [snorts] So, I already have a key generated obviously and Rattle off does two things when you don't have a key. You need help? Yeah.

Um, so Rado does two things when you already have a key. Okay, I can switch to this. That's easier. [clears throat] Excuse me, I lost my voice on Monday giving the same workshop. Um, okay. Rad. So, rat off generates a key, but if you already have a key, it loads it into SSH agent. That's because we use SSH agent to safely keep the key in memory. Um, so that we can sign all the different actions. So, every time you engage with an issue, you submit a patch, all of that gets signed by SSH agent.

Everything is signed. Yes. Um there's two mechanisms by by which commits are signed and I'll maybe get into that. But yes, every action that you do in radical is signed by that key. Okay. And you can use this rad self command to see a little bit of information about your own key and where the node is and you know this is the SSH agent and your alias. Um okay. So now that we have an identity, uh you obviously need to give your node some information about other nodes that it's going to sort of connect to uh when it starts. And uh we call

these the preferred seeds. So a seed node is just a node, radical node that is seeding repositories. Typically, a seed node would be a public node in the sense that it has a public IP and it's typically uh running on a server somewhere so that it's always online. Um, you can run one yourself. Um, but that's sort of the key idea of a seed node. And for us to collaborate, we could do that in a completely peer-to-peer sense. But for that we're going to need direct connections between us which anyone who's worked uh who has a little bit of experience with networking knows that NAT is hard and

establishing direct peer-to-peer connections is very difficult. Um and so to make things a bit more streamlined I suggest that you configure this preferred seed here. It's a permissive seed. So it's going to replicate every public repository that you create. And once you do that you can start your node and you can um run rad node status. So um >> yeah so in Mumbai.radical.fyi FYI, you can go to that URL and uh that's the same by the way as the

QR code and then the workshop has that. Yeah, the workshop markdown file. Cool. Should I show the QR code again? Make it a little bit bigger. Oh, I can't. But I can zoom in. Yeah. How's that? Big enough. Cool. Right. Oh, okay. Dark light. What kind of a crowd do we have?

Dark. All right. Dark it is. Okay. So, RAD node start. My node is already running. And uh RAD node status will show me all of the other nodes that I'm connected to. And you can see that I've been connected to some of these nodes for about half an hour. That's I think the last time I restarted my node [clears throat] and um here you can see some of the recent logs. The node is running and now we can get into the fun part of collaborating.

So the key thing that we're going to do in this workshop is we're going to we have a list of Mumbai recommendations. That's what's in this repository that you're going to clone. And uh when you clone it, you use this rad clone command. And I'm not going to get into the scope right now, but when you set scope to all, it just means that you're going to uh replicate all the changes from anyone who contributes to the repository. So with that, I am going to show you the repository. I'll make things a little bit bigger in my terminal.

And another really handy command, by the way, who's already installed it? Okay, great. Of course, I know who to look at uh for some visual feedback. So, a really useful command when you're inside a repository is the rad dot, which will just tell you the radical repository ID. This um and uh let's look at what's in this repository. Oh, sorry. I think I'm in the wrong repository. This is the right one. These are the slides and this is the actual workshop uh guide that I mentioned. So in this repository we literally just have a readme file and in that readme file just have a bunch of

recommendations. Um if you have any other recommendations I would love to get them merged [clears throat] into this repository. Um >> did you have an issue open about that? >> Uh let's see. Do we have any issues? Okay. Someone opened an issue saying that GitHub looks easier. >> Yeah. >> Yeah. I I agree. But by the way, um we're going to look at this in a moment. If you think that GitHub easy is easier because it has a UI, then I'll surprise you with our radical desktop. So now we're looking at the local first radical app which you can use even when other nodes are down. something that you

cannot do with GitHub. You cannot look at your issues. You cannot look at your pull requests when GitHub is down. And GitHub hasn't been very reliable over the last 6 months to say the least. So it might take some consolation in that as uh we software developers know software is a game of tradeoffs and u uh that's the sort of trade-off that you make by uh using something like radical. We think it's worth it uh for the kind of resilience and sovereignty that you get. But uh I hope that we can uh uh convince you also with our UX and DX.

Anything you want to add? >> Yeah, I mean it's never going to be easier. There's a mega corp with billions of dollars uh that wants you on there, that wants to log you in. They're going to make it easy for you. Well yeah. That's when you use radical. Okay. Right. Oh, okay. I'll leave this open. Maybe we can resolve it at some point and make it easier. Or maybe the person who opened it can close it if we convince him otherwise.

Okay. So, we can open issues here too, right? So um and we can attach labels and uh we can do all of the things that you know you might be familiar. We can assign it to different users. We can do all of this offline and um we can also look at all of this in the CLI and uh see the thread [snorts] and that's all nice. We can also look at this via the web browser if you don't want to install the software

or if on your you're on mobile. So we can easily just open this up here. Cannot connect. That's probably because the internet connection is unreliable or no was connected to the wrong node. So this is the radical explorer. This is a read only for now. It's hard to do these peer-to-peer things in a browser, but we're working on a version of the web explorer that is also uh capable of doing writes. But for now it's read only and you can use it to you know review code.

Um yeah you can look at the source code commit history all the things that you're familiar with from other code forggers. Um let's go back to the slides. Right. This is the one. Yeah. Okay. Now I'm going to work through the patch creation process. A patch is the equivalent of a pull request. In fact, patch actually predates the term pull request. Pull request was a term that was coined by GitHub at a time when uh even the Linux kernel development was using uh the term patch. So in a sense, we're a bit truer to sort of the

original G ethos, but we're not going to get too caught up on naming because it is one of the hardest things in software development. So, with all of that prelude, let's get into the terminal and add new spot. Yeah, I forgot the minus B. And now we're we're in this branch. Yeah, new spot. I can go here. Does anyone know a good bar? Actually, Becca, didn't you recommend a good bar? What was the name?

16 33. Is there a space? Great. Cool. If anyone wants, it would be great once I open this patch and get it merged if you can then open another patch to add a URL link to the spot on Google or whatever. But for now, we're going to go with this. I'm going to commit it and uh add Okay, so I've committed this and this is where it gets interesting. So if I go back to the slide, you will see that we have this rad remote that uh we use in

order to effectively get our changes signed because right now we just made a commit with git. And that commit could be signed by uh SSH or GPG. But to get it actually signed by our radical node so that it is signed and it can sync with other nodes, we have to use this RAD remote. And uh if I actually look at the list of remotes, you will see that this RAD remote has this RAD URI which includes who can tell me what this URI is that the RAD remote uses. Does anyone know what it is?

Yeah. No, no, I mean it's literally below here. Do you remember what the RAD dot was? That was the repository ID. So, actually, when you look at the RAD remote, it's just a RAD URI that includes the uh repository ID and my node ID. We're going to look at this in a moment, but this was a very long-winded way of creating a patch. And the idea is that you use uh you push to the radote the head. This is just standard git.

And what we're pushing the head, which is the head of the current branch we're in, we're pushing it into ref's patches. This is probably the only quirky thing about creating patches in Radical. When you do that, it will prompt you to give the patch some message. So, I'll just use whatever the commit message was for now. And I will save that. And you'll see that now we get all of this output. And [snorts] let's work through what we see here. First of all, we see that the change the patch has been opened and that it's been already synced with at least three seeds. By now, it's probably synced with many more, but you can configure how

many seeds you want your changes to be synced with every time you make uh a change that you push to the RAD remote. And uh we can also view it, view it from the radical explorer and look at the changes. And we see 60 1633. And um okay so when you just run git push no no no you didn't rake anything. So first of all it depends a little bit on your default configuration but did you do get git push from which branch? From a custom branch or fromanch >> okay that's okay

>> but that's a very good >> that's a fantastic question. So the next slide is actually going to shed some light on that. >> Well, yeah. Yeah. Yeah. >> No, no, this is where you know you're really testing uh the the developer experience. So, okay, when you push uh so first of all, when you clone the repository, by default, you will typically only get one remote, which is the uh the RAD remote. And the rad remote is that special remote that uses the uh URI that you see here below. And when you push to it, what it does is it pushes from your working copy to your radical storage. So

yes, so your node has a storage folder. It's typically in your home folder. And that folder, the radical storage uh that storage is typically managed by your radical node. So when it's running in the background, it syncs, it gets gossip messages. It looks at which nodes you're seating locally and then it makes decisions about what to fetch from other nodes when it gets their gossip messages. And similarly when you uh open patches or engage with issues and patches it will actually you will make those changes via this thing called the git remote helper or in this case the

radical remote helper. So remote helpers are a completely vanilla git concept, which is to say that when you when git sees sees a rad/ URI, it delegates the push to a special binary that is part of the radical installation. And that will actually take the changes that you're pushing with the git push command and then put them into your storage and then let your node know, hey, change has happened.

Announce it using the gossip to the network. So when you just did a git push, you pushed to the main branch of your nameace. And if your node is up, we should be able to see that from the uh radical explorer. So if I go into the Mumbai guide, what is your uh alias? There we go. And I can see actually one event not to me. So that's what happened.

That propagated to the network. It's kind of like magic. We're looking at it here. And you must be Daniel saying Pinky Anthony. Great name. going to have to tell us the story of that name after >> git name spaces is another standard git feature. Um so we what the convention radical introduces is that as the name of the like as the namespace name it uses the uh public key. So then inside the same uh git repo we can have everybody's uh commits and then from those we can uh deduce what is the canonical main since we no longer have a

centralized one uh to rely on. So Daniel, actually what you could do now is since you pushed it to your own nameace, but it's not in um our master, you could do you could try to run the command again. Oh, we already have a patch. Oh, that's my patch. That's boring. Um let's try to get Daniel's patch in. So I want you to try to run that command that we had before, the git push rad head colon ref's patches. You think you can try to do that?

>> [cough] >> While he does that, are there any questions so far? So for for I know in the beginning we had a lot of hands were raised for people who used GitHub before who loves using GitHub. I'm curious. >> Yeah. Oh, we have one enthusiastic user. >> Two, >> three, four, five. Yeah. >> Okay. Who's a bit dissatisfied with GitHub? >> I'd love to hear it. What do you not like?

>> I'm very dissatisfied. >> Yeah, you're a bit biased though, >> aren't you? >> You don't like the UI? >> Are there any other forges that you do like? Yeah. I mean, there are no magic bullets, right? Anyone else? I just love to like hear some feedback. Someone else who Yeah. Go on.

I mean stack PR are also relatively new, right? Right. Yeah. Yeah. Yeah. Yeah. Sure. Sure. We even use it for uh one of our repositories. But yeah, you can do that. Okay. Let's try and see if Daniel managed to open a patch. Did you? Yeah. Bam. All right. Okay. Now, I'm going to show the process of actually merging it. So, I can use the rad patch command to see these patches. I can even use a desktop app to review it. I could look at the changes here. And I could leave

some comments. And, you know, you can just do the comment thing. That's all nice, but we just want to merge it, right? So, uh, rad patch checkout. Um, and now I'm on this branch which tracks it. And oops, sorry, opened up my Juju UI, but I can look now at the changes and I can see that um I mean I'm just opening it up in Vim, but I can view it using uh any git tool.

So if you use TIG, I can see the diff, you know, here where you're adding it. Um, you know, I I have so many uh erh so many different div tools that I use. Like I can see a change. Wait, not this one. Sorry. One event not to miss. I can see the change here. I can see it in the JJ UI. >> Yeah, but maybe radical desktop. >> Oh, yeah. I not only did I see it, I uh reviewed it. I missed that while realizing I wrote on the board with a permanent marker that someone left there. So >> yeah, I can see obviously the diff in the web browser.

Um so with that I can um I wanted to show maybe another thing that you see we have these like squared brackets. I don't really want this. So I can make these changes and I can actually push them to this patch. And what that will do is it should actually create a new revision. And yeah, let me see what did I did I do that right.

Yeah. Okay, there we go. That was the one. Um, so as a delegate, I mean, anyone can really do this. I can actually look review your patch and not only leave comments. I can actually uh make changes to it and then push another revision uh which you can then even review yourself and uh I'm not sure what's happening here. >> Yes. Well, and not by default. You're going to have to check it out.

it doesn't propagate to your nameace. It's uh it's added as another revision on the patch which is the a patch is essentially a JSON object, right? It's stored as a JSON appendon thing. Um so what Daniel did is add a new revision to this patch from uh you know the changes he so everyone can only push to their own namespace. Um, and then yeah, >> I didn't commit the changes. That's why it didn't work.

Okay. Um, so do that now. Sorry, that's uh so git push rad refs patches. I think it's actually Yeah. Okay. And then I have to give it the patch ID. I'm like going on an side adventure here. So, excuse me. Okay. Refine patch.

And there we should be able to see it now in desktop. You can see that I created a another revision of it and it just removed the square brackets and it has these two stacked changes. And now I could just go into the main branch and uh get merge patches. What was the branch that I was on before? This one, right? 7D. Yeah, I think that was the one. Yep, that's the one. And if I push it now to RAD, it will update the canonical reference.

So the canonical reference is so as we we looked before we saw Daniel pushed into his known namespace I pushed to my nameace by interacting with this RAD remote and so we basically have all of these different views of what the repository is that's how we enable the uh sort of local first property but in order to establish what you would consider the default branch or what you say see when you look at a GitHub repository tory because a GitHub repository is also just another repository. So how does GitHub know to show you what is the current state of the master branch? Well, you know, you have different policies and configuration about who has permissions

to the to write to the repository. And if you say collaborating and say two collaborators, you know, try to push at the same time, they might have a conflict. You'll have to fetch first and then push or you might have to force push. And in [snorts] radical you don't have so much of that because you're just pushing to your own namespace. But in order to establish the canonical state of the repository, we do that by looking at the identity document which defines this thing called the threshold. So if I show the identity document, you'll see that I have a threshold of one and that I have a default branch called main. What that means is that one delegate

either me or Yorgos can push to the our main branch in our name space and it will be considered canonical which is what happened when I pushed my main branch to the radical remote. the radical remote helper saw that I merged these two patches and that the canonical reference the main branch has been updated to sort of the tip of my local branch and this is why now if you go into the Mumbai guide and you'll look at the commits then you will see the changes that uh have all been merged.

>> Yeah. So this uh unspoken convention I mentioned earlier that you know GitHub's main is the one uh what we've done you know we because we don't have the centralized server because we have to take this mindset shift is we have to put it into code how like what is the policy what what is the branch the main branch we present you know to new people that come to this project uh what is the one they should trust and this specific policy says uh we look at uh the well there's a threshold of one so we just look at the latest commit from any one of the two delegates with a threshold of two um we would both have to agree so uh what we

would present to the new people cloning this project would be the last commit we have in common if I push something then Daniel would also have to include that into their namespace and then um that becomes part of their main threat. >> So another thing I just did is I looked querty 2308 um one of the people probably from the audience opened up a patch and I just demonstrated how I checked it out and then I just did a rebase and then pushed a revision. You can see that here. Didn't change anything. I've just rebased it. Um and so now I will go back to uh you know you can see now I'm on this

branch right and uh I can go back to main and I can merge this branch and I can push it and again this will I don't even need to define or add because it's already the default remote but if I push this we will also get another notification about the canonical reference getting updated which is not the kind of thing that you would see when you push the main branch because you're not delegates of the repository. >> But this is and this is also what I meant you know Daniel has been using in that uh process there. He was just using git commands and it's just this special branch uh sorry this special remote uh the RAD remote that makes you know a

little bit of this uh behindthe-scenes magic happen. >> Yeah. And because it's just git, you can use whatever git tool you like. You can use VS Code and you know VS Code has built-in Git integration. So you can see all of this and you can do all of these shenanigans with whatever Git tool you're familiar with. Um I see we have about six minutes left. So I want to leave some couple of minutes for um some questions. So, I'm going to just give you one more challenge for today.

And your challenge is to publish your own repository by using the rattinit command from a git repository that you own just so that you can get the sense of what it's like to initialize a repository. Um, yeah, we looked a little bit at explorer and desktop. One more thing that I want to talk a little bit about is radical artifact. So who here has used git LFS before, right? And git LFS to those who are not familiar believe LFS stands for large file storage.

So, Git LFS is a way to do um to include large files, track large files in your repository without bloating the size of the repository. And so, LFS files are actually fetched out of band. Radical artifact is sort of our take on something like um like git lfs and it is a way to have signed files that live outside your git repository but are tracked within it and you still it's designed so that it's done in a peer-to-peer way meaning that uh you can have multiple uh parties seeing uh the artifacts so you're not reliant on a

single URL to resolve those um everything is signed and verifiable. We use Blake 3 as the hash function and we use SIDS like the content IDs the same ones used by IPFS and obviously they're signed by your key and it's transport agnostic so out of the box it supports HTTP and IRO blobs and we're actually starting to move a lot of the Radical releases to use um to use Radical Artifact because it's relatively new. you can see. Yeah. Go on.

>> Yeah. Radical artifact, in case it's not clear, is a replacement for GitHub releases. You no longer need to upload your binaries and attach them to a release on GitHub. Um, it's the peer-to-peer way to do releases. >> Thank you. That was much shorter, much clearer. We also have, I mean, for the agentic users, I assume all of us are using um agents to some degree. Uh we also have a radical skill which is can be really helpful if you're trying to be productive with radical. Um and there's also a cheat sheet here. We also have a guide. Um and uh with that we're coming to an end. We still have a couple of minutes. I want to open it up

for questions. But before I do, Yorgos, do you have anything you want to add that maybe we could have covered? >> No. No. And we're here for, you know, the rest of today. if you have other questions. [snorts] >> Yeah. So, we had someone in the audience. >> Yeah. Like that. >> Yeah. >> Oh, okay. That's a great question. Um, you want to tackle that? >> Yeah. Yeah. So, I mean, um, CI/CD in a way is already decentralized because you it's easy to self-host your own CI server.

There are lots of solutions, you know, like Jenkins, Woodpecker. So it does what it doesn't provide is the free compute you get from GitHub actions. So like you know when we talk about CI/CD there's the you know self-hosted system that you can have actually run the build and there's also oh Microsoft and other organizations they give you like the free compute to do that. Uh so if you're looking for a replacement for the compute part um you'll have to find you know a CI provider that does that.

any any hosted CI provider as well can be uh integrated with radical. Um yeah and uh >> yeah so I was thinking that I would show um what's sort of our approach to doing modular CI and so with CI typically what you do is you push commits right and those commit usually trigger by some mechanism some CI run whether that's GitHub actions build kite you name it right and so the way that we do that is using yet another collaborative object so we looked at these issues and patches as these collaborative objects. We also have radical job and a job is a way to uh encode these job runs without being

particularly tied to any specific CI provider. And so what we see here is this is actually the monor repo that we use for the radical web explorer and for the desktop app that we looked at. And for that we use both build kite and we also use GitHub actions. We're actually kind of like using we're testing out a number of different CI solutions. But you can actually see here the build kite runs. And what you see here are these are these job cobs. If I actually look at an older revision, you'll probably see even more of these job cobs.

[clears throat] So this is an example where you can have for this commit you know you had these build kite runs that were executed by my other node and then Rudol who's uh one of the core contributors he has this setup where he's using some of GitHub actions free compute to run some of these CI runs and so you know you can see here basically I'm running some of the Rust compilation we also have these like end to-end tests that verify you know UI regressions So all of our CI here is both in build kite but we also run it in >> in uh GitHub actions and that's what you see here. And so really we take a

modular approach where you can use any CI that you like. Uh the challenge really is just getting um those builds to trigger and that is because well you don't have a central server. You want to say something about that? I just want to uh I'm conscious of time. We had another question here. I think >> we just a minute. >> Yeah. Yeah. Yeah. >> How [snorts] can you create a private repo in GitHub? It's is it really private?

It's like I mean sorry it's it's a valid question, right? I'm just uh um uh I think the only like real answer to private repositories is when they're encrypted. So, and I mean encrypted at rest on disk. Um for which there are solutions, there are existing solutions uh which don't require radical or any like you can you know encrypt the repo and still store it on GitHub and actually have it private. Um but uh yeah, Radical does have a feature for private repositories in the sense that they're only shared with a set of uh select nodes. There's a big

vulnerability uh that we've uh discovered, you know, this wave of vulnerabilities that is hitting basically all of open source right now. So don't use them right now. Don't use private repos with Radical at this time. But um >> come back in about 3 4 months and uh you should be able to use radical private repositories. >> Um one final plug as we wrap up is that we just have radical garden. It's just a hosted service. For five bucks you can get a full [snorts] on an always on radical node. Uh and it also supports CI integrations via web hooks and build kite. And so it's just if you really want uh high availability, you can use

that. But of course, you don't have to. You can run a node on your Raspberry Pi or even just on your laptop and rely on permissive nodes to replicate your uh repositories. And uh with that uh I thank you for attending. >> Is there any final question? >> [music]