Okay, hi, my name is Martin, I'm one of the co-maintainers of GNUnet, and today I will

talk a bit about the project. I think if you have been here in the morning as well, I think it ties in quite nicely with other projects that we have heard about today when it comes to decentralization of the Internet. So I think I'm preaching to the choir, so the Internet is under attack, but I want

to give you a kind of a different perspective from what we have heard today in this aspect. If we look at the Internet, how it works today, it's not just centralized services and applications that we need to decentralize. The Internet is a technology stack that goes deep up to the, from applications down

to the physical layer. So we have the Ethernet, we have IP, BGP, so this is the OSI, ISO stack, so you have a physical layer, then you have a data link layer, which, if you have a cable, it's Ethernet. Then you have a network layer, which is IP and BGP, which is usually used for routing. Then you have a transport layer, where there are transport layer protocols.

Then you usually also have a naming system, which now is DNS, for most Internet applications, and on top of that now you have, at the moment, very centralized and large applications and services. Now, as we heard before today, and as you probably also heard in the news, those centralized

services are very easy to subvert. So programs like PRISM and any other lawful interception methods can basically directly collect data from you by simply going to those services and taking it. And in order to avoid that, of course, it makes sense to think about how can those

applications be decentralized. But that's only half of the story, because you're forgetting about the rest of the stack. So a lot of times when you hear about the blockchains or blockchain-based applications, it's completely forgotten that if you attack the network on a deeper level,

then your blockchain is not really worth much, or at least the security guarantees it gives you. Simply because the ISPs and the routing infrastructure, you have no control over that, and it also does not provide inherently any security on its metadata, for example. And as we have heard before, also in the news, people are killed based on metadata, right?

And this is hardly ever addressed in projects that try to decentralize applications, be that identity services or be that, I don't know, social network services. But you always need to keep that in mind, because everything is built on top of the Internet infrastructure.

And then, of course, you have the naming system, which is a completely different story, and DNS is something that does not provide you any kind of security, but it's also arguably managed and governed by corrupt organizations, which we have seen with the .org case just recently. So there's absolutely no aspect in this whole stack that actually provides us with any security guarantees, and we cannot actually use it to build decentralized applications

on top. It doesn't make any sense. You don't have a proper foundation to do that. And that is where the vision of the Gnunet project actually starts. So Gnunet wants to basically build a full stack that provides you with the individual layers of the ISO OSI stack so that decentralized applications can be built in a

meaningful way. And we need metadata protection, we need encryption, and we need decentralization. We need a stack that supports those three features, and specifically metadata protection. So if we were to have a clean slate and just think about, okay, so what would we like

to have in this stack, or how should it look like? Then I'm going to, for now, exclude the physical layer, because that's a bit tricky. But let's think about Ethernet. So the Ethernet is usually used to have a protocol that connects two nodes directly. So if you want to decentralize a system, you can think about your direct neighbors.

If you're in a decentralized network, you are going to communicate with your direct neighbors. What kind of protocol would you want for that? And you would probably want some kind of trust-on-first-use, off-the-record protocol that basically does a key exchange with a public key.

Trust-on-first-use maybe has some re-keying protocol as well built in, but something like that. So at least that a passive observer of the network cannot see what is happening. Or what is part of the communication. And more importantly, that encryption layer protects the metadata of the next layer.

So if you now need a routing protocol or a transport protocol, that metadata is implicitly protected against a passive attacker. The next thing that you need in a decentralized network is routing. Because usually this is what IP and BGP does for you. But you cannot rely on this infrastructure anymore because that is managed by ISPs.

DHTs implicitly have built-in routing mechanisms. Now usually you think of DHT as key-value stores, but they do provide routing. So you can use it to discover routes across the network. And this has worked since BitTorrent and this works now with IPFS. So it's a good method. Now once you are able to, you have your hop-by-hop encryption

and you have a way to discover paths across your PHP network, and if you now want to address a remote peer or communicate with it, you still need end-to-end encryption. And state-of-the-art at that point would be some kind of ratchet encryption protocol. You might even want something like onion routing at that point.

Naming, well, you want something that is less susceptible to more cowbell and less like ICANN. And once you have such a stack, now you can start building proper decentralized applications. Of course you can build them before and then after that address the stack,

but it makes sense to keep in mind that without the stack, your decentralized application is not really giving you any value. So how does this relate to GNU-Net? Well, in GNU-Net, over the record layer, so the protocol we speak with other direct neighbors,

it's just called core. To me, it's quite a boring protocol because the only thing it does is just connect to some kind of a machine that you have a connection to, do a key exchange, and then talk.

The distributed hash table in GNU-Net is called R5n, and there is a publication I've put at the end of the slides, so you can download them and look at it. It's a special DHT that is combining randomized routing with Kademlya-style routing and is particularly good in restricted route environments, so you only have very few connections.

In GNU-Net, the protocol that is used to actually communicate with a peer that is multiple hops away from you is called CADET. Now, CADET uses the DHT to discover a path to a remote peer,

this is done by simply doing a GET request against a peer ID, and the other peer does a PUT request against its own peer ID, and that way you can basically find the path from one peer to the other peer. CADET at the moment in GNU-Net does implement a ratchet for encryption,

