 with Ben, Ben works, develops in Rust and JavaScript in made safe, which actually the main supporter of safe, which he will talk about more, but more about Ben in his technical side, Ben develops application API for developers basically, but he's also a community person. He writes, facilitates community events, and he cares about human aspect of open source software. Ready? Yeah. All right, let's welcome Ben talking about the safe. Thank you. So for our audience in the live stream, you can go to timelyroll.com slash safe-d-internet. I have feedback loop here. Am I the only one? It's weird, right? Let's see. Is that better? Is it okay? You can go there and you can look at the slides while I also do them. So let's get right started. So I'm Ben. Hi. I'm a software developer, educator, architect. I write about software development as well. I do freelance open source hashtag, all the hashtags. If you want to learn more about me, you can go to Unicorn.org or follow me on Twitter. But we're not here to talk about me. We're here to talk about the impending doom of civil society and what we can do to fight the horsemen, or in a more positive way, it's time to freaking save the internet. Okay. Which microphone? This one is really muffled. Okay. Sure. One, two. Is that better? All right. Great. Was it okay? I should do the introduction again. I think it's okay, right? You got the gist of it. Okay. So because we have a big audience here and I'm not sure we're all on the same page, let me start by painting a little bit of a picture first. Imagine a society so well-developed that all of the world's knowledge is at your fingertips. With a device smaller than your hand that fits into your pocket, you can connect to anyone and everyone on the globe instantaneously. And you can share messages with them. You can share images, videos. Heck, you can even live stream your current protest to the world. And infrastructure so immense and all-compassing that not only citizens, governments, and institutions are using it, even like other infrastructures based on it for its communication, like the power grid or cars. Yet it can be taken down by a toaster. Now imagine that everything you do in this network is tracked. Everything that you look at, everything that you share with someone else is recorded by governments and corporations alike. And not only in the online world that is inside this sphere you see here, using the same device that you have in your pocket, view are tracked even offline in the meat world. And the little privacy that within the system you have left, you actually have to trade in voluntarily in order to gain access to the system. In order to share this picture with your friends and your family, you have to upload it into that entire infrastructure. Even though this infrastructure is incredibly bad at keeping that safe and secure. Like seriously bad. I really recommend this page. I'm going to tweet the link to the slides afterwards. This is a link to information is beautiful, which is just having like these bubbles of the latest data breaches. And it goes all the way back to 1994. And you should click on it. It's just terrifying. And all of this information that is available in there allows us to paint a really accurate and terribly good picture of you and your social connections. Of you and everyone in your field of vision. Everyone you talk to. And we do know that. Now imagine that this kind of mass surveillance system and tracking system falls into the hand and under the control of a demagogue, a bigot or fascist. Now I don't have to tell anyone in this room that what I just described is not a tech dystopia or for a sci-fi movie or some sort. This is the internet today. All you looked at just right now is public knowledge. These are headlines of the last three to five years. This has been happening all over the place and all the time. But that is not the internet that I signed up for. That's not the internet that I that we fought for back when we started all of this. This is not what we wanted. So what are we going to do about it? Well, first we need to take a serious look. And that when I mean a really serious look into why is that even a thing? Why are all of these problems even possible? And when I say a serious look, I mean that we really need to find the root problems of our infrastructure. Let's take the DDoS as an example. It's very easy. You all remember the headlines that it was fridges and webcams that caused this. And of course, there's a big cry that vendors should secure their devices more. And that's correct. They should. But by focusing on the conversation only on that, we distract ourselves from the actual problem that our infrastructure is so weak to a degree that an attacker with enough power could still do this, even if all of these devices are secured, because they could just buy other devices, more devices as they please. Similarly, talking about the mass surveillance apparatus, we focus and talk about, righteously so, that more things should be encrypted, that more in transit communication especially should be encrypted. And shout out to Let's Encrypt. They have done an amazing job there with getting so much more of the Internet under HTTPS. But that only helps so much if the NSA is still on that server in their opinion lawfully and righteously so. Because it doesn't really matter if we can transfer the information to the server securely if it's then not secure. And similarly, even with the end-to-end encryption systems that we have been deploying, we still rely on these relay servers in between. So if the NSA is on those, and I'm sorry to say, but I assume they are from everything we know, then they still have a vast amount of information, which is every message, even though it's encrypted, going from there to your other party. And they know that you are the one talking to the journalist. So the real problem that we need to address here, and it's uncomfortable, and we don't like to talk about it too much, is that we have in the Internet, in the public Internet, a central server paradigm. And we need to move away from it quick. And to some degree, we know this. We know that networks that are more decentralized are more resilient, more stable. And I guess to most people in this room, it's obvious that a full peer-to-peer network is the most resilient way that you can find any type of service. And we know this. We have been actually deploying a lot of these services on the Internet in various degrees of decentralization already, like email, as a good example, as a federated system. While it's possible to deed us and technically take down gmail.com, email as a service is impossible to take down. And that's good. Yet the big issue isn't really on the bottom part there, but on as well, it's very good at this. The bigger issue is the one on the top. We still have a lot of services that rely on central service somewhere. And this one, for example, the service that I want is not a forum. I want that specific forum with that kind of data. And we address those with these systems. And that's a problem, because let me put it another way. Imagine the following conversation between me and my friend. I'm like, hey, dude, this amazing book that I read the other day, you should definitely read it. It's like, oh, yeah, your recommendations are really great. What book is it? And I respond, oh, you can find it in the Harvard Library on the second floor, last shelf, on the top shelf, sevenths to the right. Natural conversation I have every day. Nobody thinks of addressing something like this except us. We are in the information technology and we address things by their location. The example I just made is exactly that. When I go to a resource on our forum, for example, the way I address is I have this Harvard Library which points to a physical location, an IP in this particular case. And then the second part of this URL points to where I find this resource in this particular location. At least that's the paradigm that we're using. If you go to gmail.com, the second part behind that is not talking about a physical or more or less physical location on a specific server anymore that's just virtualized. But it would still apply very much that you would go to the Harvard Library and then give them the path and they look it up some other means and they give it to you. You still need to go to the Harvard Library to get that. But how do we in the actual world address things? Not by that because my friend would have to go to the Harvard Library to get this book. And there's probably many other versions of this book out there that they can use instead. So instead what I'm telling them is it has this author, it has this title, and maybe I have an ISBN for them. And they can go to any library or any bookstore and ask them, hey, do you have this book? And when I say this book in our real world, we don't actually mean the physical object either. When we talk about a book, we mean it's content. And we address it already in our natural language that way because they don't care if they have the physical identical copy that I had before or when I read it because we can assume that the other one is equally good. So this is the general concept or the idea of content addressing. And this is already existing in a very simple way. The ISBN is a content addressing system with a channel registry. But we also do have this and we moved on from this URL concept to the URI in the Internet as well. The easiest form of content, and we have computers with massive amounts of calculation capacity, one of the easiest ways for us to address content is through their check sums. And we have a variety of check sums we can use. This one is, for example, the Shaw one sum for the content test. And we have been even addressing things in the wider Internet this way. You might have seen those called magnet links. This is actually a valid magnet link. If you put it in, you should get a content test somehow from BitTorrent. BitTorrent has actually deployed this in 2006. And whenever you have these magnet links and you click on them today in most piracy websites, you would still be able to find this content without ever talking about a physical location per se. But what is this? This is nothing else than a really big number in a number space that we can also write in decimals. I'm writing it out like this because it's really big. This is Shaw one. That isn't even 265 or something. But it's just a really big number. You can't argue that everything is a very big number. But if you read the first thing, a lot of people would assume it's a string. It's just a hax representation of a really big number. That's correct. And you can also write it down in base too, of course. But how does then in a fully distributed BitTorrent network without trackers, I'm not going to go into what those were or still exist, how can we actually find something? Well, technically we need an index of all the content that we have or that is known. And we need to map where I can find this. At some point I still need to find a physical location where it's actually stored. But just looking at this really big number, that is going to be a really big index. And asking every participant in the network to hold this really big index is going to be incredibly hard to even just keep up to date. So what BitTorrent did back in 2006 when they introduced this new system is something called distributed hash tables. And in the particular version that we're going to talk about it, it's Kademlia routing. So the idea is that while you can identify any type of content with a number, that is just the hash of it. So it's always unique to that particular content. Whenever a node joins the network, they also get a random number in the same number space. And then what you do is you calculate the distance between any node and any particular piece of content by just using very simple mathematical operations. In the system, because it's really simple for a computer to do, we're using XOR, which is why it's often also referred to as the XOR namespace. So you can just XOR to binary numbers. If this is too complicated, just think of it in terms of subtraction. You have a node and you have a particular content. And by using this, you can define a specific distance between any particular node in the network to any other node as well as between any node and any type of content. No, any content, not any type of content. And that allows us to do something very interestingly because through that distance we can compare how close in a virtual sense one object is to another. One object is to a node or two nodes are to one another without any reference to physical location or something similar. So when we think about this, you can think of the entire namespace as a big group of people that you can just number through. And when you join it, what you can do is you just look at the network and you compare the distance between you and all of the other nodes in the network and can divide it in areas. And what you want to do is you want to have a connection into each one of these areas. And you want to have connections to everybody who's very close to you. Now, if you want to look up a file, you have the Shasam and you can calculate the distance between you and that particular file. And you can also very simply calculate the distance between all of the connections that you're holding because you know the IDs of the other participants on that side to you. Which means that you know you don't have this file or you don't have the responsibility to know where to find this file, but you know who is closest from all the people that you know, that one. Now, they do the same thing. They don't have the file themselves. They check and they figure out, oh, of the participants that I hold very close, they're doing the same that we do by holding everybody who's very close to them at our connection. They figure out, yeah, but there's someone else who's closer. And they know that they are closer. And they do the same thing. They figure out, oh, wait, I have this file. I am closest to this. And they respond, oh, yeah, sure. I know where to find this file. Please go there to that connection that they already have open to this relaying node. And they just translate that, give that information back to me. With that system, we can very easily define responsibility in a peer to peer network of nodes who are constantly in and out. Because as soon as that node goes away, someone else is closer and is supposed to hold that information. Especially if we define this responsibility not as one, but four or five nodes have to have this information and are responsible for it. It's very easy to have a rather resilient system where if one of the node goes out, someone else again becomes closer and they just transfer the information to the other close party. At the same time, even though it is a huge number of nodes and depending on how many divisions you do and how many open connections you want to have between eight and 64, depending on the system itself, you build a binary tree to every piece of content that has very few virtual hops. It takes only very few actual connections that are already open to hop to that specific content even though it's a massive, a massively huge namespace that we're talking about. This system, this in particular, is a forward routing because one thing that you saw that it did is rather than that relaying node telling me that the other node has that information, the other node passed it to the relaying node and they passed it to me. And that has another interesting property in which that is obfuscation of these relaying parties. So imagine that you have the hash of a file and the NSA figured out which node is responsible for that file and they want to track whoever else tries to access this file like let's say a Wikipedia terrorism article. Now they are able to find this node in a physical space, they infiltrate them and they are on this relaying node. All they can see is that there's requests from the relaying node coming in for that file. Connections that are already open. And even to the relaying node is unclear who holds that file. It could be that this particular node still has another node that is closer and they asked them. As well as the relaying node doesn't know that I'm the one asking, I could also just be a relaying node that takes that information and forwards it again. Thus, especially because it goes over four to five hops usually, obfuscates very well who's accessing what. Neither end of the party knows them at all. Now, with this being deployed in 2006, why isn't everything on the decentralized system yet? Well, it turns out there's another really, another thing that central service do very well and that is transitioning of state, specifically finding consensus about what is the current state. For quite a while, we have, like, if you want to know what the law is and the king is the law, all you need to do is ask the king. It's a very easy ruling system. But in a decentralized system, especially if we say we want to have nodes that are equal among another, we can't have a king. So how do we find out what is the current state of things? Or how do you find consensus without a king? Well, effectively, it's a question of, in every democracy, how do you actually vote? And as anybody who has ever been into anarchist or left-ish movement, unanimous voting is a thing that always comes up. And we also have implemented unanimous voting through Paxes and Raft as some examples, where essentially a group of nodes, whenever a decision needs to be taken, is talking among another until they agreed what the new state is. Depending on how you implement this, though, that could mean that every node you add doubles the amount of messages that are required. And if everybody knows a unanimous voting system, as soon as one of them is not actually working very well or doesn't want to respond in this way, finding a decision can be quite hard and can be blocked for long periods of time. So very often we only implement Paxes and Raft in terms to elect a new leader in a master minion system, for example, like post-crucical clusters do where you have a master. And if the master falls away, they use a Raft-style system to figure out who's the next master. But doing this for every transaction would actually take too long and would be just too much traffic. Another very famous example of distributed voting system is actually Bitcoin. If you think about it in a more sociological sense, what Bitcoin does is a majority voting of the global state. It requires 51% of the nodes to agree on the next state. And they use a predefined process that everybody agreed to do in order to make this happen, which is specifically the longest chain idea, which is followed on the idea that you reduce the number of potential electables in the first place by making really hard puzzles. So the possibility that you have two forking chains or many forking chains going on for a long time is already quite unlikely. And if you have two, you have a majority vote, and you can elect the next state. But everybody who has ever done a massive amount of voting system or just votes in Europe knows that general elections take time. Getting the majority to agree on something is not that easy. Even in Bitcoin, if you think about it, yes, we have this 10-minute time frame that it takes to make this next block. But until there's no other competing chain anymore, until that particular point is reached, you don't actually have reached consensus that this is the new state. Because there's still a competing one that the majority could still agree on. And that actually happened in December last year, where unintentionally an update was made to the Bitcoin client that made half of, like a big part of the older system incompatible unintentionally. So they created transactions that weren't compatible. And the new version just continuously made a new fork for about six hours until they released a fix for that. And six hours of transactions actually rolled back because they were continuously running. So this system hasn't actually found consensus for six hours. But even the 10-minute time window, if I upload my file and I want to share it with my mom, I'm not going to wait 10 minutes to be confirmed that the picture is actually online. So that is not really an option either. But you remember routing? You remember that I specifically talked about that it allows us to assign responsibility rather than just files. And I mentioned that before. Let's assume that I'm responsible here for this particular file. Responsible in this case could, for example, mean that it requires me to agree that we do a change to this file. For example, by on the basis that you're sending this file with the update with the signature that I can confirm you own this file by checking the signatures. I already have connections to everyone else who's also responsible for this particular file. So when this request comes in, I can do a majority vote among these other close allies to me. And we can agree really quickly with a majority vote on already existing connections, whether that is the new state or not. And within a peer-to-peer system, I have the incentive to always do what is expected from me to be happening, because if I misbehave, my direct counterpart, my next neighbor is to be like, you seem to be broken. I'm going to disconnect from you. And you're out of the system. So it's in your interest, even though you don't know the file, even if you don't know what it's about, to confirm these updates as long as they apply to the protocol. And we can use this mechanism to model all types of processes and status changes and transactions. It doesn't only have to be, this file has this particular signature, because we define a close group of nodes who are responsible. And by being part of the network and wanting to stay in the network, you are required to take any of those, we call them personas, specific roles within a process that is assigned to you, purely on the fact that you have a specific distance at this moment in time, that your N numbers close to a specific type of thing happening within this, in this fear at this very moment. So for example, in this case, I can't really see the language. The first part confirms that when I want to upload a file to the network, that I have the credits to do so, that my client is allowed to do this. And only by having the confirmed step, the next step happens, and there's completely different nodes responsible to figure out how and where to store that file. And they need to agree on that. And that means we can actually have various types of data types that we store in this network. One thing we have inside the network itself is an authentication mechanism. So we have tokens in the network that are, that you need to know the address for, and then you have a pin to decrypt it on the client side, and they confirm, on the node, and they confirm, yes, this is an authentication token that you decrypted, then they send it back to my client, and I have a local secret key that I can, that allows me to actually decrypt this decrypted thing, and then I can act on this network. And they can confirm that, well, yeah, this key exists, this is there, and this is mine through that system. Or immutable data, which is another data type that we have in the safe network, which is defined as the address must be the hash sum of the chunk that you're trying to store. It's a very simple process, but it's a process nonetheless, that every node, when you try to store that information, is going to check. And if that doesn't match, they're going to refuse. And we're also currently working on a new version of mutable data. We had a range of different data types, but we're currently condensing this down to a key value pair style system, so like a hash table, if you will, that you can even share specific permissions to. So you could give an app or another person the possibility to add entries to that list, but not to override or delete. And all you need is this close group of nodes that agree that this is the process they have to do with the majority voting. Another thing that you can think of in this space as well is you could use it for a currency. As mentioned before, you can model any type of data type, so why not create something like a file coin or save coin, how we call it. And the process, or one process that you could imagine around this, is that I can only transfer the ownership of this particular coin if I am the owner at this point. So I have to send a signed request, and the nodes confirm or deny this request based on the fact that this coin is owned by me or not. And if it is, then they change the ownership to someone else. And the interesting part about this is that if you do it that way, that's it. By having this consensus about this, you assume afterwards that the consensus has been reached properly in the past, so you don't need to keep a record of it. So where I got that coin from before, when I transferred to you, you don't know. And after I transferred it to you, and you transferred to someone else, nobody knows that you got it from me either. So in many ways you could model a system that is much closer to cash than it would be to most of the blockchain type of currencies today, which are transactional based. And that's an interesting property, because we're not talking about this enough, and I'm not going to go into that here, but that money forgets is incredibly important for an economy. That you're not able to track down that what I just paid my pizza with, five rows back, has actually been used to pay it for drugs, is very important in our legal system. So I mentioned the Safe Network a couple of times now, and this is, this is, so what is it, what is it? The Safe Network is a decentralized privacy-first open-source data storage and communications network that provides a secure, efficient, and no-cost infrastructure for app development. So in its highest level view, what it does, it's a peer-to-peer storage mechanism, using exactly the storage mechanism that I just described through the exonames space and XOR writing, which means that with that we can also easily build data retention right into the network, because whenever a note goes down, another note is responsible now to have this piece of data, and the other notes that are also close to them then transfer the information over. In our system we currently have everything stored eight times. It's probably, like there's different mathematical models, but it's probably okay to have four or five times, and even in a net split, you're most likely still going to get it. But when we say privacy-first we mean that, and that among other things means unless the application specifically says so, everything is encrypted by default before it leaves your computer. Either through your private key, because it's your data, or a public key, because you're giving it to someone else, or through a shared key, because while you're sharing it with someone. But we even go one step further, when we say everything, we mean everything. Even the stuff that you consider public, we encrypt through a mechanism in which we split the file into smaller chunks and then encrypt each individual chunk with the previous chunks. We create smaller pieces of data which are complete garbage. And these pieces of data are then stored in the network and all you need is a data map that tells you, look at all of these things, put them in this order, and then you can translate it back to the actual file that you want to have. And that is an important thing that, just because you say that a piece of data is generally public, does not mean that you trust the person who's holding it. In a peer-to-peer system where any random note could be assigned to hold your private pictures, you don't want every creep to see your private photos. And by doing this mechanism, all they store is a really random, weird chunk of data. That has another nice benefit. For one side, it means that me as the person storing that data, I don't know what it is, which gives me plausible deniability, even if it's something that might be legally problematic in my jurisdiction, but not necessarily where they're stored in, the people who store it from. And equally so, by obfuscating everything, you make it much harder to figure out which is the sensitive information. If you only encrypt the things that are important, then it's really easy to figure out which parts I should decrypt, because it's the only thing that are interesting. But if everything is garbage that is on that system, then I don't even know which one might have been the one with the sensitive information. It allows us another interesting property right in there. By being able to, by doing this process and having this self-encryption process designed in this particular way, we can make sure that for the same file, you always end up with the same chunks. And as we store them as immutable data, meaning their hash is the address in our network, if I uploaded the file before, let's say it's a movie and you upload the same movie, we only store it in the network once, not twice, three times, or as many times as needed. Which is a, it's a very different mechanism than what you think about even for entering encryption. If I share the same video right now with my friend and my family, it's actually sent over the wire twice, and it's encrypted twice. While in this case, it would be self- encrypted on the network, and it would only store, it would only encrypt this data map and send that over, which is a much smaller amount of data. I've mentioned before as well, so I'm not going to go into that too deep, that with the system, we can provide self authentication and registration. Meaning you can create accounts with the system without any third party. You don't need maidsafe, you don't need me, you don't need to know anyone, you just connect to the network and you can create a new account. And the network and the structure inside of it holds all of that information. And more over, we're building this in the intention to create a fully, allow for an infrastructure that is built fully on decentralized and distributed apps and services. So by thinking of it that way, like every node has their role and if a node goes down, if you deduce any of the participants of the system and they go down, and now the one takes over, the service would always be available. And because there's no better word, I'm usually using Decentributed as a combination of both. This has been in the works for quite a while, we've been working on this for over 10 years now, and there's a bunch of things in there, this is just the main features. Each one of them is actually worth a 45-minute talk. And I was only able to quickly talk about the exonamespace, the group consensus, and we touched the savecoin for a moment there. I want to take another minute on the savecoin because I think when you ask the question of why didn't we upgrade the internet yet, you very quickly come to the conclusion of the tragedy of the commons, that it's not in anyone's particular incentive to do so, everybody would benefit equally from it, which means that if I as a company have DDoS protections, I actually have a competitive benefit over my counterpart that doesn't. So it's actually more interesting to me to not have this upgrade in the system, because it makes me better. And I think one key mistake we did back then is that we didn't really think about that too much, what incentivizes people to upgrade, and we have been struggling with the IPv6 update forever, I think for a similar reason. So what we intend to do in the system is that when you provide storage or any type of resource for that matter to the network, you are rewarded for that through a currency, and in order to store information on the network or use resources like computation later, you need to pay this currency. And that means that in the mid and the long-term run, we create an economy that allows us, when we have new features, they allow for new revenue. It's interesting for the participants of the network to upgrade because it means they can use more of the resources not only get used, but they can also earn better through that. So what can you actually do with us? We have been building a few example applications, and I'm rushing through them a little bit. So the most obvious one, XR namespace is still not very readable, so yeah, there's a public naming system. And again, this is, doesn't require a central registry, we can just say DNS is the hash of the name that you're looking at, and whoever claims this piece of data first, they own that domain. Done. And in there, we expect a key value of service-oriented design. So www means there's probably a website behind this, or public key means this is a public key of that particular DNS name. So this allows you, for example, to publish websites on the system, which obviously also means in order to access the system because it's not HTTP, and you need to do this multi-step routing system in order to be able to access it, then you need a browser. And the particular browser we have has another nice little feature on top of that, which is a JavaScript API that the website can use in order to connect, ask the user if they can connect to the network on your behalf. So for example, they can read the recent list of comments on a blog, but you can also use that very same system to build fully interactive web apps as well. So for example, we've built a markdown editor that allows you to store nodes fully encrypted, transparently encrypted, through the given access of the user on the web for you, or the example I took before as well, you can use that to ask the user if you can, in case they want to comment on a blog, you ask them for the permission to store data in their name on the system. So whenever you write a comment, that also means that you own it because you were the one putting into the system. And you give a link basically to that specific comment, to the list of comments and everybody can read it, but nobody can ever change it other than you. Nobody can ever delete it other than you because you own this piece of data. And we have a, this is an interesting change also in the perspective of what it means to own data, because it's not a physical location anymore and you don't have to write in terms of services, an app can store stuff on my behalf. And I am the owner. The app is just interacting with my data. And decorum is another decentralized forum idea, which does exactly that, where you say, we have third conversations, but every post is owned by you. And all you do is, when you wrote the post, when the software wrote the post, it tells a central authority where to find this post now. But it's yours, nobody could ever have changed it, the system guarantees that. Another app we have, and that's simple but a very interesting case, because of the inherent system that we have in there, we have a public key infrastructure built into the system. And we are exposing that through the API, meaning that you can very easily build an email service, let's call it app rather, that just knows that when it finds email in your DNS, that there's a public key and a public identity where you can write stuff to, anybody can write stuff to. And then you use that public key to encrypt that email so they can be sure that only the person that put that key into that DNS entry can actually read it. And when you do that, you can use your private key to sign this message as well. So the email client when it shows up and reads through all of these things, it can confirm that the email is actually from you. And that is transparent to the user, no exchanging of keys, nothing of that needed. And mostly transparent to the apps as well. And last but not least, we currently have a safe launcher which is basically entry point and control center to this system. So I hear you somewhere between, shut up and take my money and are we there yet? I have to say unfortunately, hold your horses. Similarly as the Python, the Simpsons work there, it's longer and bumpier than you might expect. The system looks fine in an architecture point, but it's not that easy to implement a reliable peer-to-peer system. But we do have an alpha running for about a year now, early last year, and we just released the latest version of Vaults this Thursday. Vaults are the full nodes that do all of the personas and all of this activity and make sure that connections drop, they find other ones and stuff. And we're currently working on the mutable data as mentioned before, but another thing that's very important to us is that we can do this on mobile as well. While we have to admit that mobile Vaults are probably a little further ahead, we do want to have at least mobile clients. So the email does actually work for mobile as well. So with that said, one of the main reasons I'm here is I want to ask you to join the resistance. If it's because you want to hack on Rust code, all our base code is in Rust, or you're just curious about how this could work, if you want to do the bindings of the library that we're doing for other languages, we're currently doing the Node.js version, but we want Python, we want C++, it's Rust, so it's rather easy way to do it. Or if you just want to run your own Vaults, join the network. Of course you have to prove that you have the resources, which currently means six megabytes upload, so not everybody gets connected, but you can go to that URL and download the code and join the network. Or if you're more interested about the aspects of what does it actually mean, if we had this kind of system for building applications, building privacy first applications where I as a developer never even know your data, have never seen it, and don't need to, I'm currently writing an e-book about this topic, which is also going into IPFS and some other systems like Ethereum Swarm and compares to what they are doing, and asking the question of how do we, how should we build decentralized apps in the future. And yeah, you can connect me, you can talk to me right after, but also go to the website and find me a screen record ban on Twitter. This is a pixelated stormtrooper because every slide to actually have a stormtrooper. Here's a bunch of more links to the project itself and the ways you can join. And with that, I'd like to say thank you. All right, thank you so much. We've got just a few minutes for question and answers. First of all, the doors at the top are closed, so if you want to leave, please get away from the other door and please keep it quiet for the question and answer. Questions, so I see one person. And also, please keep your hands up if you've got questions. There's one over there. I'll get there. So that was first, I'll come here, right? That was first. Yes. So, hi Ben. That sounds awesome. The bottom line from my point of view is getting rid of location-based addressing and centralized networks towards something decentralized and more resilient. It sounds really great. But we as engineers, we know that there's also a trade-off when switching from one paradigm to another. So from your point of view, what is the major trade-off we are facing here and not only in terms of technical, but also in terms of social or legal stuff? Well, so I think this is what I'm trying to also go into into the book. From an engineering perspective, it's a change in paradigm which means we need to get, not get rid, but we need to let loose of the idea of what we had before. We always thought of this one CPU, of this one entity that has access to all of that information and that builds the social graph. I think we have already in the last couple of years seen more decentralized and distributed databases, but it's a vast change of how you perceive data and how you interact with the data that I think that is the biggest challenge for most of the things. There's a few things that we honestly haven't figured out yet. How can you model a social graph in this without everyone telling everyone who they like and having this public knowledge? But I think it's about time that we start asking these questions in a more privacy manner, because yeah, the server system is broken. We know this and it's not working. It's able to solve this technically, but not in a socialist, social democracy way that we can actually ethically, and there was a good conversation about this yesterday, be okay with how this is solved. I think this is the major change is how we approach handling of information in this. We have, like if you could keep answers short, that would be great. And also if you could repeat the question. Hi, I was just wondering if you are aware or you're in connection with WebTorrent browser project, which is a web browser specifically for, well, websites of WebTorrent and the LISC project. What's the second? The LISC project, which is where you paid through the well, a blockchain exchange to run applications. I'm aware of the WebTorrent. I didn't quite understand the second one, but... LISC, L-Y-S-K. There's a lot of, in the blockchain sphere especially, there's a lot of interesting projects on this. Thank you. I'm going to look that one up. There's another question right behind you. Thank you for the talk. Can you pixie-boot an operating system ESO of the safe network? You can, yes. Because that would be really cool. All the ESOs there. All the ESOs. Totally up for that. So right now we're running an alpha, but one of the first things I want to do, once we have a more left stable network is basically clone Wikipedia so that everybody can access it without anyone else knowing. Yeah, definitely. All of the operating systems. There's a question down here. Thanks for the talk indeed. There are more similar projects to make decentralized encrypted peer-to-peer network. Is there any option of federating with different projects? I think there is to a degree like IPLD, the IPFS linked data protocol even contains in its specification the idea that you would tell me where this hash is. There's, I think in the exonamespace we're still very early in the stages of how we actually do this. Aside from us, Ethereum's swarm is the only implementation actually existing trying to achieve that. And addressing works differently in those. So I'm not sure if addressing across networks is compatible all the time and we're not stable enough to even know if what we're currently doing is something worth keeping around. So I do think it's possible. I do think it's an interesting idea and but I don't think there have been attempts made yet. The next question, and if you could keep it short so we could answer more. Thanks. Yeah, I was wondering. Is the company behind this project? How is this? Oh, sorry. The company behind the project. How is this structured and can we expect features which are for paying users or? Okay, so the company structure is that we have a company called Matesafe that was founded by one person 10 years ago which had this idea to get rid of the server. And we've been developing stuff since but the idea of the network is that from these safe coins that are created I think it's 10% is supposed to be designated for the core development. We haven't figured out yet even how the currency works but the idea is that this currency then through the usage of the network would be given to the developers to continue working on it and Matesafe considers itself one of the companies that as it has many of the core developers currently on payroll would get a lot of these coins but hopefully won't be the only one. So the idea is from the from the get go that other developers once we have this in place are pushed to incentivize to also join this and become independent and it's not controlled by one company. It's too massive and important offer project to have this under control of one potentially problematic legal thing which is the other thing it's currently Matesafe limited in Scotland and Brexit and their Snooper Charter are kind of worrying us. So one idea is to have more entities involved. Thank you. The last question and then the last question. Okay. Hi. Given that there's so many companies nowadays who are storing literally terabytes or not terabytes petabytes data bytes of data is it your expectation that under this type of architecture that all of that data would be spread out over the internet that my house would somehow have 150 terabytes and my neighbor would have 150 terabytes and somehow that would have all of our photos and videos everywhere or their data warehouses in your architecture somewhere that I'm not seeing. No data warehousing is definitely in the architecture like you can run a vault on any AWS instance for example and considering that depending on how much resources are in the network it might actually be more interesting for someone like AWS or other big data centers to instead of renting the machine to you renting it by running a vault to that network and so they would get that money. This is almost theoretical of course but the idea is that when we say peer to peer it could be any size of storage in the end we have some minimum requirements to make sure that the network is stable and up time is okay but until until that point you can just run it on AWS or any other server and use all of that storage up. Okay thank you very much if you have more questions or we want to discuss stuff I'm going to go over there. Thank you.