It's time to SAFE the Internet Introducing
Kampmann, Benjamin
Servers are hacked. Passwords leaked. Personal information stolen. DNSDDoS'ed. Cloud services are mining and exploiting everything they can gettheir hands on. The core problem; centralised server infrastructure. In this talk, we will introduce you to SAFE, a decentralised privacy-firstopen source data storage and communications network enabling anyone to developdecentralised, secure, privacy-concealing apps. There is no more denying it; the server-centric infrastructure has failed us:personal information mined, private photos are stolen, passwords leaked,entire infrastructures DDoS'ed – en masse. We are doomed! But are we? Actually, as engineers, we know better: a decentralised networkhas the highest reliability. With distributed computing resources that canscale up and down on-demand and aren't bound by physical limitations. Andwe've been building these systems, clusters of databases across data centres,successfully for years – in our server backends. On the public internet,however, we are still using a single point of failure infrastructures: DNS,single endpoint IPs. But issues with the existing Internet infrastructure don't stop there:government firewalls can block web services for entire countries, our plaintext communication is heavily surveilled, and companies mine our most personaland private data for their profit. To protect one's privacy, people have toresort to obfuscation protocols like Tor – with significant drawbacks likeslower connectivity and worsened user experience. But even then the data isstill stored, exploited and stolen from the centralised "cloud providers". It is time that we bring those concepts of distributed computing,decentralised storage and communication out of the data centres into the realmof the wider internet. Combine that with an obfuscating peer-2-peer routingmechanism, a transparent, self-encrypting public-key-infrastructure andautomatic data retention, and you have covered the basics of what the opensource SAFE Network software provides. In this talk, we explore the SAFE Network, the underlying DHT-based routing,and the XOR-namespace and how they are used to successfully concealsconnectivity and even metadata itself by making it infeasible for an attackerto calculate the path data will travel. We will discover what it means tobuild privacy-first Apps on a network where all data is sandboxed per tenantand distributed over multiple machines. Furthermore, by taking a look at theAPIs SAFE provides and going through some example apps, we will learn how tostructure and build fully distributed, privacy-first Apps on SAFE today. Finally, we will take a look into the future of SAFE, what apps are indevelopment and how developers could alternatively be paid through the built-in currency based on the app usage rather than the exploitation of personaldata. SAFE, Secure Access for Everyone.
 with Ben, Ben works, develops in Rust and JavaScript in main, made safe, which actually the main supporter of safe, which he will talk about more, but more about Ben, and his technical side, Ben develops application API for developers, basically, but he's also a community person. He writes, he 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 time.com. I have feedback loop here. 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 glue.nicorn.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 help you fight the horsemen. Or in a more positive way, it's time to freaking save the internet. Did you use the other microphone? Yeah. Okay. Which microphone? I'm going to give you this microphone instead because this one is really muffled. Okay, sure. One, two. Is that better? All right. Great. Was it okay? I should have do the introduction again. I think it's okay, right? You got the gist of it. So because we have a big audience here and we're not, 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 infrastructure is 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, you 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 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 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 a 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 look 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. 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 massive islands apparatus, we focus and talk about, rightfully 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. And 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 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're 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, for example, is 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, seventh to the right. Natural conversation I have every day. We think 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 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. 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 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 SHA-1 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. So what is this? 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 SHA-1. 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 the hax representation of a really big number. That's correct. And you can also write it down in base 2, 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 the particular version that we're going to talk about it is cadmium 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 this 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 Chasam 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 nodes goes out, someone else again becomes closer and they just transfer the information to the other close party. At the same time, even though this is a huge number of nodes and depending on how many divisions you do and how many open connections you want to have between 8 and 64, depending on the system itself, you can, 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 Cadamlia 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. That has another interesting property in which that is obfuscation of these relaying parties. 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 is, who 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 node. All they can see is that there's requests from the relaying node coming in for that file, connections that are already open. 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 ask 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 is 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 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, 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 the 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 RAF as some examples where essentially a group of nodes whenever a decision needs to be taken is talking among another until they agreed with the new status. 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 RAF 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 RAF 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. We just 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. Making 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 blog. 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. 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, 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 for me to be happening. Because if I misbehave, my direct counterpart, my next neighbor, is 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 though 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, and your N numbers close to a specific type of thing happening within this sphere 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 you need to know the address for. And then you have a pin to decrypted 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 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. We're 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 a safe 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 transfer it to you, you don't know. And after I transferred it to you and you transferred it 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 paid for drugs is very important in our legal system. So I mentioned the Safe Network a couple of times now and 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 base and XR 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 it, 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 is needed. Which is 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 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 Matesafe, 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. The network and the structure inside of it holds all of that information. Moreover, 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. By thinking of it that way, every node has their role and if a node goes down, if you DDoS any of the participants of the system and they go down, another one takes over. The service would always be available. 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. I was only able to quickly talk about the exonames space, the group consensus and we touched the save coin for a moment there. I want to take another minute on the save coin 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. 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. It's actually more interesting to me to not have this upgrade in the system because it makes me better. 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. 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 awarded for that through a currency. In order to store information on the network or use resources like computation later, you need to pay this currency. That means that in the mid and the long term one, 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. What can you actually do with this? We've been building a few example applications and I'm rushing through them a little bit. The most obvious one, XOR namespace is still not very readable, so yeah, there's a public naming system. Again, this doesn't require a central registry. We can just say DNS is the hash of the name that you're looking at. Whoever claims this piece of data first, they own that domain. Done. 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. 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. 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. 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. 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. We have 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 the 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 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 a 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 that 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 what they are doing, and asking the question of how do we, how should we build a 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 at ScrumryConben on Twitter. This is a pixelated stormtrooper because every slide to actually have a stormtrooper. There'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. 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. That was first. I'll come here, right? That was first. Yes. So hi, Ben. Hi. That sounds awesome. Thank you. The bottom line from my point of view is getting rid of location-based addressing and centralizing 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 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 the book. From an engineering perspective, it's a change in paradigm, which means we need to 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. 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 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. Also, if you could repeat the question. Oh, yeah, sure. Hi. I was just wondering if you are aware or you're in connection with the WebTorrent browser project, which is a web browser specifically for websites of the torrent, and the Lisk project. What's the second? The Lisk project, which is where you page through the blockchain exchange to run applications. I'm aware of the web torrent. I didn't quite understand the second one. Lisk. 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 pick, reboot an operating system ISO of the safe network? You can, yes. Because that would be really cool. There are all the ASOs there. All the ASOs. I'm 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 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. I think in the exo namespace 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. But I don't think there have been attempts made yet. The next question. 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? 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 save 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 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 an 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 you're asked. Okay. Hi. Given that there's so many companies nowadays who are storing literally terabytes, 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. 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 uptime is okay but 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. Thank you.
 with Ben, Ben works, develops in Rust and JavaScript in main, made safe, which actually the main  supporter of safe, which he will talk about more, but more about Ben, and his technical  side, Ben develops application API for developers, basically, but he's also a community person.  He writes, he 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 time.com.  I have feedback loop here.  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 glue.nicorn.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 help  you fight the horsemen.  Or in a more positive way, it's time to freaking save the internet.  Did you use the other microphone?  Yeah.  Okay.  Which microphone?  I'm going to give you this microphone instead because this one is really muffled.  Okay, sure.  One, two.  Is that better?  All right.  Great.  Was it okay?  I should have do the introduction again.  I think it's okay, right?  You got the gist of it.  So because we have a big audience here and we're not, 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 infrastructure is 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, you 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 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 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 a 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 look 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.  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 massive islands apparatus, we focus and talk about, rightfully  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.  And 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 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're 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, for example, is 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, seventh to the right.  Natural conversation I have every day.  We think 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  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.  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 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 SHA-1 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.  So what is this?  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 SHA-1.  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 the hax representation of a really big number.  That's correct.  And you can also write it down in base 2, 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 the particular version that we're going to talk about it is cadmium 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 this 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 Chasam 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 nodes goes out, someone else again becomes closer and they  just transfer the information to the other close party.  At the same time, even though this is a huge number of nodes and depending on how many  divisions you do and how many open connections you want to have between 8 and 64, depending  on the system itself, you can, 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 Cadamlia 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.  That has another interesting property in which that is obfuscation of these relaying parties.  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 is, who 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 node.  All they can see is that there's requests from the relaying node coming in for that  file, connections that are already open.  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 ask  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 is 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 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, 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 the 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 RAF as some examples where  essentially a group of nodes whenever a decision needs to be taken is talking among another  until they agreed with the new status.  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 RAF 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 RAF 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.  We just 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.  Making 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 blog.  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.  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, 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 for  me to be happening.  Because if I misbehave, my direct counterpart, my next neighbor, is 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 though 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,  and your N numbers close to a specific type of thing happening within this sphere 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 you need to know the address for.  And then you have a pin to decrypted 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 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.  We're 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 a safe 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 transfer it to you, you don't know.  And after I transferred it to you and you transferred it 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 paid for drugs is very important in our legal system.  So I mentioned the Safe Network a couple of times now and 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 base and XR  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 it, 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 is needed.  Which is 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 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 Matesafe, 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.  The network and the structure inside of it holds all of that information.  Moreover, 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.  By thinking of it that way, every node has their role and if a node goes down, if you  DDoS any of the participants of the system and they go down, another one takes over.  The service would always be available.  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.  I was only able to quickly talk about the exonames space, the group consensus and we  touched the save coin for a moment there.  I want to take another minute on the save coin 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.  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.  It's actually more interesting to me to not have this upgrade in the system because it  makes me better.  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.  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 awarded for that through a currency.  In order to store information on the network or use resources like computation later, you  need to pay this currency.  That means that in the mid and the long term one, 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.  What can you actually do with this?  We've been building a few example applications and I'm rushing through them a little bit.  The most obvious one, XOR namespace is still not very readable, so yeah, there's a public  naming system.  Again, this doesn't require a central registry.  We can just say DNS is the hash of the name that you're looking at.  Whoever claims this piece of data first, they own that domain.  Done.  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.  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.  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.  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.  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.  We have 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 the 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 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 a 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 that 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 what they are doing, and asking the question  of how do we, how should we build a 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 at ScrumryConben on Twitter.  This is a pixelated stormtrooper because every slide to actually have a stormtrooper.  There'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.  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.  That was first.  I'll come here, right?  That was first.  Yes.  So hi, Ben.  Hi.  That sounds awesome.  Thank you.  The bottom line from my point of view is getting rid of location-based addressing and centralizing  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 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 the book.  From an engineering perspective, it's a change in paradigm, which means we need to 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.  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 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.  Also, if you could repeat the question.  Oh, yeah, sure.  Hi.  I was just wondering if you are aware or you're in connection with the WebTorrent browser  project, which is a web browser specifically for websites of the torrent, and the Lisk  project.  What's the second?  The Lisk project, which is where you page through the blockchain exchange to run applications.  I'm aware of the web torrent.  I didn't quite understand the second one.  Lisk.  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 pick, reboot an operating system ISO of the safe network?  You can, yes.  Because that would be really cool.  There are all the ASOs there.  All the ASOs.  I'm 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 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.  I think in the exo namespace 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.  But I don't think there have been attempts made yet.  The next question.  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?  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 save 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 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 an 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 you're asked.  Okay.  Hi.  Given that there's so many companies nowadays who are storing literally terabytes, 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.  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 uptime  is okay but 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.  Thank you.
