 OK, so we've got another lightning talk from Alexis Celia. Cool, hey. So I'm Alexi, or CloudHead, and I'm going to talk about the problem of peer-to-peer code collaboration and what we're doing at Monatic around this. So I'd like to start with Git, because I think this is today the foundation for code collaboration. It's the common ground. And what I mean by that is that despite us using maybe GitLab, GitHub, or mailing lists, or whatever it is, there's always at the center of that Git, at least for most people. And if we want to talk about code collaboration, therefore, we should start with Git. However, there are a few things missing from Git as a protocol. And this is why things like hosted platforms are so popular. So I broke it down to three categories. There's discovery. So this is the problem of finding change sets to merge, or finding peers, finding remotes, places to push to, things like that. Canonicity, which is to know which is the upstream that I should download my changes from, or I should download a release from. And social artifacts. So the bare bones Git only supports code. And if we want things like issues and pull requests or things like that, we need something extra. So let's look at what has been done to resolve these. So first of all, we have mailing lists. So this is kind of the first solution that there was. And so it's fairly simple in a way. But in terms of user experience and usability, it's not great. And so from there, we kind of moved towards what I'm calling hosted platforms. And here we have our usability. And it's become really mainstream. But we have another problem, which is a lot of these are not free software. They are not necessarily resilient in that they are run by for profit companies. And they're controlled in a way that does not allow communities to sort of stir them in the direction that is best for the community. So what does peer-to-peer have to say about this? Is there something we can do with peer-to-peer technology that could fill this gap that the protocol has in terms of code collaboration? So first of all, just to explain why we would want to do this. So peer-to-peer systems are resilient. And this is the most interesting thing about them. They're economically resilient, which means that they don't depend on making a profit. And this is simply because a burden is shared across the network and the community. So typically users host nodes. And therefore, we don't need to pay for hosting. Politically resilient, which is to say that there is no authority or country or government that can shut down a peer-to-peer network easily, for everyone at least. And finally, technically resilient because there's no single point of failure. It's quite hard to DDoS or to DDoS a peer-to-peer system. So before diving into our solution, I want to talk about an example of a peer-to-peer system that I really like called Secure Scuttlebutt. And the reason I want to talk about this is that we're going to take some inspiration from it for our code collaboration solution. One of the coolest things about Scuttlebutt is this what we call a social overlay protocol, which is that essentially replication works based on your social network. So in the center here, you have the user in the pink circle. Then you have a circle of friends and a circle of friends of friends. And everything within the two circles is replicated by the user in the middle. Everything out of the circle, so the dotted little squares, are not replicated. So essentially, you choose what you replicate based on who you follow. And you sort of, by proxy, choose friends of friends. And you also replicate those. And this has proved to work quite well, at least for the size of networks Scuttlebutt has. Another cool thing about this is that you essentially so identities are cryptographic. They use public keys. And therefore, it's very easy to verify if something is legitimate by just verifying the signatures on the content. And we're also going to use this property. Cool. So what about code collaboration? So how do we take these ideas, this kind of Scuttlebutt ideas, and the things we talked about, resilience, and how do we get to a code collaboration solution? So our project is called Radical. And Radical is essentially Git plus peer-to-peer. And there's a few properties it has that I'm going to introduce quickly. Of course, it's offline first, so it keeps that property that Git already has. It's secure. In the same way Scuttlebutt is secure in that it's all based on cryptographic identities. And so everything is signed. Every single object in the network is signed by someone. And of course, it's peer-to-peer in the sense that you don't really need a server, although in some cases we'll see it could be useful, but it's not required. And the design is based on three technologies which we take our inspiration from. So Scuttlebutt I just talked about, where we take the follow graph, but instead of a social network, we use a network of clones, essentially, of repositories and their remotes. There's Tough, the update framework, which maybe some people know about, which is a way to sort of authoritatively update a set of maintainers, for example, or a set of metadata around a project, even under attack like a stolen key and things like that. And finally, Git, which I already talked about, which Radical is really based on. So why Git? So of course, we talked about it as a common ground for source code collaboration, but it's actually cool for peer-to-peer in even more ways. So for one, it's optimized for full replication, so this is great for peer-to-peer offline for systems. Second, it's designed for the Bizarre model, and it turns out the Bizarre model, where there's no real central server you push to, works really well for peer-to-peer, where there typically isn't a central server either. So this works really well for us. Finally, Packfiles. Packfiles are really, really cool, and it's one of the reasons why certain sort of peer-to-peer networks didn't work for us like IPFS, and I can talk more about this after the presentation. Because Packfiles is an interactive protocol which makes replication super, super fast, and most of you know about it, so I'm not going to go into it. Cool. So let's talk about the architecture of Radical quickly. We don't have that much time, but I think just kind of going briefly into it. So each user essentially is this yellow sort of square, and each user runs two or has two essentially copies, which are not really copies or hard link, but they're two logical copies of the repository. There's one working tree, which is the working copy, which is the one you kind of edit and commit, and this is what you use day to day. And there's a hidden replicated copy, which is what's being replicated to the other peers. And so from the working copy standpoint, it looks like typical if you'd use GitHub or whatever, but in the replicated copy, we have other things. So we have, for instance, remotes of remotes. So I don't know if you can read it, but you can essentially, we store two degrees out of all of our remotes. And there's some other sort of hidden branches, which give metadata around the project. So the concept of a project is just kind of like a set of repositories that all have the intent to be one thing, one logical thing, and a contributor. And this is the information on the specific clone or specific tree essentially that you have on your computer. And so the replicated copies sort of replicate amongst each other, and the user pushes locally, essentially it's like a file protocol push, so it's instant. But the git push is when you wanna publish, when you wanna make something public essentially. Before that it's just kind of your own copy. And so diving a little bit into the, what is this idea of project and why do we use tuft and things like that. So this is kind of a mock view of this project file. And so it's essentially in a disjoint branch, right? It's a branch that is hidden. And you have first like project name, but the most important thing is you have a list of maintainers, right? And these are public keys. And updating this list of maintainers requires essentially a signature from a quorum of maintainers. So you can essentially verify this when you clone a project, you can verify that the code is essentially approved by the maintainers in some way. And the way this works is that this initial project file, which has the initial list of maintainers, is hashed or it's committed and the commit hash becomes a project ID, right? And so that's what you share. And so when you clone a project, you have the project ID, you verify the project metadata file, and you verify, you sort of go through the history of that file, which is again in its own branch, and verify each step, making sure there's a quorum of signatures if there are updates like adding maintainer, removing a maintainer, and so forth. And then each clone, so there's one of these project files for the entire project, for the, yeah. And there's one of these contributor files for each clone in that project, right? So each person will have their own contributor file, which has their signing key, and which also has refs that are signed by that signing key. So this is kind of the counterpart to that, which says that I as a contributor or maintainer, right? I'm signing this reference saying I approve of this, this is a legitimate change, right? And so in a peer-to-peer network, you can sort of attest that things are authoritative basically, and you make sure that someone hasn't just, you know, cloned a project, changed the maintainers, and then signed a bunch of refs, and you have no idea if this is still something you wanna build and use essentially. In terms of replication, I'm not gonna go into lots of details either, but essentially we're building a gossip-based protocol where when you have a new ref for something, you just announce it to your connected peers. You say, hey, here's for this project ID, here's a new ref, and here's the hash of that ref, right? And then the peer will just fetch, and they will fetch through the Git protocol because that's what's super fast. Fetch the ref, of course, they do all the validation, then if it's the first time they see your project, they will go through the whole project metadata first without even having to clone the source code, and that's one of the cool things is that having source code in one branch and having metadata and the other things in other branches, you can sort of do a shallow clone and just kind of verify the authenticity of the project before you download the whole source code. Yeah, and by the way, I'm not talking about how we do issues and PRs and that kind of thing here, but it's the same principle, so there's gonna be hidden branches with issues, with revisions, and so you could also, maybe you're just interested in issues and you don't want to download the whole source code because you're a user who is not a developer and you just want to create an issue, right? So these will work kind of in the same way. And that's about it. You can find out more information on the website. It's still in heavy development, but there's more info there. So we've got a minute for questions, if I could just. Is there a way to revoke a maintainer if somebody goes rogue and starts putting malicious changes in? Yes, so is there a way to revoke a maintainer? Yes, again, it depends on kind of the quorum and the rules of your project metadata file, but essentially, if it's two out of three, for example, and you want to remove one maintainer, you need two signatures, and then of course the person downloading the project will verify that that was legitimately removed, that maintainer was legitimately removed. Sorry? How secure is radical? That's a complicated question. So as secure as can be. So we're building it, we're designing it in a way that we're using everything available to make it as secure as possible. And as I said, like everything is signed and can be verified and attested, essentially. Okay, awesome, thank you very much.