but I think it does not at the moment implement some kind of onion routing across the path. Probably the most stable component at the moment in GNU-Net is the GNU name system, we currently have a project with an L-Net as well to write basically an independent standard on how the wire format of the GNU name system actually looks like.

The GNU name system essentially, if you know how DNS works in DNS, you have usually a recursive DNS server that iteratively queries other DNS servers until it has found an actual result. The GNU name system does not use any servers,

instead all of the record information in the DNS system is stored in the distributed hash table. In addition to that, we use a little bit of a fancy elliptic cryptography as part of the keys and values, what is stored in the DHT, in order to realize what is called a private information retrieval scheme,

and that means that if you are a passive attacker on the network or if you're just observing queries and responses in DNS, then you cannot tell what is queried and you also cannot really read the answers unless you know what is queried.

So passively just collecting all of the queries and responses doesn't really get you anywhere. And there are also some planned and existing applications on top of GNU-Net. Wait, I have slides on DNS, but they are only in there because, so you can look at them how it works. Next slide.

There are already some planned and existing applications on top of GNU-Net. One of them is the SecuShare project, which is not directly part, I think, of GNU-Net at the moment and is still in development. Then there's also, SecuShare, by the way, is a social network, I think, so it's kind of a replacement for something like Facebook.

Then there's Gnutala. Gnutala is a privacy-friendly payment system, and something, a project that I'm also involved with is ReclaimID. ReclaimID is, we have heard it, I think, three times now today, what you would call a self-sovereign identity system.

What it does a bit differently, I guess, is that the only thing ReclaimID tries to achieve is to decentralize the OpenID Connect service. I think I heard today that whenever you do authentication, that you can basically simply use OpenID Connect,

and then the authentication will happen for you. That is not actually true, because OpenID Connect, they have actually nothing to do with authentication. It actually says that in the spec. The only thing OpenID Connect helps you to do is to authorize another party to access your data somewhere.

That's the only thing the protocol actually does. It doesn't have anything to do with authentication, and that is what ReclaimID does. Users can basically use a standardized way to share personal information with other websites, but it does not include any kind of authentication.

ReclaimID basically is just a combination of OpenID Connect with GNS. Now, one thing I left out until now, and that is probably the most important thing, if you want to use the stack, obviously at some point you need to bring it to the real world, right?

Your software needs to run on something, and the most straightforward way, if you build any peer-to-peer system, is to just say, I'm going to open a TCP socket to the other peers, and then you're done, which makes sense, as long as this works. As long as your peer-to-peer protocol port is not blocked, as long as the network is not blocked in any way,

for example by deep package inspection, then this is fine. But what if your network is more restricted? At that point, you could think, well, I'm just going to run my protocol over an application layer protocol. I could just say, well, then I'm going to run over HTTPS because who's going to block HTTPS?

So that's another option. Until somebody maybe tries to, I don't know, probe your HTTPS servers that are not really HTTPS servers. So, the third option might be to go lower in the stack, and you say, well, if I can't use Ethernet, maybe I can use Ethernet, but if I can't use Ethernet,

then maybe I need to use bare Wi-Fi or Bluetooth meshes or, I don't know, satellites, so that I have some kind of physical mechanism that I can run my protocols on that are not under the control of some kind of infrastructure provider. The answer in NewNet and how to solve this is yes.

We're just going to use all of them. So, basically, we have a separate layer that exposes a transport API to our stack, but the actual connectivity that a node has is, you can think of it like a plug-in infrastructure. So you can basically enable or disable plug-ins

such as a TCP plug-in, an HTTP plug-in, a Wi-Fi, Bluetooth plug-in, quick plug-in. You can think of it. And it doesn't really matter what plug-ins you have enabled. You will still be using the same stack. So, somebody who has a very restricted network might need to use a Bluetooth mesh network.

Somebody who just wants to use the network for something productive and is in a very liberal network might be able to use a TCP node just as well. And it will work. But the important thing is that this is abstracted from the actual application. So, it will just work.

Now, this is the core NewNet stack if you look at it from the ISOOC layer perspective. This is something that you can just use. And one thing I would like to note at that point is that whenever somebody looks at NewNet and look at the documentation, then obviously everything in that stack is documented.

So the documentation is huge. It looks very complex. But if you think about it, if you want to open a socket somewhere, you're not looking up how Ethernet works. Nobody does that. You're not looking up how your Wi-Fi actually does the connection and the signaling works. So, in NewNet, if you need a name system, you just have to look at GNS.

And if you only need a transport layer protocol, you can only look at CADET. And then you're done. And the APIs for the individual layers are actually quite lean. Now, we can also look at this graph a bit differently. If you actually would start a NewNet node, you would basically get a number of processes

that are started. And each process is essentially a layer in our core stack. So you would get a process for the transport layer. You would get a process for the name system, for the resolver. You would get a process for your transports, et cetera. And I guess today you would call this a microservice architecture and put them in containers. But the NewNet protocol, the NewNet project

