 All right. Prologue. We live in a special time. We're in the middle of this graph right now. 200 years ago it took years to send information from one end of humanity to the other end of humanity and now it's instantaneous. But as we spread out to the other planets, to other stars, we won't be able to do that because the speed of light. A little bit about me, a little bit more about me. My name is Chad Ostrowski. I live in the Orion Arm of the Milky Way Galaxy on a water world called Earth on the east coast of the United States in a small city called Lancaster, Pennsylvania. This is what I've been up to for the past 14 years. This is my entire dot life chart. Each of these dots is a month of my life. The emojis represent significant things that happen. You can get one yourself. Go to entire dot life. That is the URL. Check it out. My day job I work at Citrusbite. We are about 70 people all around the world including here in Barcelona and we're always accepting applications. So if you're looking for a new gig, check us out. You can find me on the internet at Chad OH just about everywhere. Disclaimer, Earth is a spaceship and we're the passengers, cosmic pilgrims on a voyage toward truth. Or we're basically algae on the side of a boat. Cosmic algae. I am cosmic algae. I am learning with you. I am not an expert on a lot of the things I will be presenting. So if you know better please tell me afterwards so we can set the record straight. All right, where we're going? We're going to talk about problems of the future or problems of futures present. And then we're going to talk about solutions. We're going to run through offline first. We've heard about it a little bit already today but we'll see it in this new context. And then the distributed web. And my goal is to give us a good framework for how to think about all of these different technologies and how they all fit together. So let's go on a journey. How far is it to Mars? Let me switch. All right. So this is a website called distance2mars.com. And it says if the Earth were 100 pixels wide and then you can click a little arrow and fly to the moon. The moon would be 3,000 pixels away. Didn't take us long at all to get there. Meanwhile Mars at its closest would be, and now we see the stars moving, which you would not see the stars moving on your way to Mars. It would all be very still. You would see the Earth shrink and then you would see nothing change for a long time. As it says on the screen right now, we're currently going 7,000 pixels per second which is three times faster than the speed of light. So we will get to Mars very quickly, much faster than we can send radio signals or text messages to Mars. It will take 150 days to actually fly to Mars, current technology. Like I said, we're seeing right now kind of a simulation of how long it takes just to send one message, one direction to Mars, except we're going three times faster than light. It feels so fast, right? And I think the stars are about to slow down. You can see the little scroll bar over in the far right, working its way down the screen. And here we are. We're finally at Mars. So that was 56 million kilometers divided by the speed of light is three light minutes, which is a six minute latency, six minutes round trip during the fast part of the year. The longest, it can take 45 minutes round trip, 22 minutes each way when Earth and Mars are far apart. Who here has heard of Mars One? This is a non-profit organization that wants to establish a permanent human colony on Mars. Their current estimates are 20 30. A lot of people don't think that this will be the organization that actually does it, but it's really fun to think through what this would, how this would play out. They want to land four people on Mars in 2030 and then four more people two years after that and four more two years after that, et cetera, et cetera. On their website, on their FAQ, they have this question. What will the astronauts do on Mars? And part of the answer here has always stuck with me. They say Internet access will be limited to the astronauts' favorite websites, which will be, oops, oops, let me go back, there we go. Easy Internet access will be limited to their preferred sites, which are constantly updated on the local Mars web server. Other websites will take between six and 45 minutes to appear on their screen. So this line, preferred sites that are constantly updated on the local Mars web server, I was like thinking about that, it bugged me. And I think what I came to is like, does this even qualify as the Internet? No, this doesn't qualify. The Internet is a discussion. It's many to many. It is controlled by its participants. It is a great democratizer. And if I can't contribute, then it doesn't count. So let's think through it. Maybe Mars One was thinking about simple pages of static content, like this one. It doesn't matter what the content is, so I've blurted out. But even simple pages like this are very rare on the Internet. Usually they'll have a little thing in the bottom right where you can vote and say, yes, I liked this, or you can share it with your friends. Moving up the stack of how interactive apps are from there, we have social media. We on Earth will want to see what the Martians are up to. We'll want to look at their Instagram feeds. If the Internet's read only for them, how will we do that? And then there are all the apps that assume that you have constant, fast connection to the backbone of the Internet, stuff like Slack. Things like Slack will just never work on Mars the way that they're written right now. So, meanwhile, 2017, why should we care about this? Why did I bring us on this journey? Why do we want to solve this problem? My thesis is that tomorrow's problems are today's problems, but bigger. If we solve tomorrow's problems, we will solve all sorts of interesting problems right now. I'm going to be talking a lot about helping people or serving people in this talk. If that is not motivating for you, you can roughly translate those ideas into making money. Sometimes helping people can also help you make money from them. Sometimes helping people does not make money, but you can think of it that way. All right, so problem one, latency. We can totally fix latency if we fix this Mars problem. These are Amazon's data center locations. The yellow squares are their actual AWS locations, and then the little red circles are their CDN, their content delivery network. You can see that whole big parts of the globe are not served very well by them. And some of these parts have the worst infrastructure. This is a gift showing the number of Internet users and how it changed from 2000 to 2012. That last one was 2012. And you can see even at the end, in 2012, a lot of Africa still is not very well covered. And the infrastructure in a lot of these places is not good. It's very slow network speeds, and sometimes people are charged a lot for the data that they use. So we can fix this problem if we make an Internet that even works on Mars. There are 86 million people in Nigeria alone that are online right now, and that's with 46% of the population. So that's a lot of people to help. And then bringing it closer to maybe a lot of our experience, there's just airplane mode or spotty Wi-Fi connectivity, spotty cell connectivity. Flaky network connections are not limited to the developing world. It's something that we all experience. Earth problem number two, censorship. In 2011, Egypt cut off all of the Internet for the entire country, which brings us back to these folks. This is during the Arab Spring, they were trying to organize for a while, they were trying to get their democracy, communicating with Twitter, and then they couldn't talk to each other anymore because all of their communication was stored on a server way far away. And so it could no longer make the round trip back to them. This is countries at risk of disconnection the way that internet, the way that Egypt suffered disconnection. We in the blue countries tend to feel pretty smug about this, but just a little while after this, the internet was shut down to foil a protest. And censorship is a similar problem. It doesn't have to be as extreme as shutting down the entire Internet. Problem three, data growth outpaces network speed. In 2013, there were 4.4 zettabytes of data on the Internet. This graph is showing if you stacked up iPad errors, how far they would go to the moon. There would be like two thirds of the way to the moon in 2013. And in 2020, there's projected to be I think 6.7 or so ways to the moon. So 44 zettabytes. A lot of this is driven by the Internet of things. We have all these new devices that are sending a bunch of data back to centralized warehouses. Entire data centers are full of different sensors that are now being used to track everything. So there are just these huge data sets. And other data demand is being driven by WebVR or just VR in general. All these new augmented reality experiences or virtual reality experiences, 4K video, et cetera. The speed of the network does grow exponentially. This is a logarithmic graph. So if the straight line means that it's exponential, but it doesn't grow as quickly exponentially as computer power and our ability to store things and our desire to measure more things. So what do we do about all these different problems? How can we solve all of them? Let's go one step at a time. Let's think about we have Mars on one side and we have Earth on the other. And let's say that I'm on Mars and I visit, oh, and let's just say on average that they're 12 light minutes apart. So between three minutes and 22 minutes, 12 light minutes. So I'm there on Mars and I make a request for a web page to Entire.Life because why wouldn't I? And it takes 12 minutes, goes out to Earth, comes the whole way back. And then that page starts rendering. And my browser says, oh, it also needs some styles and some JavaScript and some assets. So back to Earth, it goes, gets the rest of the assets. And 48 minutes later, I can finally look at one page. All right. So improvement one, I think we heard about this earlier today, HTTP 2. So in this setup, I make the request for the web page. It comes back. But instead of just that one page, it also pushes along my styles, my JavaScripts, my assets, all the assets that I need in order to render that page. This is called server push, it is the server push feature of HTTP 2. So 24 minutes. Hooray. I mean, still not great. And it gets worse. Because let's say I tap a link and now that link has to go the whole way back to Earth. Except wait, we're front-end developers. So this is a single page app. So that will be instantaneous. Great. But let's say the next page loads in some plug-in JavaScript. And it loads in some new assets. So those now have to go to Earth. So it's 48 minutes for two whole pages. Big improvement there. And then we'll have to do it all again tomorrow, right? If we want to visit the website again, our browser is going to have to re-go through this whole dance, downloading all of these files, even though they probably haven't changed. So that sucks. Improvement number two that we can make is service workers. Service workers give us periodic background sync, push notifications, and most interestingly for this context they give us rich offline experiences. They sit in between your app, they run in the background in your browser and whenever your app makes a request, it'll get intercepted by a service worker and the service worker is going to send back cashed assets if it has them so that it doesn't have to go the whole way through the network. In this case, the whole way back to Earth. Can we use it yet? Yes, if you go to, if you look up as service worker ready, the URL is not easily rememberable. But if you go to is service worker ready, you can see which features browsers currently support. For a lot of users, they can already start using service worker right now. So now, with service workers, service workers, I'm on Mars, I send my request to Earth, and now the server on Earth sends back my index.html, my styles, all those assets plus another asset, register service worker.js. And as soon as that gets back to Mars, my page starts going through it and it's going to send off the new request for the other stuff it's going to need in the background for my app to be fully functional. And then Earth will send all that stuff back. And now, maybe, if I was sitting there looking at one page for 48 minutes, by the time that I visit the next page, all of it will already be there. The app is installed essentially within the browser. And it'll all be there tomorrow. So whenever I go back, it's already there. So, I mean, we're going to have to expect some latency for people on Mars. It takes a long time to get that stuff. But at this point, we've got a working web app. It's not, it's not too bad. It's pretty cool. Except 48 minutes to install the app. Let's just say that the app is installed now. So, app installed. We'll just put a little check mark there to indicate that. And I'm browsing around the site and I come to form. And now I fill out this form. This is what Entire.life looks like. It's going to send a post request to an endpoint. And then when that data comes back from the server, when the server says like, yep, I saved it, then we update the user interface to show that event that they saved. This means that we're going to have a post request going the whole way to Earth, coming the whole way back. And 24 minutes for every single interaction. Not so great. Improvement three that we can make. Local storage. So the idea is that we will store data locally and sync it back to the server periodically. There are two underlying technologies in modern browsers for this. Local storage and index DB. I didn't know what to call this whole concept. Maybe web storage. It's weird to call it local storage and have one of the sub technologies be also called local storage. But here we are. So yes, these things are ready. You can use them in browsers now. And there are lots of tools to make it easier. Local forage is a pretty low level one that gives you a consistent API so that all of the browsers because all of the browsers implemented a little bit differently. Some of them use an older technology called web SQL. So local forage wraps them all up. Pouch DB is a whole like database that lives right in the browser. And the idea is that you have an entire real database in the browser. And occasionally, Pouch DB automatically syncs back to the server. It's made to use Couch DB on the server. That's couch with a C. You can use other things, though. There are things like RX DB, which use the same idea, but aren't maybe as tied to Couch DB or that same API. And there are lots of other tools that people are working on. Swarm, JS, synced DB, shared DB. And hoodie is a whole back end as a service that tries to make it very easy to do offline first applications. So we're on Mars now. We've installed this app with service workers. We have our little check mark saying that we've installed it. And now we're going to add things to a queue. We're going to instead of sending a post request every single time that we hit save on the form, it's going to add them to a queue. And I can add multiple things. And then every now and then it's going to sync to Earth. And when the request comes back, then we can clear out the queue. And now we know that the database and our local storage are both synced. So we're getting there. This is decent. It's almost working. Service workers plus local storage is approximately what people mean when they say progressive web apps. It's also approximately what people mean when they say offline first. So we're getting there, but there are still problems. So this all seems very Earth centric, right? Like, isn't it annoying that we live on Mars now, but we have to keep going to Earth for all our data? If we think about having this installed app, or we're going to make it a new problem, I have installed the app, I am on Mars, but I have a collaborator on Mars also, someone else, one of the four people who is settling it. When she wants to get the entire .life website, she has to make a request the whole way back to Earth, even though I already have the files there on my machine. And then the Earth sends them, like, that's just so annoying. Why can't she just request them right from me? And then I send them right back. Is there some way that we can do this? We need a better architecture for building apps like this. Specifically, everything we've been talking about so far is the client server architecture. We have browsers that are in our phones or in our computers, and they send a request out across the Internet to a server, and the server is the master. The server is where all the data lives, and then the server sends it back. This is kind of, this is described by this 1962 chart. Someone created this idea, came up with this idea in 1962 when the U.S. military via DARPA was coming up with the DARPA net, and they said, okay, we definitely don't want a centralized network. A centralized network means if there's a natural disaster or a bomb strike on a centralized spot, then we can't communicate with each other. That's bad. And what they wanted to build was a distributed network, where it's all a bunch of peers in the network. Instead of that, what we've ended up with is this decentralized network. It's pretty good. There's no one point of failure, but there are still these servers are like the masters of the whole thing, and then there are these dumb nodes out on the end. How do we get to this distributed one? My tagline for the distributed web is where two or more devices are gathered. There the internet is also. So if we're sitting right next to each other and we have these amazing communication devices, why can't they communicate right with each other? Why can't we do this? The distributed web answers this question. Can my collaborator just ask for the files right from my machine with an emphatic, yes, yes, let's do that. So how do we do that? BitTorrent? Maybe BitTorrent. BitTorrent uses a tracking server, which is kind of centralized, to keep track of all these different pieces of files. And then you can download all the different pieces of files from all the different peers in the network, which seems like it's getting close. Or maybe we can use Git. Git, unlike older version control systems, is totally decentralized. Subversion, SVN was a little like our Mars Earth scenario that we've been talking about so far. But with Git, everyone has a complete working, fully, like it has the entire history of the entire source code on every single machine. And then whenever you make changes, you push it up to some place where your collaborators can pull it. But it doesn't need to be GitHub. We all use GitHub. We have all centralized this beautiful decentralized piece of software. But it doesn't need to be centralized. Git does this using what's called a Merkle tree. This is this structure. So this whole concept was invented by Ralph Merkle, who also invented public private key encryption. We called a Merkle tree or a Merkle directed acyclic graph, which is a mouthful, so we shortened it to Merkle dag. And the idea is that there's a one-to-one relationship between a file and a hash of a file. You create a hash of a file, and that hash will uniquely identify that content. So 3FA0D4B98 uniquely identifies hello world. It will not, there will not be other content that could be represented by that hash. So this means that we don't need the tracking server anymore in BitTorrent, right? We might be able to use Git and BitTorrent together because now we don't need a central server to keep track of where all the pieces are because of all of our content is uniquely identified by different files. Enter IPFS, the interplanetary file system. A peer-to-peer hypermedia protocol to make the web faster, safer, and more open. It describes itself as similar to the original aims of the web, but IPFS is actually more similar to a single bit torrent swarm exchanging Git objects. That sounds like what we want. Cool. So improvement four. We'll throw in IPFS. IPFS is a distributed file system that seeks to connect all computing devices with the same system of files. Again, that sounds perfect for getting files right from one person to the other out at these edges of the network. It's becoming a new major subsystem of the Internet. If built right, it could complement or replace HTTP. It could complement or replace even more. It sounds crazy. It is crazy. All right, so how does it work? It is content addressable. Right now, whenever you say Twitter.com slash some user slash some tweet, it's kind of like going to a particular bookstore and saying, give me the book five in from the edge on the bottom shelf. And then that bookstore will hopefully hand you what you expected to see, but they could change that. Instead, IPFS uses slash IPFS slash the hash of some content. And this hash uniquely identifies the content just like in Git. So you know that what you're getting back is the content that you wanted. This is more analogous to using an ISBN and being able to go get the book at whatever local library instead of needing to go to one particular bookstore. So we can do this. We can send the files from me to my collaborator on Mars. And now we both have the app installed. No round trip to Earth. Sweet. But all right, we have that. But we're still using this queue where we're adding different data that we want to sync back to Earth to my local machine. And then at some point that's going to sync back to Earth. And then maybe Earth sends it to both of us. And now my collaborator has the updated, like, no, this again, we don't want this. We don't want round trips to Earth. It's way too long. It takes too much time. So instead of thinking of this queue, what if we just say like, okay, this data structure that lives in my browser is the database. We both have a full copy of the entire database like Git. And like Git, our database is identified by some hash, 8B716, et cetera. And then whenever I add an event, the hash of my database changes. And maybe I can broadcast that. I can publish that out for different subscribers. And the subscribers can say, cool, and update their own local copy of the database. And now we're storing a database in two different locations, this decentralized database between the two of us. Can we do this? Oh, one more thing. When someone back on Earth, like, now our database only lives on Mars. What if someone on Earth wants it now? What if we want to show off what we've been up to? Well, maybe we can both send it back. It'll be a little bit like BitTorrent, where we can each send back different pieces. We only have to send back half the data. Or if there are four of us, we each send back a quarter of the data. And then once it's back on Earth, of course, it'll distribute very quickly around the Earth network. So can we do this? Yes, we can. It's called IPFS PubSub. There's a whole video that you can find on the IPFS blog, where it uses IPFS PubSub, which is that idea of updating the file locally and then broadcasting to all your peers. It broadcasts it over WebRTC. And then it uses this algorithm called CRDTs, Conflict Free Replicated Data Types, which is a whole area of study into resolving conflicts. So if we update the same line at the same time, what do we do about that? CRDTs are a whole methodical, like, area of research around what to do about that problem. And there are already libraries that do this. So you can go start playing with this and build cool little apps that really are serverless. There is no server in the background. It's just two browsers communicating with each other. All right, one more puzzle piece. We've got distributed files and data now. Files and data that live on the individual nodes and then radiate out from there, right? We're creating our content on Mars. It goes back to Earth when it's requested there. But what about server-side logic? We now have this whole network of peers. Where do we do things like transactions, sending people money, or other things that we don't trust to run in JavaScript in someone's browser, where they can manipulate it? Really, what this is, we think of it as server-side logic. But what we really need is incorruptible logic, something that someone can't muck with. So we both have our apps installed. And now instead of sending data, let's say I want to send money. We're going to use this to keep track of how much money I have sent to the other people on Mars. I don't know why we need money on Mars. Maybe this metaphor is getting stretched too far. But maybe I add it to a payments table in my local database, and then I broadcast that. But what's to prevent the other person on Mars from saying, like, oh, yeah, he paid me way more than that, actually. He paid me three times more than that. That would make me very sad. So we need some way to do distributed ledgers, to all have a concrete idea or to all be able to agree with no central authority coming in between us to say who has how much money. We all need a way to agree on how much was sent and how much was received. This gif is from an awesome video about how the blockchain works. So this idea of distributed ledgers or distributed consensus, which is what we need, is also known as blockchain or Bitcoin, Bitcoin invented blockchain. Bitcoin came up with this idea of distributed consensus, consensus without a central authority. Or in this case, since we want incorruptible logic, not just the transactions, we can use Ethereum. Ethereum gives you smart contracts, contracts that are run between different machines in the network without the need for a central authority. This is their web page. They talk about building unstoppable applications, and they talk about this idea of smart contracts and incorruptible logic. So improvement six, Ethereum. And we did it. We have a fully functional app for any network edge. We fixed the Martian Internet. We fixed latency. We fixed censorship. We can put data close to where it's needed. We're feeling pretty good. And it gets crazier from there. Instead of getting like sadder from there, now it can get even weirder and cooler. Because we don't, we're not limited to the same kind of apps we built before. This is from the Ethereum homepage. And in the bottom left here, it has this, you can build, I'll make it bigger, you can build a virtual organization where members vote on issues. A transparent association based on shareholder voting. Your own country with an unchangeable constitution and a better, better delegative democracy. This all gets very blue sky, very like wild thinking. And you can, you can do things like build Airbnb the service without Airbnb the company. Now that people can interact directly without a middleman, a host can directly rent out their room to guests without needing Airbnb the company to mediate. And that opens the doors to all kinds of crazy things like this stuff. So let's wrap up. Where we've been. Problems of futures present. We have solved them. We've solved them with offline first, which is ready for you to use now and the distributed web, which is still falling into place around us and which you can still contribute to and shape the future of. And that is all. That was really fantastic. I'm very excited about the future of the interplanetary Internet. I have a few questions here for you from the audience. Let's see. You mentioned that AWS has a concept of regions. Should we treat planets as regions and design for high interplanet availability? I mentioned that what has regions? AWS regions. AWS has regions. Yes. So I would expect that like in one way that we could make the Martian Internet work is that you would be able to deploy to Mars. I would also expect that to be very expensive and for only big players to be able to do it. So I'm interested in solutions that are more accessible to all of us who are building side apps or new startups. Awesome. WebRTC typically needs a signaling server to connect to peers. Can this be distributed for interplanetary use easily as well? A signaling server in order to connect to peers. I have not actually used WebRTC myself. I know that with the example that I gave of the that video for using IPFS PubSub and CRDTs. I know that your computers find each other. I don't know if right now it's using some kind of signaling server. A lot of this stuff with the distributed web there are still parts that need to be centralized right now and people are doing a lot of thinking and a lot of work to figure out how to get rid of all the bits of centralization. Last question. How do you handle sensitive data and how do you handle sync failures? These are great questions. Right now IPFS is unencrypted or it's all you could encrypt it yourself and put something up there but there's no way for like you would have to work out with people on the other end how to decrypt that so you would have to send them a private key file or something like that or use keybase.io. So people are like the IPFS team the team that creates IPFS which you could contribute to of course but there is a company behind it called protocol labs and that is on the roadmap is to build in private data and it actually ends up being more private because instead of sending this data that you're then trusting a third party to encrypt you can essentially encrypt it yourself so it's encrypted the entire way over the wire and only the people who you give access to can then read it. Very cool thank you so much Chad. Let's give him another round of a