Refactoring qaul.net in Rust (Internet independent mesh communication App)
CC Attribution 4.0 International:
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.
Jud, Mathias
et al.
Concepts, goals, implementations and the lessons learned from rewriting qaul.net decentralized messenger in rust. qaul.net is a Internet independent wifi mesh communication app with fully decentralized messaging, file sharing and voice chat. At the moment we are rewriting the entire application in rust, implementing our experience of 8 years off the grid peer2peer mesh communication, with a mobile first approach and a network agnostic routing protocoll wich can do synchronous as well as delay tolerant messaging. We are currently rewriting qaul.net 2.0 in rust with a new network agnostic routing protocol, identity based routing and delay tolerant messaging. The talk will show our learnings and the journey ahead of us at the alpha stage of the rewrite.
 Hello, and welcome everybody at the Open Infrastructure Orbit. Here you find all the different organizations that are involved with Open Infrastructure. So we're very happy to also have Matthias and Katarina from the Afra in Berlin here, who are working on Qualnet, and they're talking about how you can do that in Rust. So thanks a lot that you're here, and that's your applause. Yeah, Qualnet is an internet independent wireless mesh communication app. That means that we try to communicate between the end users devices directly in an interconnected way. So every device can communicate with all the other devices it is connected to, and even further if the other device is connected to other. This has several upsides. One of the upsides is we build our own infrastructure. We are not dependent on the internet service providers. We can also communicate if the internet services and mobile services are shut down, or if we don't want to go over them. The idea is to have a zero-config easily usable app. So multi-language with a nice user interface, this is the version 1.0. It's a cross-platform. It's easily installable on all the different platforms. We have written it for Linux, for Windows, for OS X, for Android, and for iPhone. And this all was written beautifully in C, and it was used or is used all around the world. It's a modular structure that goes even into the routers, and you can build a really modular networks that you can add and add and add new devices that extend. But there are some challenges. So we were using in the first version the so-called ad hoc or IBSS mode, which is dying and not usable in the devices anymore. We had over 400,000 lines of C code, which was hard to maintain, and people didn't like it too much how it was written. So even our user interface, which was an HTML5 user interface, got much too big and was really unstructured. So what is really important if we want to go kind of off the grid, if we want to be able to communicate with our devices, is that our devices nowadays are the mobile devices, and mobile devices don't have administrative rights. So to go to be mobile first, we need to go off of that. We cannot have administration rights. We need to get rid of the ad hoc mode because it's not supported anymore, and we need to do user space routing. All right. Can you hear me? Great. I can hear myself, so you can probably also hear me. So I've been working on Callnet for a few years now. I started with a GSOC project in 2016 doing new security stuff in the old code base, and since then we've been thinking about how to restructure the code in a way that makes it more extensible and maintainable. The old code base, you saw this diagram with a bunch of boxes. In theory, those existed, but in practice, over time, the project has existed since 2012. Modules started bleeding into each other, and it became really not fun to work with. And so for the rewrite, we started thinking about the layers that we might want to have. We have to replicate a lot of the work that is being done for us in dependencies such as OLSR in our own code and user space because we don't have the permissions to actually do these things with dependencies. And so coming from the bottom up, we had to think about network interfaces and the way that we interface our own code with whatever is there on a platform, which is the bottom two modules that you can see in the stack. Then we had to think about how to do actual routing. So if you have a network of multiple nodes, how do you get a packet from A to B that has to go via C or D in the middle? On top of that, there is a whole bunch of stuff that we'll get into. In this slide, it's only called the service API. And this has to do with the thought that we didn't want to just be one application anymore. Callnet is very useful, and it can be used to do a bunch of things. You can send messages. You can share files. You can do voice calls over it. But fundamentally, it's still just a single application that people install, and then they do stuff with, and they're locked into whatever we come up with for use cases. And so both for a new architectural design and also to let other people extend this network, we thought about the concept of services. A service being an application that runs on a distributed mesh network without any servers, without there being someone who hosts something that can self-replicate through the network and let other people decide what they want to do on this infrastructure that everyone is building as a community. And so that's the service API, which is the, I would say, core component of the new stuff that we've been writing and something that we'll get into in a little bit. On top of that, we actually write some services ourselves. So we still do provide a messaging service, a basically decentralized Twitter, which at the moment, or has so far had a 140 character limit, I guess we have to up that now because Twitter is cool, I guess. We also have file sharing, so you can announce a file to the network, and it sort of works like torrenting where you don't have to immediately send your file out. You can sort of announce it to the network and then people can get to you and get the file. And also, if other people along the way have parts of the files, they can get them from there instead. And voice calls, of course, which previously were called VoIP, but we'll get to that. We have a bit of a name conflict because we don't have any IP addresses anymore, so also something that we'll cover. And on top of that, we have a new web UI written in EmberJS, which makes it much more maintainable and just smaller to work with. But at the same time, because the lights are being weird, because we have this API that people can build stuff on, it is possible for other people or even for us to add other UIs as well. So if you wanted to build something that is specifically Android, you can do that. If you wanted to build something that's a text-based terminal application, you can do that. You just layer stuff on top. So to go down into the, I would say, interesting bit of the routing a little bit, this is sort of a slice, again, just lower. You have the service layer at the top, which we're messaging, file sharing, et cetera, and you have a service API. And then you have this routing core. It does a few things. It keeps a routing table, of course, which is something that we can't rely on a kernel for us to do, because we might need root for that, so we need to replicate that functionality in our own code. We also collect some link heuristics about package drop rate and TTL and a bunch of other stuff that can help us factor into what is a good connection, what is a bad connection. You might not want to send all of your packets just to the first person who can receive them if that person has a packet drop rate that's really high, and instead maybe take a longer route which is much more sustainable. It also has a persistence module built in, which is something that's important to us for reasons that we'll get into. But it basically just means that every packet that gets routed can also be stored for some amount of time. It doesn't have to be routed immediately, and just because something was delivered to a neighbor doesn't mean that that packet is lost. Underneath that, you have the network interfaces. Only two of those exist at the moment, or actually only two interfaces exist because we're still sort of early in development of this rewrite, but fundamentally there's nothing stopping you from hooking this up to Tor or your local wireless mesh network like Fryfunk or whatever. The two ones that we really care about on Android are Bluetooth and Wi-Fi Direct, which are direct replacements for the ad hoc mode that we lost, which has been deprecated. Maybe we can explain a bit further. The reasons we have so many possibilities to interconnect is that in the first version we use what every wireless community network is kind of using nowadays, so in ad hoc mode or Wi-Fi connections. As this is not there anymore, the ad hoc mode is a beautiful mode where every device is kind of equally connected with the same routes. You don't have a router and then followers. With other networking modes, we cannot replace it, but we can to try and go with as many connectivity possibilities that we have and use all the different possibilities or try to use all the different possibilities, which also kind of requests us to abstract this layer. What we have been working in the last two years was also to get a concept that allows us to abstract all those layers. So, to go back to the top, to go again top down, the service API is essentially the core library of call called libcall. It's written in Rust, like almost everything in the project. It provides you a few end points to interact with a system entirely in user space. It makes a few abstractions over platforms so that if you're on Android, if you're running on Android versus you're running on a Linux PC, there's no real difference how you have to handle these things. It sort of gives you a framework to build an application on top without having to worry about the exact implementation of your platform. It handles user authentication. It handles messages, so things that you send into the network. It handles contact data where people can make friends and assign trust levels and set nicknames and whatever. And also, it allows services, as I've mentioned, to interact with this library register themselves and say, hi, I'm an application running here, please talk to me. The way that this looks in actual code, this is the initialization of an application running on callnet. The thing that's missing there, which is the to do, is this is not initializing any network modules. So, you're creating a router and then you're not attaching anything to the router. So the router is going to get every packet and go, cool, I don't know what to do with that and save it, I guess. The router is, so you initialize everything from the bottom up, you initialize your network stack, then you initialize the router, then you initialize lib call, which is the call struct that is created there. You can create users with this API, you can register a service, which in my case here is DE Space Cookie My App. And then you can send a message and sending messages is, it has a few different modes that it can run in depending on if the recipient is a flood or a user or a group. So you can either address something to a single user or a group of users or in this case, a flood, which is basically spread it into the network and any node that is existent on this network can get this message. The beauty of this is that if you have an application that you want to provide on this network and you don't know how many other people have this because it's not standard, you can send out an announcement like this with a flood and say, hi, by the way, I am running here, can please people talk to me. And then you can find other instances of your application running on other people's devices that can then do whatever you want to do with it. On the receiving end, that's pretty simple as well. I have skipped all the initialization step, but you just have a listener function. There's also a poll and we're also working on making things asynchronously, but it's sort of a rolling working version where you can listen for this specific service ID and then every message that this node encounters on the network that is addressed to the service will get called with your code. And then you can do stuff with it. So that's the sort of top level application building process. Then we get to the routing. Again we have to do routing in user space and we are orienting ourselves with Batman, which is a routing protocol which uses pheromones and sort of a distance vector approach. We are writing it in Rust and I am bad with names so I called it Ratman. It also does a few other things such as delay tolerance, which is the DTN. What that means is that if you have two networks running in two physically distinct locations and you have people with bicycles, for example, crossing between location A and B, then if someone from A wants to talk to someone in B, the messages can be buffered on the person with a bike for the duration of that trip, which is why the routing core has a persistence module. They have to be stored somewhere. It has to survive device power-offs and potentially it has to stay there for weeks until either the message is surely delivered or it can be deleted because maybe a buffer has filled up or, you know, we are not going to fill up a device just completely. There is a maximum size of stuff that we are going to save but we are going to hold onto frames and packets as long as we possibly can. Some of the stuff that we have also been working on is simulating this. This was actually a Google summer of code project by someone who is now part of the core development team. Her job was to figure out a way to get a bunch of inputs and then create transform functions so that with relatively little work we can, you know, have a bunch of events and then replicate those events in slightly different circumstances throughout the network so that the actual load on the machine simulating this can be low whereas we can simulate a lot of network traffic. This has been working pretty well. The networks that we have so far only simulated were like three or five devices connected with each other but we don't really, right now the problem is that creating these networks is a bit of a manual task where you have to like hard code stuff that gets, you know, all the nodes and how they are connected and once we build a thing that can auto generate networks this testing will be able to go much further. It doesn't replace actual physical testing but this is a pretty good approach to test some assumptions in how we want to do routing and how certain mechanics are going to impact the link quality. Right. To be able to navigate it easily and to support as many platforms as possible we again decided to go with Web GUI which is an HTML5 GUI written in Ember.js and to implement the current paradigms of usability and to have much more responsiveness that we had before so different layouts and possibilities for different devices but all within one HTML5 layout which is then over a JSON API connected to our application and there it uses then our API to communicate. It is beautifully documented or should be at least we invest quite a lot of time and you can also communicate with us. We have a mailing list and we also have an IRC channel which are our main community and also developer communication interfaces and we also try to have a weekly voice chat that you can approach if you are interested in it. So that's our development team. At the moment if you are interested we would be really happy to enlarge it and to have you join us. Thank you so much for the talk. Katarina and Mathias and now we hand over to some questions. Hello, thank you for the talk. Can you say something about the scalability of your system? Not at the moment. We think that the scalability is going to be comparable to something that you can expect from a Batman network in Freifunk for example. The routing algorithm that we take is very similar to it. People announce themselves on the network and then you have a routing table just in user space instead of some kernel table. We don't know, we can't say for sure yet because we haven't built networks that are big enough yet but on the other side we're not making substantial changes to the algorithm that Batman uses to indicate that we might have scalability problems down the line. Next question. Hi, can you speak a bit about the choice of Rust and how that's been? The previous application was entirely written in C99 specifically. We were looking at what we wanted out of a language and one thing that we aim to do is run on certain routers that then don't provide a UI and that only become infrastructure nodes that know how to keep a routing table and how to process data. Because of this we were already looking at pretty low level languages. The question was do we rewrite it and see with a better architecture? Do we rewrite it in C++ or Rust was kind of new at the time when we made that decision. It was a language that I started having quite a lot of experience with because I used it in a lot of personal projects. At this point I'm also on a few Rust teams and I'm quite heavily involved in the community. The initial decision was made because it is a much more modern language than C++. It gives you a lot of the same benefits. It has other benefits. Of course it has some downsides but we thought that because of the benefits that the language gave us the downsides didn't seem so bad. Next question. Hi, thank you for the talk. It's very interesting. I've been looking for a few months now into decentralized things in the work-smash like this and I was just wondering how would you compare this to other projects like libp2p or GNUnet or other projects? I'm just wondering why again? In a way it's not again. So when we started the project in 2011 there was really nothing usable at all so I never wanted to start an other project of anything. Since then many projects tried also to go in this path. It's a very hard path as most projects that also try to be decentralized or are decentralized are just Internet overlay. So with integrating everything into one application from the infrastructure level, from the real network connectivity over the services up to the user interface and the whole configuration of the system. All this in one program is really painful and I haven't seen an application kind of be really succeeding in that. So one of the reasons we are rewriting that is that it was working really great back in 2012 until 2014 and we were still working okay on desktop systems but not on mobile systems anymore. And to have an application that is interconnected all those devices together is unique and is not there at the moment and we hope we will be succeeding. We are also in constant contact with other projects and also try to check what they are doing and most probably we can share some of the things because the real things at the bottom of it. So how do we really interconnect with it? Those problems are for I guess everyone the same. One thing to say there, I don't think we're really reinventing a lot of things. We're mostly looking at what other projects have learned over the last few years and then applying those findings in a different context and seeing what we can come up with. So definitely I would say without a lot of the other projects that have existed, for example, server approach to the delay tolerance and how to store messages and communicate changes in journals and advances in general routing like Batman and the derivatives that exist now, without those we would not be able to do what we do now. So it's very much a we're sort of succeeding or we're trying to be the successor of some of these ideas and see where they lead. Wonderful. Thank you so much again. Thanks for your very interesting questions also. And now my question is of course where can I find you during Congress if I want to contribute? I heard you have a workshop over there now, right? Right now we have a testing workshop where we are looking a bit more in the program where we are and can also find out a few things together. And then we are sitting a lot at the EFRA and there are some other testing workshops that I'm doing tomorrow and after tomorrow about decentralized networks about networking protocols. Okay, so I find that of course in the FA plan. So 6.30 you find them in the workshop area and if there's not more questions, I have a tiny thing for you. You can now choose whether you want some martin or some chocolate as a tiny gift of the open infrastructure orbit for you as a thank you. I haven't slept yet so I'll take the martin. Okay, perfect. You want some chocolate or? Yes, please. So thank you very much. Thank you for having the talk here.
 Hello, and welcome everybody at the Open Infrastructure Orbit.  Here you find all the different organizations that are involved with Open Infrastructure.  So we're very happy to also have Matthias and Katarina from the Afra in Berlin here,  who are working on Qualnet, and they're talking about how you can do that in Rust.  So thanks a lot that you're here, and that's your applause.  Yeah, Qualnet is an internet independent wireless mesh communication app.  That means that we try to communicate between the end users devices directly in an interconnected  way.  So every device can communicate with all the other devices it is connected to, and even  further if the other device is connected to other.  This has several upsides.  One of the upsides is we build our own infrastructure.  We are not dependent on the internet service providers.  We can also communicate if the internet services and mobile services are shut down, or if we  don't want to go over them.  The idea is to have a zero-config easily usable app.  So multi-language with a nice user interface, this is the version 1.0.  It's a cross-platform.  It's easily installable on all the different platforms.  We have written it for Linux, for Windows, for OS X, for Android, and for iPhone.  And this all was written beautifully in C, and it was used or is used all around the  world.  It's a modular structure that goes even into the routers, and you can build a really modular  networks that you can add and add and add new devices that extend.  But there are some challenges.  So we were using in the first version the so-called ad hoc or IBSS mode, which is dying and not  usable in the devices anymore.  We had over 400,000 lines of C code, which was hard to maintain, and people didn't like  it too much how it was written.  So even our user interface, which was an HTML5 user interface, got much too big and was really  unstructured.  So what is really important if we want to go kind of off the grid, if we want to be  able to communicate with our devices, is that our devices nowadays are the mobile devices,  and mobile devices don't have administrative rights.  So to go to be mobile first, we need to go off of that.  We cannot have administration rights.  We need to get rid of the ad hoc mode because it's not supported anymore, and we need to  do user space routing.  All right.  Can you hear me?  Great.  I can hear myself, so you can probably also hear me.  So I've been working on Callnet for a few years now.  I started with a GSOC project in 2016 doing new security stuff in the old code base, and  since then we've been thinking about how to restructure the code in a way that makes  it more extensible and maintainable.  The old code base, you saw this diagram with a bunch of boxes.  In theory, those existed, but in practice, over time, the project has existed since 2012.  Modules started bleeding into each other, and it became really not fun to work with.  And so for the rewrite, we started thinking about the layers that we might want to have.  We have to replicate a lot of the work that is being done for us in dependencies such  as OLSR in our own code and user space because we don't have the permissions to actually  do these things with dependencies.  And so coming from the bottom up, we had to think about network interfaces and the way  that we interface our own code with whatever is there on a platform, which is the bottom  two modules that you can see in the stack.  Then we had to think about how to do actual routing.  So if you have a network of multiple nodes, how do you get a packet from A to B that has  to go via C or D in the middle?  On top of that, there is a whole bunch of stuff that we'll get into.  In this slide, it's only called the service API.  And this has to do with the thought that we didn't want to just be one application anymore.  Callnet is very useful, and it can be used to do a bunch of things.  You can send messages.  You can share files.  You can do voice calls over it.  But fundamentally, it's still just a single application that people install, and then  they do stuff with, and they're locked into whatever we come up with for use cases.  And so both for a new architectural design and also to let other people extend this network,  we thought about the concept of services.  A service being an application that runs on a distributed mesh network without any servers,  without there being someone who hosts something that can self-replicate through the network  and let other people decide what they want to do on this infrastructure that everyone  is building as a community.  And so that's the service API, which is the, I would say, core component of the new stuff  that we've been writing and something that we'll get into in a little bit.  On top of that, we actually write some services ourselves.  So we still do provide a messaging service, a basically decentralized Twitter, which at  the moment, or has so far had a 140 character limit, I guess we have to up that now because  Twitter is cool, I guess.  We also have file sharing, so you can announce a file to the network, and it sort of works  like torrenting where you don't have to immediately send your file out.  You can sort of announce it to the network and then people can get to you and get the  file.  And also, if other people along the way have parts of the files, they can get them from  there instead.  And voice calls, of course, which previously were called VoIP, but we'll get to that.  We have a bit of a name conflict because we don't have any IP addresses anymore, so also  something that we'll cover.  And on top of that, we have a new web UI written in EmberJS, which makes it much more maintainable  and just smaller to work with.  But at the same time, because the lights are being weird, because we have this API that  people can build stuff on, it is possible for other people or even for us to add other  UIs as well.  So if you wanted to build something that is specifically Android, you can do that.  If you wanted to build something that's a text-based terminal application, you can do  that.  You just layer stuff on top.  So to go down into the, I would say, interesting bit of the routing a little bit, this is sort  of a slice, again, just lower.  You have the service layer at the top, which we're messaging, file sharing, et cetera,  and you have a service API.  And then you have this routing core.  It does a few things.  It keeps a routing table, of course, which is something that we can't rely on a kernel  for us to do, because we might need root for that, so we need to replicate that functionality  in our own code.  We also collect some link heuristics about package drop rate and TTL and a bunch of other  stuff that can help us factor into what is a good connection, what is a bad connection.  You might not want to send all of your packets just to the first person who can receive them  if that person has a packet drop rate that's really high, and instead maybe take a longer  route which is much more sustainable.  It also has a persistence module built in, which is something that's important to us  for reasons that we'll get into.  But it basically just means that every packet that gets routed can also be stored for some  amount of time.  It doesn't have to be routed immediately, and just because something was delivered to  a neighbor doesn't mean that that packet is lost.  Underneath that, you have the network interfaces.  Only two of those exist at the moment, or actually only two interfaces exist because  we're still sort of early in development of this rewrite, but fundamentally there's nothing  stopping you from hooking this up to Tor or your local wireless mesh network like Fryfunk  or whatever.  The two ones that we really care about on Android are Bluetooth and Wi-Fi Direct, which  are direct replacements for the ad hoc mode that we lost, which has been deprecated.  Maybe we can explain a bit further.  The reasons we have so many possibilities to interconnect is that in the first version  we use what every wireless community network is kind of using nowadays, so in ad hoc mode  or Wi-Fi connections.  As this is not there anymore, the ad hoc mode is a beautiful mode where every device is  kind of equally connected with the same routes.  You don't have a router and then followers.  With other networking modes, we cannot replace it, but we can to try and go with as many  connectivity possibilities that we have and use all the different possibilities or try  to use all the different possibilities, which also kind of requests us to abstract this  layer.  What we have been working in the last two years was also to get a concept that allows  us to abstract all those layers.  So, to go back to the top, to go again top down, the service API is essentially the core  library of call called libcall.  It's written in Rust, like almost everything in the project.  It provides you a few end points to interact with a system entirely in user space.  It makes a few abstractions over platforms so that if you're on Android, if you're running  on Android versus you're running on a Linux PC, there's no real difference how you have  to handle these things.  It sort of gives you a framework to build an application on top without having to worry  about the exact implementation of your platform.  It handles user authentication.  It handles messages, so things that you send into the network.  It handles contact data where people can make friends and assign trust levels and set nicknames  and whatever.  And also, it allows services, as I've mentioned, to interact with this library register themselves  and say, hi, I'm an application running here, please talk to me.  The way that this looks in actual code, this is the initialization of an application running  on callnet.  The thing that's missing there, which is the to do, is this is not initializing any network  modules.  So, you're creating a router and then you're not attaching anything to the router.  So the router is going to get every packet and go, cool, I don't know what to do with  that and save it, I guess.  The router is, so you initialize everything from the bottom up, you initialize your network  stack, then you initialize the router, then you initialize lib call, which is the call  struct that is created there.  You can create users with this API, you can register a service, which in my case here  is DE Space Cookie My App.  And then you can send a message and sending messages is, it has a few different modes that  it can run in depending on if the recipient is a flood or a user or a group.  So you can either address something to a single user or a group of users or in this case,  a flood, which is basically spread it into the network and any node that is existent  on this network can get this message.  The beauty of this is that if you have an application that you want to provide on this  network and you don't know how many other people have this because it's not standard,  you can send out an announcement like this with a flood and say, hi, by the way, I am  running here, can please people talk to me.  And then you can find other instances of your application running on other people's devices  that can then do whatever you want to do with it.  On the receiving end, that's pretty simple as well.  I have skipped all the initialization step, but you just have a listener function.  There's also a poll and we're also working on making things asynchronously, but it's  sort of a rolling working version where you can listen for this specific service ID and  then every message that this node encounters on the network that is addressed to the service  will get called with your code.  And then you can do stuff with it.  So that's the sort of top level application building process.  Then we get to the routing.  Again we have to do routing in user space and we are orienting ourselves with Batman,  which is a routing protocol which uses pheromones and sort of a distance vector approach.  We are writing it in Rust and I am bad with names so I called it Ratman.  It also does a few other things such as delay tolerance, which is the DTN.  What that means is that if you have two networks running in two physically distinct locations  and you have people with bicycles, for example, crossing between location A and B, then if  someone from A wants to talk to someone in B, the messages can be buffered on the person  with a bike for the duration of that trip, which is why the routing core has a persistence  module.  They have to be stored somewhere.  It has to survive device power-offs and potentially it has to stay there for weeks until either  the message is surely delivered or it can be deleted because maybe a buffer has filled  up or, you know, we are not going to fill up a device just completely.  There is a maximum size of stuff that we are going to save but we are going to hold onto  frames and packets as long as we possibly can.  Some of the stuff that we have also been working on is simulating this.  This was actually a Google summer of code project by someone who is now part of the core development  team.  Her job was to figure out a way to get a bunch of inputs and then create transform functions  so that with relatively little work we can, you know, have a bunch of events and then  replicate those events in slightly different circumstances throughout the network so that  the actual load on the machine simulating this can be low whereas we can simulate a lot  of network traffic.  This has been working pretty well.  The networks that we have so far only simulated were like three or five devices connected  with each other but we don't really, right now the problem is that creating these networks  is a bit of a manual task where you have to like hard code stuff that gets, you know,  all the nodes and how they are connected and once we build a thing that can auto generate  networks this testing will be able to go much further.  It doesn't replace actual physical testing but this is a pretty good approach to test  some assumptions in how we want to do routing and how certain mechanics are going to impact  the link quality.  Right.  To be able to navigate it easily and to support as many platforms as possible we again decided  to go with Web GUI which is an HTML5 GUI written in Ember.js and to implement the current  paradigms of usability and to have much more responsiveness that we had before so different  layouts and possibilities for different devices but all within one HTML5 layout which is then  over a JSON API connected to our application and there it uses then our API to communicate.  It is beautifully documented or should be at least we invest quite a lot of time and  you can also communicate with us.  We have a mailing list and we also have an IRC channel which are our main community and  also developer communication interfaces and we also try to have a weekly voice chat that  you can approach if you are interested in it.  So that's our development team.  At the moment if you are interested we would be really happy to enlarge it and to have you  join us.  Thank you so much for the talk.  Katarina and Mathias and now we hand over to some questions.  Hello, thank you for the talk.  Can you say something about the scalability of your system?  Not at the moment.  We think that the scalability is going to be comparable to something that you can expect  from a Batman network in Freifunk for example.  The routing algorithm that we take is very similar to it.  People announce themselves on the network and then you have a routing table just in  user space instead of some kernel table.  We don't know, we can't say for sure yet because we haven't built networks that are  big enough yet but on the other side we're not making substantial changes to the algorithm  that Batman uses to indicate that we might have scalability problems down the line.  Next question.  Hi, can you speak a bit about the choice of Rust and how that's been?  The previous application was entirely written in C99 specifically.  We were looking at what we wanted out of a language and one thing that we aim to do is  run on certain routers that then don't provide a UI and that only become infrastructure nodes  that know how to keep a routing table and how to process data.  Because of this we were already looking at pretty low level languages.  The question was do we rewrite it and see with a better architecture?  Do we rewrite it in C++ or Rust was kind of new at the time when we made that decision.  It was a language that I started having quite a lot of experience with because I used it  in a lot of personal projects.  At this point I'm also on a few Rust teams and I'm quite heavily involved in the community.  The initial decision was made because it is a much more modern language than C++.  It gives you a lot of the same benefits.  It has other benefits.  Of course it has some downsides but we thought that because of the benefits that the language  gave us the downsides didn't seem so bad.  Next question.  Hi, thank you for the talk.  It's very interesting.  I've been looking for a few months now into decentralized things in the work-smash like  this and I was just wondering how would you compare this to other projects like libp2p  or GNUnet or other projects?  I'm just wondering why again?  In a way it's not again.  So when we started the project in 2011 there was really nothing usable at all so I never  wanted to start an other project of anything.  Since then many projects tried also to go in this path.  It's a very hard path as most projects that also try to be decentralized or are decentralized  are just Internet overlay.  So with integrating everything into one application from the infrastructure level, from the real  network connectivity over the services up to the user interface and the whole configuration  of the system.  All this in one program is really painful and I haven't seen an application kind of  be really succeeding in that.  So one of the reasons we are rewriting that is that it was working really great back in  2012 until 2014 and we were still working okay on desktop systems but not on mobile systems  anymore.  And to have an application that is interconnected all those devices together is unique and is  not there at the moment and we hope we will be succeeding.  We are also in constant contact with other projects and also try to check what they are  doing and most probably we can share some of the things because the real things at the  bottom of it.  So how do we really interconnect with it?  Those problems are for I guess everyone the same.  One thing to say there, I don't think we're really reinventing a lot of things.  We're mostly looking at what other projects have learned over the last few years and then  applying those findings in a different context and seeing what we can come up with.  So definitely I would say without a lot of the other projects that have existed, for  example, server approach to the delay tolerance and how to store messages and communicate  changes in journals and advances in general routing like Batman and the derivatives that  exist now, without those we would not be able to do what we do now.  So it's very much a we're sort of succeeding or we're trying to be the successor of some  of these ideas and see where they lead.  Wonderful.  Thank you so much again.  Thanks for your very interesting questions also.  And now my question is of course where can I find you during Congress if I want to contribute?  I heard you have a workshop over there now, right?  Right now we have a testing workshop where we are looking a bit more in the program where  we are and can also find out a few things together.  And then we are sitting a lot at the EFRA and there are some other testing workshops  that I'm doing tomorrow and after tomorrow about decentralized networks about networking  protocols.  Okay, so I find that of course in the FA plan.  So 6.30 you find them in the workshop area and if there's not more questions, I have  a tiny thing for you.  You can now choose whether you want some martin or some chocolate as a tiny gift of the open  infrastructure orbit for you as a thank you.  I haven't slept yet so I'll take the martin.  Okay, perfect.  You want some chocolate or?  Yes, please.  So thank you very much.  Thank you for having the talk here.
36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_0_1211.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_1212_2759.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_2760_3647.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_3648_3839.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_3840_10523.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_10524_10595.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_10596_10703.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_10704_11279.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_11280_12143.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_12144_14867.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_14868_16859.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_16860_26423.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_26424_26531.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_26532_26675.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_26676_28187.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_28188_28811.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_28812_29327.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_29328_30311.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_30312_30527.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_30528_30587.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_30588_32963.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_32964_33971.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_33972_35735.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_35736_36071.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_36072_36167.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_36168_36227.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_36228_36551.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_36552_38735.png 36c3-oio-143-eng-Refactoring_qaulnet_in_Rust_Internet_independent_mesh_communication_App_hd_38736_38803.png