is over 10 years old. So back then, those names didn't exist. But this is how it looks like. The nice thing that you can do, and that is currently also happening, because I told you that we're currently standardizing the GNS name system. And what somebody else is doing, part of the project, is he says,

well, just one thing, NewNet is written in C. And usually we get something like, oh, it's written in C. I don't want to write C. But you don't really have to because what you can do is you can just write a service in another language. So currently somebody writes a Go implementation of GNS. And you don't have to implement the whole stack down to make this work

because each layer in GNS, in the user space, communicates with the lower and upper layers using sockets. It could be a Unix domain socket or a TCP socket. It doesn't really matter. And you can drop and replace any service that you want. And this is also true, for example, for the Go service. So you can just listen to the proper sockets

and use the proper sockets, and then it will just work. So extension is not really tied to the technology used in the framework. Actually, we are currently rewriting the transport stack because it has some architectural deficits currently. For example, the plugins that we use, TCP, HTTP,

if one of those plugins currently crashes, it takes the transport service with it because it's a dynamic library, and we want to change that so that every actual transport plugin is its own process. So if it crashes, we don't really care, and we can still provide the transport layer.

And at this point, I should probably say that I have not been quite honest with you. So this is a very simplistic view over how NUNET works. The truth is there are a lot of applications and services currently implemented in NUNET. And if you go to our website and look at architecture,

you will get this picture, which is the NUNET spaghetti monster. But it's actually, if you now know that the core, the core framework of NUNET consists of the services that I've just shown you. You can easily find them again here. So in the middle, you have a core, if you can read it.

And in the above, you have CADET, and there's a DHT somewhere. But it's just already a huge application ecosystem. One thing that you can see here is on the left side, you can see that there's an FS application, which is essentially file sharing. Think IPFS.

There's a voting application. On the top right, you can see conversation, which is a voice over IP service. On top, you can see the secure share. So personally, I think we should probably remove this picture and replace it with something more simplistic. On the other hand, this is more truth to what is actually currently implemented. So we probably need to think about this.

Okay, so what's the current state and where are we going? I would say that NUNET currently is not something that you can just use and build a productive application with it because just in December, we had to basically break compatibility and re-implement some of the cryptography.

And obviously, that basically broke the whole network, and now it has to rebuild itself. And we are planning to do that at least once again this year because there's just still a lot of things to do and a lot of things to get right, especially in the lower levels, especially in transport layer, especially in the core layers to get this right.

On the other hand, the upper layers, they look a lot better. So we're currently standardizing the GNS protocol, at which point we probably don't want to change anything regarding that anymore. That's why there's also currently an alternative implementation. Right, and beyond that, we have obviously larger goals.

One of the largest ones is probably offer maybe something like a .org replacement authority using the new name system. Obviously, there needs to be some kind of an organization that actually manages this, which is probably then not going to be us. And also, we will continue to implement additional transports.

I think the ability to use different transports and to implement them is actually quite interesting. So if somebody's interested in writing a transport, then feel free to contact us. We're also going to participate in this year's Google Summer of Code. I don't know yet what kind of projects we're going to offer, but there's probably going to be from very simple projects to very difficult tasks,

a few options. So if you're interested in that, you can just contact us. Yeah, that was my final slide. Thank you, and if you have any questions.

Thanks. I love the project, especially the talent. I really like the payment system. I have a question about the name system, GNS. Does each name owned by one entity, if yes, how do you make sure and who decides who owns the name, and if not, when I come to resolve the name,

how do I know which of the values to take? So the idea that it's initially supposed to work is, I don't know if you heard about hyper-local root in DNS. So we're going to basically ship a root zone for you. That's basically a list of top-level domains that map against the public key, and if a user wants to change that,

he can do that because it's just a configuration file, but that's basically the concept. So you have a local root zone file that you can modify, and that basically assures that most of the time you will have the same names. Thanks for the talk. Every technology stack has certain affordances.

The problems with the left-hand stack are really obvious now. Is anyone thinking ahead to what the unintended consequences of the right-hand side might be? Are you doing things like consequence scanning? Have you got people who are maybe not technologists

working with you to think about the political implications? The political implications of the right-hand stack. You mean within our project, if we're thinking about that? I think there are people that think about this. I'm more the techie. I don't really care about it. I just want it to work. But yeah, if you write on the mailing list,

I'm sure there will be a few people that have comments on that, but I'm not the right person probably. Sorry, can you tell us a bit on the performances of NUNET? The performance of NUNET? There are actual numbers on that. We have last year done a study, for example, on the performance of the DHT and with it the GNS. You can look that up.

It's on our web page. Obviously, it's not as good as the current Internet, right? But it's enough to do your regular work and to do things with it.

Hi, hello. Is there any plan to have it run on top of WebSocket and implementing everything inside the browser, for example? There is a project that is working, not working on it, nunet.io. You can look it up. Somebody compiled NUNET, which is C,

into WebAssembly using Emscripten and wrote a transport plugin for WebSocket so that it just runs in the browser. So that works. Are there any further questions? If you want to leave, please leave silently.

I guess that's it. Then thank you very much for giving this talk, Martin. As this room is known to get full every year, we ask you that during the break you try to move as much insight as possible

so people who come late can find a seat.