GNUnet: A network protocol stack for building secure, distributed, and privacy-preserving applications
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Schanzenbach, Martin
In this talk we will give a brief introduction into the GNUnet peer-to-peer framework, its architecture and existing applications. This includes details on the p2p overlay, double-ratchet messaging channels (CADET) the GNU Name System (GNS) and a selection of other applications and features. We present the current status of the project, the roadmap as well as ways to participate and use GNUnet.
 Okay, hi, my name is Martin. I'm one of the co-maintenors of GNUNAT 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 the 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 we 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 doesn't 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. And this is hardly ever addressed in projects that try to decentralize applications, be that identity services or be that 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. 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 GNUNAID project actually starts. So GNUNAID 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 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, like, 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 of the record protocol that basically does a key exchange with a public key, trust on first use, maybe has some rekeying protocol as well built in, but something like that. So at least that a passive observer of the network cannot see what's 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 the passive attacker. The next thing what 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. DHT is 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 bit torrent 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, 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 more cowbell and well, less like ICANN. And once you have such a stack, now you can start building property centralized 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 GNUNET? Well, in GNUNET, for the over-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 GNUNET is called R5N. 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 cadmilia-style routing and is particularly good in restricted route environments. So you only have very few connections. In GNUNET, the protocol that is used to actually communicate with a peer that is multiple hops away from you is called CADET. Now, CADET does is it uses the DHT to discover a path to a remote peer. This is done by simply retrieving, 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 GNUNET 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 GNUNET is the GNU name system. We currently have a project with an LNET 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. 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. Passively just collecting all of the queries and responses doesn't really get you anywhere. There are also some planned and existing applications on top of GNUNET. 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 GNUNET. One of them is the SecureShare project, which is not directly part of GNUNET at the moment and is still in development. SecureShare, by the way, is a social network, I think. 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's actually set 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. That's 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. Okay, so 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. Your software needs to run on something. 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 part 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 a 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 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 use Ethernet, maybe I can use Ethernet, but if I can't use Ethernet, then maybe I need to use like bare Wi-Fi or Bluetooth meshes or 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 GNUNET 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 plugins 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 plugins you have enabled. You will still be using the same stack. So somebody who lives, who has a very restricted network might need to use a Bluetooth mesh network. Somebody who just wants to use the network as 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 GNUNET stack if you look at it from the ISO OC 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 GNUNET 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 GNUNET, 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 CADDET. 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 GNUNET 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, etc. And I guess today you would call this a microservice architecture and put them in containers. But the GNUNET protocol, the GNUNET 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, oh, well, just one thing, GNUNET 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. Which could be a Unix domain socket or a TCP socket. Doesn't really matter. And you can drop in, 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 GNUnet works. The truth is, there are a lot of applications and services currently implemented in GNUnet. And if you go to our website and look at architecture, you will get this picture. Which is the GNUnet spaghetti monster. But it's actually, if you now know that the core framework of GNUnet 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 CADD 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. And top if you can see the secure. 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 GNUnet 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 reimplement 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. 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 GNU 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 be continued 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 Summab 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. That was my final slide. Thank you. And if you have any questions. Thanks. So I love the project, especially the Taler. 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 decide who owns the name? And if not, when I come to resolve a 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 hyperlocal root in GNS. So we're going to basically ship a root zone for you. That is basically a list of top-double domains that map against the public key. And if the 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. Do 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 the GNS. So you can look that up. It's on our webpage. And 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 like 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, GNUNET.io. You can look it up. Somebody compiled GNUNET, which is C, into WebAssembly using M-scripten and wrote a transport plug-in 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. No. 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 inside as possible so people who come late can find a seat.
 Okay, hi, my name is Martin.  I'm one of the co-maintenors of GNUNAT 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 the 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 we 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 doesn't 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. And this is hardly ever  addressed in projects that try to decentralize applications, be that identity services or be  that 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. 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 GNUNAID project actually starts. So GNUNAID 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 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, like, 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 of the record  protocol that basically does a key exchange with a public key, trust on first use, maybe has some  rekeying protocol as well built in, but something like that. So at least that a passive observer of  the network cannot see what's 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 the passive attacker.  The next thing what 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. DHT is 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 bit torrent 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, 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 more cowbell and  well, less like ICANN. And once you have such a stack, now you can start building property  centralized 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 GNUNET? Well, in GNUNET, for the over-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  GNUNET is called R5N. 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 cadmilia-style  routing and is particularly good in restricted route environments. So you only have very few  connections. In GNUNET, the protocol that is used to actually communicate with a peer that is  multiple hops away from you is called CADET. Now, CADET does is it uses the DHT to discover a path  to a remote peer. This is done by simply retrieving, 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 GNUNET 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 GNUNET is the GNU name system. We  currently have a project with an LNET 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. 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. Passively just collecting all of the  queries and responses doesn't really get you anywhere. There are also some planned and existing  applications on top of GNUNET. 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 GNUNET. One of them is the SecureShare project, which is not directly part  of GNUNET at the moment and is still in development. SecureShare, by the way, is a social network,  I think. 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's actually set 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. That's  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.  Okay, so 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.  Your software needs to run on something. 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  part 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  a 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 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 use Ethernet,  maybe I can use Ethernet, but if I can't use Ethernet, then maybe I need to use like  bare Wi-Fi or Bluetooth meshes or 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 GNUNET 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 plugins 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 plugins  you have enabled. You will still be using the same stack. So somebody who lives, who has a very  restricted network might need to use a Bluetooth mesh network. Somebody who just wants to use the  network as 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 GNUNET stack if you look at it  from the ISO OC 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 GNUNET 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 GNUNET, 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 CADDET.  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 GNUNET 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, etc. And I  guess today you would call this a microservice architecture and put them in containers. But  the GNUNET protocol, the GNUNET 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, oh, well, just one thing, GNUNET 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. Which could be a Unix domain socket or a TCP socket.  Doesn't really matter. And you can drop in, 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 GNUnet works. The truth is, there are a lot of applications and services currently  implemented in GNUnet. And if you go to our website and look at architecture, you will get this picture.  Which is the GNUnet spaghetti monster. But it's actually, if you now know that the core framework  of GNUnet 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 CADD 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. And top if you can see the secure. 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 GNUnet 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 reimplement 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. 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 GNU 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 be continued 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 Summab 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. That was my final slide. Thank you. And if you have any questions.  Thanks. So I love the project, especially the Taler. 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 decide who owns the name? And if not, when I come to resolve  a 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 hyperlocal root in GNS. So we're going to basically ship a root  zone for you. That is basically a list of top-double domains that map against the public key.  And if the 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.  Do 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 the GNS. So you can look that up. It's on  our webpage. And 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 like  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, GNUNET.io. You can look it up.  Somebody compiled GNUNET, which is C, into WebAssembly using M-scripten and wrote a transport  plug-in 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.  No. 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 inside as possible so people who come late can find a seat.
