 Okay, today I'm going to present two projects. One is a general purpose distributed hash table, which is called a bulletin board and another project that works with this general purpose distributed hash table, which is called Weigard peer-to-peer project to set up Weigard VPN connections where peer-to-peer. So what always annoys me is that it's really hard to connect to computer these days. I mean, if I want to connect to my home server, I usually have the dynamic DNS for that and you have to set that up. And if I want to connect to computer of my friends, you also have problems because of the nut in between and this is the problem that I'm trying to solve with these two projects. For that, we need a way to store the IP address of the computers, the external IP addresses. And this is where the distributed hash table comes in. So bulletin board is based on the Cadmium protocol. And before I've been looking for distributed hash table that you can use for these stuff, but the problem that I found was that, that for example, famous use of a DHT is the BitTorrent network. And these networks only accept information that is for BitTorrent, yeah, for BitTorrent peers. And there's no general purpose distributed hash table. So I came up with this bulletin board that you can also use for your projects if you like. It's based on the Cadmium protocol, which means that down here you have the peers and every peer generates a ID, which is three bits in this case. And let's assume you have this peer and now you wanna look up information under a certain key and this key also has three bits. And what's how it works is that when you have this peer you know the peers in this tree that the nodes make up very well, but you don't, the further away you are in the tree, the less you know about the other nodes. And the idea about Cadmium is when you wanna look up, for example, this ID here, so this node is responsible for storing this ID, then you ask any peer in this neighborhood, hey, I'm looking for this key, do you know where to find it? And any peer in this neighborhood of course has a better view on the network because it's the other peers in this neighborhood are nearer in terms of the metric that's set up this tree. It is UDP based and implemented in Rust. I'm currently porting it to the Tokyo Asynchronous IO Library and it's Deba Service. Basically it has two main commands, which is put where you put in the key and the value and get where you put in a key and you get out all the values that are stored under these keys. And to prevent hash collisions it also uses a string which is the application IDs. Basically you can put anything in there. I'm also implementing a new command here which is subscribe which means as soon as another peer publishes a new value in the network you will be notified. You can store about two kilobytes of values in the network. Usually this is limited by the maximum transfer unit so roughly 1,500 bytes. So you can only store some small information in there. The other part that I used to set up these peer-to-peer connections is the Viagard VPN. It's also UDP-based. The crypto is based on the noise protocol and currently the Viagard developers are working to get this into a mainline kernel and it looks quite good that it's becoming, it's getting into the kernel the next month. The keys are actually quite simple. With this command you can create a key. It's 256 bits here encoded as base 64. So that's a private key and you can easily generate your public key using that. And the way Viagard peer-to-peer comes into play is that it sits in between the Viagard and the internet and what it will do is it will use the S-tunt protocol to ask a server what your external IP is and then it will encrypt this external IP using lip sodium and publish it in the DHT and it will ask for all the other peers what their external IP is and set up a connection and then as soon as you found this out it will set up a connection from the external host to your local host Viagard connection. This is required so it will open a port on the local host device. This setup is required because Viagard peer-to-peer cannot talk directly to the host because then it will use a different IP and that would make a little bit of trouble. So yeah, this is what it looks like when you have multiple hosts it will allocate several ports on your local address. This is how you set it up, you create a configuration file where you tell what the device name is and for each peer that Viagard peer-to-peer should handle you put in the public key and then you basically just start the daemon. I'm also working on a network plug-in, network manager plug-in for Viagard and also for Viagard peer-to-peer so you can set up these connections quite easily. This is for GNOME, so currently I'm only developing this for GNOME and it has nice features like key fingerprint printing so it can easily compare public keys. The bulletin board is already ready. The packages are already ready. It's for Debian and Fedora, you can download them or if you wanna build it yourself you can use cargo so it's also implemented in Rust so you would need cargo and Viagard peer-to-peer is currently not, there are currently no packages for that but I will provide them in the next month I hope but you can also already install it using cargo but Rust nightly will be required because it uses these features a lot and this is only implemented in nightly. So if you're interested in the code, my GitHub name is Manuel S, create bug reports, create some merge requests, let me know what you think, if it works for you and I think that's already it. I was very fast so I don't know, are there any questions? I repeat. So yes, thanks. So the question is how is ETCD different from this bulletin board setup? Well, ETCD as far as I know it is only for your local network so it's only for the LAN and it's not really connected to the internet so I don't think it makes sense to connect it to the internet but the bulletin board is connected to the internet so anybody on the internet can store information in there and can receive information from this DHT. So the question was does the wire guard peer-to-peer link a public key to a public IP address and that's correct, yeah. Yes. Yes, so it solves this problem and it also solves the nut problem that you have to punch holes in your firewall to be able to receive UDP connections. If I understood correctly, how long does it take to store information on the DHT? Ah, how long does it stay on the DHT? I'm not 100% sure, I think I said something like 10 minutes so you will have to publish your information repeatedly every five minutes or whatever. There's also a special command for that, a special debuts command for that where you can say, okay, please, please, please publish this information for two hours or whatever and we'll repeatedly publish it. Okay, if that's it, thanks. Cheers.