It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_0_131.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_132_2027.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_2028_2435.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_2436_3767.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_3768_4007.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_4008_4103.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_4104_4427.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_4428_5123.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_5124_6407.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_6408_6539.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_6540_7355.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_7356_7883.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_7884_12479.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_12480_12527.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_12528_15107.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_15108_17927.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_17928_18179.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_18180_18239.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_18240_18299.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_18300_18443.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_18444_18491.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_18492_19583.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_19584_21671.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_21672_21719.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_21720_21947.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_21948_22031.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_22032_22115.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_22116_22199.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_22200_24095.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_24096_30779.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_30780_31835.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_31836_31883.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_31884_37271.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_37272_41255.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_41256_41351.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_41352_41603.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_41604_46079.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_46080_46511.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_46512_46799.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_46800_46859.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_46860_47939.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_47940_48023.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_48024_48227.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_48228_48383.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_48384_48599.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_48600_48731.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_48732_48971.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_48972_49043.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_49044_49127.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_49128_49331.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_49332_49763.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_49764_49907.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_49908_50039.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_50040_50087.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_50088_50147.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_50148_50219.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_50220_50327.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_50328_50375.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_50376_50483.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_50484_50615.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_50616_50759.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_50760_50867.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_50868_50951.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_50952_51083.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_51084_51143.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_51144_51239.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_51240_52787.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_52788_52967.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_52968_53015.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_53016_53087.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_53088_53171.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_53172_53219.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_53220_53399.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_53400_54299.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_54300_55523.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_55524_59135.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_59136_59231.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_59232_64223.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_64224_64271.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_64272_66623.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_66624_81563.png It_s_time_to_SAFE_the_Internet_Introducing_SAFE_the_decentralised_privacyfirst_storage_and_commun_81564_81685.png
with Ben, Ben works, develops in Rust and JavaScript in main, made safe, which actually the main supporter of safe, which he will talk about more, but more about Ben, and his technical side, Ben develops application API for developers, basically, but he's also a community person. He writes, he 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 time.com. I have feedback loop here. 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 glue.nicorn.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 help you fight the horsemen. Or in a more positive way, it's time to freaking save the internet. Did you use the other microphone? Yeah. Okay. Which microphone? I'm going to give you this microphone instead because this one is really muffled. Okay, sure. One, two. Is that better? All right. Great. Was it okay? I should have do the introduction again. I think it's okay, right? You got the gist of it. So because we have a big audience here and we're not, 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 infrastructure is 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, you 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 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 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 a 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 look 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. 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 massive islands apparatus, we focus and talk about, rightfully 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. And 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 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're 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, for example, is 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, seventh to the right. Natural conversation I have every day. We think 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 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. 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 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 SHA-1 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. So what is this? 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 SHA-1. 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 the hax representation of a really big number. That's correct. And you can also write it down in base 2, 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 the particular version that we're going to talk about it is cadmium 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 this 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 Chasam 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 nodes goes out, someone else again becomes closer and they just transfer the information to the other close party. At the same time, even though this is a huge number of nodes and depending on how many divisions you do and how many open connections you want to have between 8 and 64, depending on the system itself, you can, 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 Cadamlia 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. That has another interesting property in which that is obfuscation of these relaying parties. 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 is, who 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 node. All they can see is that there's requests from the relaying node coming in for that file, connections that are already open. 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 ask 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 is 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 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, 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 the 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 RAF as some examples where essentially a group of nodes whenever a decision needs to be taken is talking among another until they agreed with the new status. 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 RAF 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 RAF 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. We just 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. Making 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 blog. 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. 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, 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 for me to be happening. Because if I misbehave, my direct counterpart, my next neighbor, is 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 though 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, and your N numbers close to a specific type of thing happening within this sphere 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 you need to know the address for. And then you have a pin to decrypted 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 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. We're 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 a safe 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 transfer it to you, you don't know. And after I transferred it to you and you transferred it 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 paid for drugs is very important in our legal system. So I mentioned the Safe Network a couple of times now and 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 base and XR 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 it, 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 is needed. Which is 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 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 Matesafe, 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. The network and the structure inside of it holds all of that information. Moreover, 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. By thinking of it that way, every node has their role and if a node goes down, if you DDoS any of the participants of the system and they go down, another one takes over. The service would always be available. 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. I was only able to quickly talk about the exonames space, the group consensus and we touched the save coin for a moment there. I want to take another minute on the save coin 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. 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. It's actually more interesting to me to not have this upgrade in the system because it makes me better. 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. 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 awarded for that through a currency. In order to store information on the network or use resources like computation later, you need to pay this currency. That means that in the mid and the long term one, 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. What can you actually do with this? We've been building a few example applications and I'm rushing through them a little bit. The most obvious one, XOR namespace is still not very readable, so yeah, there's a public naming system. Again, this doesn't require a central registry. We can just say DNS is the hash of the name that you're looking at. Whoever claims this piece of data first, they own that domain. Done. 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. 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. 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. 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. 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. We have 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 the 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 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 a 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 that 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 what they are doing, and asking the question of how do we, how should we build a 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 at ScrumryConben on Twitter. This is a pixelated stormtrooper because every slide to actually have a stormtrooper. There'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. 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. That was first. I'll come here, right? That was first. Yes. So hi, Ben. Hi. That sounds awesome. Thank you. The bottom line from my point of view is getting rid of location-based addressing and centralizing 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 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 the book. From an engineering perspective, it's a change in paradigm, which means we need to 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. 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 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. Also, if you could repeat the question. Oh, yeah, sure. Hi. I was just wondering if you are aware or you're in connection with the WebTorrent browser project, which is a web browser specifically for websites of the torrent, and the Lisk project. What's the second? The Lisk project, which is where you page through the blockchain exchange to run applications. I'm aware of the web torrent. I didn't quite understand the second one. Lisk. 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 pick, reboot an operating system ISO of the safe network? You can, yes. Because that would be really cool. There are all the ASOs there. All the ASOs. I'm 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 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. I think in the exo namespace 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. But I don't think there have been attempts made yet. The next question. 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? 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 save 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 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 an 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 you're asked. Okay. Hi. Given that there's so many companies nowadays who are storing literally terabytes, 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. 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 uptime is okay but 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. Thank you.
like other infrastructure is based on it for its have to upload it into that entire So what are we going to do about it? Well, first really serious look into why is that even a ourselves from the actual problem that our encrypted, that more in transit communication I assume they are from everything we know, then in the internet, in the public internet, a data. And we address those with these systems. addressing something like this, except us. We are things by their location. The example I just made physical location on a specific server anymore Library and then give them the path and they look addressing. And this is already existing in a we have been even addressing things in the wider today in most piracy websites, you would still be about a physical location per se. So what is where I can find this. At some point I still need using very simple mathematical operations. In you just look at the network and you compare the you have the Chasam and you can calculate the you don't have the responsibility to know where With that system, we can very easily define depending on how many divisions you do and how and 64, depending on the system itself, you can, they can see is that there's requests from the post-crucical clusters do where you have a master first place by making really hard puzzles. So the allows us to assign responsibility rather than specific permissions to. So you could give an app five rows back has actually been used to paid for Network is a decentralized privacy-first open source data storage and communications network that provides a secure, efficient and no-cost that with that we can also easily build data retention right into the network because whenever going to get it. But when we say privacy-first, see your private photos. And by doing this stored it, the people who store it from. And need to know anyone, you just connect to the for an infrastructure that is built fully on decentralized and distributed apps and services. the participants of the system and they go down, be available. Because there's no better word, I'm information on the network or use resources like actually do with this? We've been building a few very same system to build fully interactive web also in the perspective of what it means to own transparent to the user. No exchanging of keys, I hear you somewhere between, shut up and take my decentralized apps in the future. And yeah, you engineers, we know that there's also a trade-off decentralized and distributed databases, but it's you interact with the data. I think that is the it's about time that we start asking these questions in a more privacy manner because the the talk indeed. There are more similar projects currency then through the usage of the network of the companies that as it has many of the core developers, once we have this in place, are that all of that data would be spread out over