dip_gnunet_0_131.png dip_gnunet_132_875.png dip_gnunet_876_1211.png dip_gnunet_1212_2603.png dip_gnunet_2604_3671.png dip_gnunet_3672_4727.png dip_gnunet_4728_5351.png dip_gnunet_5352_6155.png dip_gnunet_6156_6875.png dip_gnunet_6876_8435.png dip_gnunet_8436_9419.png dip_gnunet_9420_9863.png dip_gnunet_9864_11159.png dip_gnunet_11160_12215.png dip_gnunet_12216_14291.png dip_gnunet_14292_14351.png dip_gnunet_14352_14519.png dip_gnunet_14520_17015.png dip_gnunet_17016_17219.png dip_gnunet_17220_18911.png dip_gnunet_18912_19535.png dip_gnunet_19536_22379.png dip_gnunet_22380_23771.png dip_gnunet_23772_24779.png dip_gnunet_24780_26063.png dip_gnunet_26064_27587.png dip_gnunet_27588_30227.png dip_gnunet_30228_35219.png dip_gnunet_35220_35279.png dip_gnunet_35280_35327.png dip_gnunet_35328_35423.png dip_gnunet_35424_35471.png dip_gnunet_35472_35531.png dip_gnunet_35532_35615.png dip_gnunet_35616_35736.png