WEBVTT 00:00.000 --> 00:13.760 I want to send one disclaimer and say that this is nothing to do with what I do for my work. 00:13.760 --> 00:19.640 At the McSmanke Institute for Informatics, so I also do free software and that's what this 00:19.640 --> 00:21.640 is about. 00:21.640 --> 00:27.360 Okay, and I actually wanted to start a bit with my motivation here. 00:27.360 --> 00:35.280 So a bit of a very short story, one of conviction and passion because this is really a passion 00:35.280 --> 00:37.920 project for me. 00:37.920 --> 00:41.960 I'm Lawrence and I contribute to radical and you might be wondering, okay, I mean, you 00:41.960 --> 00:46.280 will find out what it is, right, but why maybe you have read the intro, why do we do 00:46.280 --> 00:48.240 this and so on? 00:48.240 --> 00:54.880 And Phosem is developer focused and we learn about lots of interesting technologies here. 00:54.880 --> 01:00.360 We have learned a lot about peer-to-peer technologies and radically is a project that 01:00.360 --> 01:05.040 really wants to bring this back to software development in one particular way. 01:05.040 --> 01:10.560 So it's about the future home for open source. 01:10.560 --> 01:13.040 I like Git. 01:13.040 --> 01:17.280 You could substitute this with other version control systems, of course. 01:17.280 --> 01:21.000 I think Git is pretty fine. 01:21.000 --> 01:24.640 But what I really like is the decentralized part of Git, right? 01:24.640 --> 01:32.920 The way it was designed to be used, the fact that you do not rely on a central party. 01:32.920 --> 01:38.800 And I don't like decentralized Git, which unfortunately is what large parts of the software 01:38.800 --> 01:42.800 ecosystem in general have gravitated to. 01:42.800 --> 01:49.560 In the free software world, maybe not as much, but in the commercial part and also the overlap 01:49.560 --> 01:57.680 between commercial software, large companies and free software, there's big centralization 01:57.680 --> 01:58.680 effect. 01:58.680 --> 02:03.000 There's this big pool to GitHub and a few other forges. 02:03.000 --> 02:08.560 Of course, there are people that run their own GitHub instances for J.H.O. instances 02:08.560 --> 02:15.120 and so on, but if you really look at the size of GitHub and decentralization going on 02:15.120 --> 02:21.600 there with one company controlling this, this is just frightening, right? 02:21.600 --> 02:27.360 So radical goes back and asks, okay, what about decentralize Git? 02:27.360 --> 02:30.200 How can we make this decentralize Git work? 02:30.200 --> 02:31.480 What is actually needed? 02:31.480 --> 02:37.720 So the idea behind radical is not to come up with some completely different source controls 02:37.720 --> 02:38.720 software. 02:38.720 --> 02:42.720 It's just okay, we take Git, which works, which is widely known. 02:42.720 --> 02:49.720 Then we figure out how can we make it work so that this scales and is one approach to 02:49.720 --> 02:55.040 use Git in a peer-to-peer decentralized way again. 02:55.040 --> 03:02.800 So turns out that I saw radical and what it does with Git and hard work, and that's why 03:02.800 --> 03:06.480 that's why I'm here today, that's why I started working on this. 03:06.480 --> 03:13.280 So yes, it's about this future home of open source, and I mean, yes, I will present radical 03:13.280 --> 03:21.560 today, but anything you can do to work on decentralization of your software development stack 03:21.560 --> 03:22.560 will be beneficial. 03:22.560 --> 03:25.600 We need way more ideas in this space. 03:25.600 --> 03:31.320 There are other ideas, just to mention, I have already said like for J.H.O. before, they're 03:31.320 --> 03:33.080 looking into Federation. 03:33.080 --> 03:37.400 There are also alternatives like Tangled, Building on top of 80 protocol. 03:37.400 --> 03:40.160 There are people that just run their own Git service. 03:40.160 --> 03:43.080 These are all valid in their own sense, right? 03:43.080 --> 03:47.800 Just because I'm presenting radical today, I'm not trying to invalidate any of these other 03:47.800 --> 03:48.800 ideas. 03:48.800 --> 03:53.640 I'm just presenting one in this whole toolbox, and to my knowledge, radical is the most advanced 03:53.640 --> 03:54.640 peer-to-peer forge. 03:54.640 --> 04:00.240 I know, if you know, I'm any better than let's talk, but so far, I think we're pioneering 04:00.240 --> 04:05.240 the peer-to-peer part of this. 04:05.240 --> 04:14.520 Maybe to drive home-wide the strongest, I think, or how it became the strongest. 04:14.520 --> 04:19.680 It's a project that has been going for a while, and has tried out different ways of doing 04:19.680 --> 04:20.680 this. 04:20.680 --> 04:27.360 There were previous iterations that were based on IPFS, influence by secure scuttled 04:27.360 --> 04:30.400 but and things like this. 04:30.400 --> 04:31.840 These were the previous iterations. 04:31.840 --> 04:39.040 Now it just works on top of Git, uses Git to synchronize, so really when you synchronize 04:39.040 --> 04:44.040 on the radical network, you just do the Git synchronization protocol and not some other 04:44.040 --> 04:48.840 file system file sharing protocol. 04:48.840 --> 04:55.560 Radical is now developed on Radical since roughly three years now, and we have released 04:55.560 --> 05:01.400 version 1.0, quite a while ago, and we're now at 1.6.1, and pushing onwards. 05:01.400 --> 05:07.560 Our release cadence is roughly one release every one and a half months, currently, and 05:07.560 --> 05:11.960 we are trying to get to one release per month. 05:11.960 --> 05:18.920 So we actually have luckily, we have two talks about Radical at first them. 05:18.920 --> 05:23.320 You are now in the talk that is more focused on the peer-to-peer stuff. 05:23.400 --> 05:30.920 Also, very much influenced by the local first idea, which obviously ties in well together 05:30.920 --> 05:38.120 with peer-to-peer, but I will be not talking so much about the local first aspect of it. 05:38.120 --> 05:44.600 If you are interested in that, phinto-haps will be talking about that, basically right after 05:44.600 --> 05:50.040 my talk in a different building, in a different developer room, just so you know, okay, 05:50.040 --> 05:51.320 so you can also check this out. 05:51.320 --> 05:58.360 And this is in particular for our social artefacts, because if you think about patches, 05:58.360 --> 06:03.160 for code review, think about pull requests, issue tracking, and so on, if you just 06:03.160 --> 06:07.400 may even put that into git check in a two-do.txt file or something, then you will get 06:07.400 --> 06:13.640 like merge conflicts on your two-do.txt, which is, yeah, I'm not really nice to work with, 06:13.640 --> 06:19.160 so we use CRDT's to work around that. But as I said, this is not this talk, 06:19.160 --> 06:24.360 it's the other one. So this talk will be about more the peer-to-peer aspects. 06:24.360 --> 06:30.040 So there are no servers, there are gossiping between peers. There is no central user database 06:30.040 --> 06:41.080 like with GitHub, GitLab, and the likes also not with the federated setups where at every 06:41.080 --> 06:47.000 federation point you have a user database, so we don't do that. And the ideas, of course, 06:47.000 --> 06:52.280 that users of the radical protocol kind of share their storage and their availability. 06:52.280 --> 06:57.400 So you should be able to contribute to the network in that sense. 06:58.360 --> 07:03.240 Maybe one detail here is you probably know that on GitHub you can start a repository, 07:03.240 --> 07:06.600 and oftentimes we get the question, okay, how do we do that on radical? 07:06.600 --> 07:11.960 And our answer usually is, well, forget about just starring and incrementing a counter 07:11.960 --> 07:17.960 in a database, we suggest you just replicate that very repo, which means you download a copy 07:17.960 --> 07:24.520 of that repo to your computer and you make it available to be shared by others, which we think 07:24.520 --> 07:31.560 is much more sensible than just putting a star on some website. But okay, and the user is always 07:31.640 --> 07:37.720 in control, this decision of which repo do you want on your machine is yours, and there's 07:37.720 --> 07:45.560 no way that we will ever like interfere with that, of course. Just so you get a better idea of what 07:45.560 --> 07:51.560 is like looks like, the look and feel as a radical user, I still want to go through the three main 07:51.560 --> 07:59.400 interfaces that we have before we get started. So there, of course, is a CLI interface. 08:00.360 --> 08:04.440 You can see here, this is just the list of repositories that I have and the very left, 08:04.440 --> 08:11.720 you have the name, the repository ID, which is some sort of hash, the visibility of the repository. 08:11.720 --> 08:16.280 So you can see that most of the repositories I have on my machine are public, but there's also 08:16.280 --> 08:21.800 the possibility to have private repositories ahead of the repository and the description. 08:22.440 --> 08:30.600 Then we have a way to obviously inspect which other peers, your node is connected to, 08:30.600 --> 08:34.440 so this is just basically the list of connections you currently have in the network. 08:35.720 --> 08:43.400 By default, your node, if you don't change any setting, will attempt to hold eight connections, 08:43.400 --> 08:50.920 so it will attempt to mesh out to eight other nodes, which then makes it usually very quickly 08:50.920 --> 08:59.240 to converge on the latest status of a repository. Two onion nodes are shown here. I didn't 08:59.240 --> 09:05.000 configure the connection properly, but onion connections are supported out of the box. 09:05.000 --> 09:14.440 I think I disabled it on when I did that screenshot. Then you have things like patches, 09:14.440 --> 09:19.640 so this is the history of a patch. Think about it as a merge request or pull request, 09:19.640 --> 09:25.240 so you can see the updates, you can see the revisions that were posted. These revisions are 09:25.240 --> 09:31.000 immutable, which makes a lot of sense for reviewing, so when someone posts a new revision, 09:31.000 --> 09:39.000 you have this clearly identified thing, what is a revision not something floating around on 09:39.000 --> 09:47.240 a website that changes and so on. Then there's a list of patches where you can get the status. 09:47.320 --> 09:54.440 We also have a desktop application, which essentially shows the same information, but it's not 09:54.440 --> 10:03.400 a CLI, it's a desktop app. You can also search through your repository listing on a different 10:03.400 --> 10:11.640 machine, on a desktop app. You can do the code review features are a bit more advanced on the 10:11.640 --> 10:17.960 desktop app. You can do like line comments and so on, and then we also have a web application, 10:17.960 --> 10:25.400 which, yeah, to refer, looks a lot like the others, so the code website you already know, 10:27.640 --> 10:33.000 just makes it a little bit easier to find out more about the radical-mated data, 10:33.000 --> 10:40.280 like who owns the repository, what is the repository ID and so on. Right. And now, 10:40.280 --> 10:44.600 a bit about the high-level design, as I mentioned in my introduction, we build on top of 10:44.600 --> 10:52.200 Git, okay, so we try to use as much of Git, and it's nice features as possible. So by using Git, 10:52.200 --> 10:59.240 we immediately get like continuity, immutability of data, and efficient sync protocol, and relatively 10:59.240 --> 11:07.320 wide acceptance. So by putting, for example, all the social artifacts, like issues and patches, 11:07.400 --> 11:15.720 into Git, we also get efficient syncing of these. Right. We also get these nice immutability effects 11:15.720 --> 11:22.200 that a revision of a patch is in some sense. It's not exposed to US that, but it's in some 11:22.200 --> 11:30.120 sense a commit, so it has also a commit ID and it's immutable. And yeah, this makes it 11:30.920 --> 11:38.200 it makes it relatively easy to also replicate and so on. But Git, I mean, if Git would have 11:38.200 --> 11:45.640 been the perfect peer-to-peer system to do development, then people wouldn't have jumped 11:45.640 --> 11:51.480 onto Git up, right. So there is something, something that is missing, that's the reason, 11:51.480 --> 11:58.120 why this even is, or part of the reason, why this ecosystem even developed in the way it did. 11:58.520 --> 12:05.080 And we think there are a few important aspects. So we have to add something on. So 12:06.840 --> 12:12.520 globally, unique repository addresses. Well, now if you go around here and watch different talks, 12:12.520 --> 12:19.720 in many of these talks, you will see github.com slash something. So obviously, I know that technically 12:20.680 --> 12:28.920 it's not the one de facto global unique address space, but it's certainly the address space 12:28.920 --> 12:35.720 that is controlled by Gitup.com and these addresses have become very prevalent. So if someone reads 12:35.720 --> 12:41.560 off their slide and wants to mention the repository, they will usually even omit the prefix Gitup.com 12:41.560 --> 12:48.440 and they will just say, you know, this slag component of the URL. This is something that is, 12:48.440 --> 12:57.800 of course, very, very valuable. What we are doing is we have a way to globally and uniquely 12:57.800 --> 13:06.600 address repositories. In our case, this is a hash and you can look up repositories via the hash 13:06.600 --> 13:12.840 name and then from there, you can look at different metadata of the repository, which also contains 13:12.920 --> 13:22.360 a human readable name and so on. But we think that this slag of global addressing is a bit of, 13:22.360 --> 13:29.320 I mean, a bit of a problem where we want to improve Git, because what doesn't seem to work 13:29.320 --> 13:35.240 is that you have many different git servers and you have to configure remotes all by yourself. 13:35.240 --> 13:39.960 If you want to have lots of connections to different remotes, because you are in a peer-to-peer network, 13:40.920 --> 13:46.680 with just playing it, you would have to set up each and every remote. So for every 13:46.680 --> 13:52.200 collaborator you want to work with, you would probably have a remote. And for each collaborator, 13:52.200 --> 13:56.760 you would have to think about addressing that collaborator, like what is maybe their IP address, 13:56.760 --> 14:04.440 or which is the onion service that they are running and so on. And we want to step away from that 14:05.240 --> 14:10.920 and address all repositories the same as kind of a view onto the network. 14:12.360 --> 14:18.040 Then of course you need something for metadata. As I mentioned before, this metadata of 14:19.320 --> 14:26.440 a human readable name is important, but it's slightly more than that. It's like who governs 14:26.440 --> 14:30.440 the repository, who gets decide to push to which branch of the repository, 14:31.240 --> 14:40.520 what are like extension points for the repository. Maybe you want to also note where you can find 14:40.520 --> 14:46.680 mirrors of the repository and so on. So we also have a schema for that and we do access control 14:46.680 --> 14:56.920 over this and you can actually, we have a mechanism to share the ownership of this repository 14:56.920 --> 15:03.240 metadata and identity document, which then doesn't live at one person's name space, but at the 15:03.240 --> 15:11.880 name space of the repository. And if, for example, you want to migrate a repository that's 15:11.880 --> 15:17.800 like a regular Git repository onto a radical, then basically the only thing you do is you create 15:17.800 --> 15:25.560 a new address that is based on the initial metadata and work from there. And if you ever need 15:25.560 --> 15:32.440 to take up the work of someone else, like the project went dormant and you want to revive it 15:32.440 --> 15:38.040 and you want to bring it to radical, you can still do that. If you are in the case that you 15:38.040 --> 15:44.600 have to fork a repository on radical, then what you would do is you create a new address for it 15:44.680 --> 15:52.280 and add the respective metadata. And something I've also watched the talk this morning about 15:52.280 --> 16:01.320 the PGP and the nicety of a completely self-sovereign identity. And yeah, that's also something 16:01.320 --> 16:10.040 that radical supports. So in in in in radical every every user is really self-sovereign. So it's just 16:10.040 --> 16:20.600 an AdWords 250519 key and from there on this is how we bootstrap everything. We lack a few 16:20.600 --> 16:26.600 features. I have to be honest in terms of like migrating your key, exporting your key, multi-device 16:26.600 --> 16:34.280 and so on, but this is all on our roadmap. And this idea that the user is in full control over 16:34.360 --> 16:41.880 their identity is still fully respected. Yes, and the discovery of replicas, of course, if you do 16:41.880 --> 16:48.040 like if you think about just using Git alone and you want to discover who else might have an 16:48.040 --> 16:54.760 interesting copy because they have written a patch or so without any server, would get really 16:54.760 --> 17:00.520 tricky to set up the remotes and everything. So radical also, of course, the nose in the peer 17:00.600 --> 17:07.640 to peer network, they will discover each other and this is how you how you can step like you 17:07.640 --> 17:19.240 can solve the problem of how you discover someone else's work basically. Okay, so I'm going to start 17:19.240 --> 17:25.560 with what happens after a push. So suppose you're working on a radical repository, you have 17:25.560 --> 17:32.360 implemented something nice, you made a commit, now you're pushing. Git push in this case is local 17:32.360 --> 17:39.000 first, right? So what happens when you push code on radical is not that it connects to some server 17:39.000 --> 17:45.720 and pushes the code there, but the operation for like in the first step is actually local, right? 17:45.720 --> 17:50.760 So this is implemented using a mechanism that's standard called Git remote helpers. So we have 17:50.760 --> 17:56.680 implemented a Git remote helper which just moves the objects that you're pushing so the commit 17:56.680 --> 18:01.720 and the tree inside of it and recursively the trees and the blobs and everything. So basically 18:01.720 --> 18:08.360 your changes moves them across only on the file system. So moves them to a specific 18:09.000 --> 18:14.040 other Git repository that you have in your file system that maps one to one to your working copy 18:15.000 --> 18:22.040 and from and this is this is very fast usually because it's just on the same file system and then 18:22.040 --> 18:27.160 there is a long running process which we call the radical node which will pick up these changes 18:27.160 --> 18:33.240 and the nouns that these changes and the changes to your references to the local network. Okay, 18:33.240 --> 18:41.880 so you will never actually push to some other node. You just we just still kept this 18:42.520 --> 18:49.000 nice mental model of pushing because this gives a clear separation of what is your working copy 18:49.000 --> 18:54.840 like your checkout the one that you work on locally where you have maybe intermediate commits that 18:54.840 --> 18:58.680 you're not willing to share with anyone that you're still cleaning up, you're revasing, 18:58.680 --> 19:05.640 maybe you use JJ so you will do all kinds of crazy things and then you have a Git push step 19:05.640 --> 19:11.800 which then maps to okay now I'm pushing my changes to the network but what's really happening 19:11.800 --> 19:15.800 is you're just pushing it locally and then you get an announcement. 19:23.400 --> 19:27.880 By default yes but you can disable that. So the question sorry the question was does 19:27.880 --> 19:33.240 pushing wait for the changes to propagate over the network? By default yes there are some 19:33.240 --> 19:38.440 settings the default settings are you can nominate preferred seats for which you want to receive 19:38.440 --> 19:44.760 a confirmation that they have received your changes and you have a replication factor which by default 19:44.760 --> 19:51.240 is 3 so you wait for three other nodes to confirm that they have received your changes and then 19:51.240 --> 19:59.400 the push will be completed but you can configure it to not wait so the like all of this announcement 19:59.480 --> 20:06.200 just goes on in the background which then means it's really fast yeah follow up question. 20:09.480 --> 20:15.800 The question was what happens if the radical node is not running I will answer that on the next slide 20:15.800 --> 20:26.360 okay so the radical node these clients which I briefly showed before we have CLI desktop we have a 20:26.360 --> 20:34.760 tool that I did not show we have an HTTP demon HTTP demon which gives you basically an HTTP 20:34.760 --> 20:41.480 bridge which is optional which I also didn't show but they interact with with radical via two 20:41.480 --> 20:47.720 pathways so first is radical storage which is this other location where we keep a copy of the 20:47.720 --> 20:55.160 HTTP repository with other with more namespaces and there is the radical node process right 20:55.880 --> 21:03.400 and so the push that I actually mentioned before interacts with them both the push first pushes to 21:04.680 --> 21:12.040 the radical storage so it updates radical storage and then it notifies the radical node that there 21:12.120 --> 21:17.800 should be an announcement sent to the network and so the question was what happens when the radical 21:17.800 --> 21:24.200 node is offline well then only the first part will happen so you will push to storage and then 21:25.800 --> 21:31.240 the remote helper will realize that the node is offline and it will actually tell you you just 21:31.240 --> 21:39.240 didn't offline push the reason is that your node is offline when the node comes online it will be 21:39.240 --> 21:45.880 announced to the network and the way we can detect this is that we have a different connection 21:45.880 --> 21:53.960 to the node as well so this is just a unique socket which is where you just exchange JSON messages 21:53.960 --> 21:59.320 I mean you you don't do that yourself of course but the CLI will or and the 22:00.280 --> 22:06.040 key to remote helper will do that and they will see okay there's no no radical node running on the 22:06.120 --> 22:11.240 other side and then they will tell you you can start it using red node start and if you do that then 22:11.240 --> 22:22.840 you you will get the announcement the question was whether radical node is a system white 22:22.840 --> 22:29.400 process or user process you can do both the recommendation is for like an end use a machine like 22:29.400 --> 22:37.320 you as a developer you would run it for yourself but we also have the setup of people that 22:37.320 --> 22:42.920 just want to use a server or some other machine the Raspberry Pi that you have lying in your 22:44.040 --> 22:49.960 cell or whatever to replicate over the network and for these people they would run it as a system 22:49.960 --> 22:59.000 service the question is what is the mechanism for activating the service so we distribute 22:59.160 --> 23:07.800 system deconfig files and we also have the possibility to just use red node start which will just 23:08.440 --> 23:14.920 fork off the process and keep it in in the background but I think I can answer more detailed 23:14.920 --> 23:24.600 questions after the talk if that's fine yes the system service can be socket activated so the 23:25.560 --> 23:31.720 yeah and then this this appears to other nodes so the initial question is of course how do I find 23:31.720 --> 23:38.200 how do I find an initial node to peer with currently we do bootstrapping via two nodes that we 23:38.200 --> 23:46.600 run these nodes are also reachable via tour using onion services and we have like conceptually 23:46.600 --> 23:55.080 we have figured out how to use DNSSD in the future but it's not yet implemented and we might 23:55.080 --> 24:02.600 also combine this with a DHT in the future so for now things are working quite well but we understand 24:02.600 --> 24:12.280 that yeah bootstrapping via some specific node might not be might not be as resilient and of course 24:13.000 --> 24:19.560 I can also mention this later if there's a question but of course you can basically connect to 24:19.560 --> 24:25.800 your own network okay so you don't have to use these bootstraps service you can you can use 24:27.000 --> 24:34.520 yeah any any particular configuration okay so now I want to talk about the peer-to-peer connections 24:34.520 --> 24:40.120 so what is actually this connection between two radical nodes it's a noise connection over TCP 24:40.280 --> 24:47.400 and inside this TCP connection inside the like the noise wrapped TCP connection 24:48.600 --> 24:54.200 we have a simple multiplexer the design is inspired by quick and they're basically two sub 24:54.200 --> 25:00.920 protocols in there one is the git protocol which is just for syncing so it's really the git push and 25:00.920 --> 25:07.640 fetch you know and then we have the gossip protocol which is to announce metadata which is the 25:07.720 --> 25:14.920 things that I mentioned which git itself doesn't natively support and the thing can also be configured 25:14.920 --> 25:23.000 to run over toy using socks out of the box so it's relatively easy to do that and to be honest like 25:23.000 --> 25:29.320 this protocol is relatively simple I will now go into the details of the messages that are being 25:29.400 --> 25:38.600 exchanged but this is not rocket science okay so I will just mention messages of two different kinds 25:39.480 --> 25:45.480 I will omit informational messages they are not really important and keep alive messages so you're 25:45.480 --> 25:51.480 left with three different kinds of announcements that your node will send and one subscription message 25:51.480 --> 25:58.600 that your node will send so what can you announce you can first of all announce the node okay so the 25:58.680 --> 26:05.640 node can say hello this is my this is my public key these are the addresses that I'm willing to 26:05.640 --> 26:11.320 share with the network of course you don't have to share any addresses for connecting to your node 26:11.320 --> 26:18.760 one of these addresses kind of course be onion service so this is all like making your node 26:18.760 --> 26:27.640 connectable by others is like all opt in and can be done via Thor and the second message is 26:27.640 --> 26:33.160 the you can announce the inventory of your node which basically is the list of repositories that you 26:33.160 --> 26:43.560 have this must also somehow be known and finally per repository you can announce that a reference 26:43.560 --> 26:49.960 has or the list of references has changed so when you push you would change I don't know say 26:49.960 --> 26:56.680 ref's heads main in your name space and this is basically the content of the announcement note that 26:56.680 --> 27:05.000 all the refs are signed using your own identity so this can be also relayed and when you actually 27:05.000 --> 27:11.880 receive like when your when your node decides to fetch these changes from another node it can be 27:12.040 --> 27:18.280 cryptographically verified that these are the commits that were originally signed by the user 27:18.280 --> 27:26.760 who owns the specific reference namespace and yeah it's I mean this is not this is not very 27:26.760 --> 27:32.920 complicated it's just three different layers of granularity of things that you want to announce 27:32.920 --> 27:40.520 through the network and then on the other side you have subscription messages which are 27:40.840 --> 27:47.720 currently just bloom filters over the repository ideas which also include a start and endpoints you 27:47.720 --> 27:55.880 can you can basically say the validity of a subscription and also it's usually pretty simple 27:55.880 --> 28:02.040 you would usually subscribe to the repositories that you have on your machine because you're interested 28:02.040 --> 28:10.440 in getting new information about them okay before I close off I think I have around 28:11.080 --> 28:18.440 two minutes left the network today I want to just show you okay I talk to you about this nice 28:18.440 --> 28:25.160 ideas and all of these comes concepts how big is this thing we have one node which just measures 28:25.160 --> 28:30.280 activity on the network and I just want to show you some numbers so the number of repositories 28:31.160 --> 28:41.400 so here this is okay you cannot see the my pointer but just here in the middle middle of the screen 28:41.400 --> 28:48.680 there's this number 25 this is the change of the year so to the left we have 2024 and then to the 28:48.680 --> 28:55.080 right we have 2025 and just recently we switched over to 2026 of course and the number of repositories 28:55.160 --> 29:03.560 is growing let's say roughly somewhat linear around 5,000 repositories with a bit of pickup 29:05.240 --> 29:11.880 the number of nodes has been increasing a bit recently so the number of weekly active nodes 29:13.320 --> 29:20.200 let's say is around maybe a bit more than 400 maybe it's 450 more maybe 500 let's see how many of 29:21.160 --> 29:29.320 those stay active but it's not just 5 nodes okay so people are using this people are using this we also 29:29.320 --> 29:34.840 have a permissive seed nodes which just will pick up any new repository and we'll start replicating it 29:36.680 --> 29:45.880 the number of pushes is also picking up a bit so it's quite nice to see this metric that 29:46.520 --> 29:53.480 people are just pushing more code the number of patches is also picking up a bit we have more than 29:53.480 --> 30:03.400 30,000 patches on the network currently I will skip over this and in yeah the road ahead we know that 30:03.400 --> 30:11.160 we still have like room to grow we can improve our peer-to-peer technology but the point is that 30:11.240 --> 30:17.560 radical is in a place where it is all possible okay so we have not maneuvered ourselves in a 30:17.560 --> 30:26.840 world where we now have to go back to servers or whatever we will make it much much better I cannot 30:26.840 --> 30:34.440 go into to detail one thing is multi device support that we're working on and yeah feel free to 30:34.440 --> 30:40.520 talk to me anytime I will be at the open local first after party today check us out online 30:40.520 --> 30:42.520 and thanks very much for listening