 Chris, thanks for having me here. I'm just in Singapore for a week working with some artists' drama box in Chinatown and consulting with them on technology and in practice in their artwork, and I looked online and I saw you guys have a JavaScript meet-up and so I thought, and there was one on Wednesday and I was like, oh, I'll put in a talk and you guys kindly let me come along and speak. So thank you very much. Yeah, so I'm going to talk about something I've been working on for a while now, which is decentralized systems on the web. So do you guys know what WebRTC is in general, some of you? So WebRTC is basically a way of two computers, two browsers, talking directly to each other over the internet, rather than, you know, typically when you have like a chat program, you'll have your browser, two different browsers and they'll talk via a server. So WebRTC is like cutting out the server in the middle and just having the browsers send packets directly to each other across the internet. So it's a very complicated protocol because it has to negotiate. Both ends have to figure out a pathway behind through firewalls and stuff like that. But when you get it working, it's pretty magical because it's, yeah, like just literally two browsers talking to each other. And so, yeah, that's what I've been interested in and building stuff around that. And yeah, so this is what I'm going to cover today. I'm actually going to start with a demo. What could possibly go wrong with that? Then I'm going to talk about how to build your own version of the, using the library that I've developed. I should say, if you want to read more, that's the URL at the top, bugout.network. So that's where I'm doing all the decentralized stuff and writing about that and my email and my Twitter account, if you want to stay in touch. So, yeah, then I'm going to talk about how you can build stuff using this library. And then I'm going to show you a bit of hardware at the end. And then I'm going to talk about some of the limitations, like things that don't quite work that well yet with this because it's quite new technology. The first speaker you were talking about, people just jumping in and adopting new technology. Well, no one should do that because this is like very unstable. And anyway, this is my living room back in Perth. So five hours flight south of here. This little machine is sitting there. Actually, this slides a lie because it's now in near my kitchen because I had to move it because my wife said it was in the way. But anyway, it's in my house. And there's only one of what I'm about to show you in the whole world, like this type of server running on that. But I think maybe one day a lot more people might run this kind of thing. So if you go to this URL, you'll see a message board. And a message board back end is pretty simple generally. So fundamentally, it reads some data, which is the list of posts that people have written. And it writes some data, which is writing new posts to the database. And then it talks to browsers to let people do those two things. Usually the back end to that, like what I was saying before, would run on a VPS server. So Linux machine somewhere in a service provider's warehouse on the internet somewhere. Here in Singapore, Digital Ocean have a presence, I think, and Amazon. So you guys get really fast ping times to these VPSs. My own mail server is here in Singapore. So let's check out the message board. I guess some of you might have scanned that by now. Hopefully it's working. Where's my mouse? So this is the message board here. Yeah, some of you have connected. I can see four people. Oh, lots of messages. It'll probably crash. So obviously, if you look at this URL up here, it's loading the actual page and the code from GitHub. And GitHub doesn't have a server back end. It's static pages only. So all the data here that you can see is actually being sent directly from your phones to that Raspberry Pi that's sitting in my living room. That's where it's writing the data and reading it off to print it here. That's probably the hardest workout it's ever got. Yeah, so I've said all that. Yeah, so that's what's going on. It's going from your browser directly to and the way the reason it can run on a Raspberry Pi is on this Raspberry Pi, yeah, on this Raspberry Pi. It's actually running not just like in a shell or in the background. I've actually got a browser running headless on the Raspberry Pi, and that's what's running the server back end. So the server is running inside the browser kind of thing. Sorry, I'm just jumping ahead of my notes here. So yeah, so that's what's happening. The page is being read from GitHub. Then the data is going back to a browser that's running on this Raspberry Pi in Perth, and your computers are talking directly to it. So what does this mean? What this means is, well, one side effect is that I have physical access to the Raspberry Pi and the data on the message board. So I can physically secure it if I want to. I could put it in a safe in my house. And you can do the same kind of thing if you had a computer, a laptop in your house, and you had a reverse SSH tunnel. But I think what's exciting about this is it is really directly browser to browser. You don't need to be a sysadmin. Anybody can visit that tab and run their own message board. So if you look at the bottom of the tab here, if you scroll down, it says, fire up your own copy of the server. Now, if I launch this, now I have this server running on my laptop here. And if you connect to that one, then your phones will be sending messages directly to my laptop. And the laptop's running in the back end inside the browser tab. So it's a very different paradigm from how things normally work. We have a server in the cloud, and your browser talks to the cloud. So what's the point of this? I've been interested in self-hosting movement for a while as a model of computing. Do you guys know what self-hosting idea behind it is? It's like basically running your own stuff. So running your own mail server, running your own calendar server, instead of relying on Google or whatever other provider you want. Yeah. So instead of doing that, you have a VPS somewhere and you'll run your own mail server. And I like this idea. I like the idea of users being able to control the software. So instead of having upgrades forced on them by a company, they can decide when they want to upgrade. And they can decide, like I was saying before, with the Raspberry Pi. Like my mail server is on a VPS here in Singapore, but if there was the equivalent kind of thing that you could run on your own Raspberry Pi, you can literally have your mail server running in your living room. And all of your emails go to your living room kind of thing. And I kind of like that idea of having sovereignty over your own data. Yeah. And the other thing is that it's easy for us tech people to run servers on VPS computers. Like a lot of people here probably run Node.js servers. And we know how to do that. We know how to SSH in or launch a Heroku instance or deploy something on AWS or etc. But a lot of people don't. And it's doing things like setting up SSL certificates is very complicated. Getting a domain name is complicated. And I started thinking about what it would be like if it was as easy for an ordinary non-technical person to run their own servers as it is for them to run like phone apps. So you can install an app on your phone. You're probably your parents. Maybe sometimes they get you to do it. But your parents could probably even install an app on their own phone. And yeah. So what if it was as easy enough for your parents to run their own servers? So what if your parents could do things like run their own calendar server or they have some reading meetup and they could host the forum system for their reading meetup themselves instead of having relying on some third party or a drop box. They have maybe they're part of some other organization or at their work and they want to run their own drop box. So currently things are very centralized. And it's interesting to think about what happens if that's decentralized more and we can all do our own kind of stuff. So that's what's possible with this WebRTC kind of architecture. And so this library I built is called Bugout. And you can find that on if you go to bugout.network or my GitHub username is chr15m slash bugout. You'll see the library as well. And what it is is a layer for doing networking and cryptography. So getting the browsers to talk to each other securely. And it's built on top of something else called WebTorrent. And WebTorrent is basically like implementation of BitTorrent that runs in the browser. Because it runs in the browser it's got a bunch of limitations. And real BitTorrent is a lot better than WebTorrent. But yeah, so I was trying to make that a bit more accessible and more useful. So the way Bugout works is to treat the WebTorrent info hashes as chat rooms. So like when you download a torrent on the internet using BitTorrent it has something called an info hash which is like a cryptographic set of numbers that identifies that one file. And that info hash is how all the other computers on the internet can find each other to share that one file. And so this uses a similar kind of idea. There's a room name which I'll get to in a minute. Yep. And all the other thing Bugout does is encrypt things. So traffic between nodes is encrypted. Because you're sending actually WebRTC is already encrypted. But in this case because you've got browsers connecting to each other and you might get a situation where you have someone in the middle listening. So this adds another layer of cryptography on top of it. All right. So if you Google or if you search for maybe use duck duck go. If you search for build a decentralized chat in 15 minutes you can find an article that I wrote which is basically what I'm about to show you now. Which is how to build your own stuff. And I start with the example of building a decentralized chat. So two browsers no server back end and the two browsers are sending chat messages directly to each other. So you start with I know you guys are JavaScript developers so you probably all know node and you can NPM install Bugout and do this stuff that way. But I'm just going to show it with script tags because you know I'm old school and I like the idea of all you need is a browser and the JS file and then you can build something. So start with a basic index file index.html and load the library. Once you have the library loaded you open a new script tag and create a bug out instance like this. So it's very simple. Be equals actually that's got a typo in it. It should be new bug out. So you create a new bug out object and every instance that you create in every browser has its own ID. And you get that doing B dot address. So that's a base 58 encoded string starting with the letter B. You might notice this address looks a bit like a Bitcoin address. That's because bug out uses a similar kind of hashing and encoding when it generates the key pair. And when it shows you that that's basically a hash of the public key. So when you instantiate a bug out instance it'll start reaching out into the network and trying to find other bug out nodes using the same room hash. In the instantiation here we haven't we haven't passed an address that it should connect to. So the default in that case is to connect to its own address. And the reason for that is if you have a bug out node running you can then say you can give out the address to other people and when they connect they put that into their connect string and they'll all connect to that. But you can also use a generic room name so a shared room name. So you might have an application here we've got one elite secret hacker room and every bug out in the world right now if you wrote this code in your browser your instance would connect to all the others that have that same room name. So once you've connected you can listen out for messages from other nodes by binding event handlers. This is a classic JavaScript way of doing things. So this first callback will fire whenever a new peer node is seen by your node that you've created and the second callback will fire whenever a message is received by your node from another node. Messages can still get through from peers in the same room even if the peer doesn't directly connect to them because they use a gossip protocol to reshare everything. So if you have WebRTC isn't perfect and maybe two maybe you've got three nodes in your chat and this one can see this one and this one can see this one but these two can't see each other the bug out protocol has a built-in gossip system so it everything is overshared as much as possible so there's high redundancy. Finally to send a message it's pretty simple you just do b.send and obviously you can like do a JSON encoded packet or any other kind of thing you want to put in there. And that's basically it. These are the simple components that the message board demo that you saw before is built on it's just sending and doing when it receives on message it writes it to local storage and that's yeah so there's a bunch of other things you could do with bug out like RPC which is remote procedure calls but this is the core functionality that enables and the main thing which is browsers talking to each other in a decentralized peer-to-peer way. So again if you want to go through that tutorial in your own time you can look up build a decentralized chat in 15 minutes. So I was thinking about all this stuff and one of the big problems with building decentralized systems is okay let's say you build a something like Facebook but it just runs in everyone's browsers and there's no back-end server what happens when if you I've done a bunch of posts and then I close my browser and I go to sleep and then my friend is looking at my posts and he can't see anything because the data is not available it's on my laptop that's closed and so then I was thinking about this idea of a box so I made this thing called the bug out box which is you can connect to it from anywhere in the world using its it uses the bug out library underneath and you can get it to do things like run server apps which all it does is it's running in in a browser on the Raspberry Pi and it pulls down a piece of JavaScript and runs it locally and you can also get it to torrent do web torrents so you can share data files onto the internet in a highly available way even when you're not around so you just leave the box running so really it's kind of like I'm trying to productize this first thing that you saw here that's in my living room already so try it I've been thinking about a way to make that more available to other people and at the moment it's very beta so I don't know where I'm going with it but the source code is online um yeah so if you want to find out more about that that's at bugout.network slash box so that's all pretty interesting I guess took browsers talking to each other what are what are some of the problems with this it's very it's very new technology web RTC and one of the problems is web RTC signaling so when you have these two browsers that need to find each other on the internet they before they can talk directly to each other they need some way to rendezvous and to negotiate the connection and that actually now is very centralized so the recommendation by the people who like the big companies Google and Apple and that who designed web RTC is to run a signaling server so it's like this centralized server and you're if you're building a web RTC application you use this centralized server to communicate directly um that to me kind of like it's still more decentralized than not doing that than not having web RTC but that signaling phase means that for example if you were hosting us hosting a chat that was directly browsed a browser and some government didn't like what you were doing they could close that signaling server and none of the browsers could find each other after that point so I've been thinking a lot about how to solve that and at the moment I'm working on something which is like a web RTC signaling server mesh so it's like you run a node and on in the on the internet in the back end there's all these servers that form like a cloud so you can't shut them down because anyone in the world is kind of like the bitcoin network where anyone in the world can run their own one and they all interoperate and if one gets shut down you could still connect to other ones but so that's at the moment that's vaporware I've only written like the just started that project but uh that's where I'm going to going with that um and the other downside to this is cryptography in the browser and key management which is related uh browsers are really leaky you know like they're very good at uh it it's very easy to exfiltrate data from a browser if you're like a security engineer and um they you know you can do things like piggyback people's passwords on css requests and that there's just lots of vectors for getting out there so um yeah if if this becomes a thing where it's more common for people to write systems that talk directly to each other on the internet browser to browser there'll have to be some of those security issues solved but my feeling is it's better to move forward on the on the idea and then hopefully the security um from the browser vendors would catch up uh and the other thing which I discussed already is where to store the data and that's uh yeah I think the solution to that is people in the in the long run I can see people running in their own house actually like people used to everyone had a pc at home that was sit on their desk I can imagine people again having a little box that has their like mail and calendars and their dropbox and all that kind of stuff so I'm hoping that that's where things go in the future so we don't have to rely on big companies who sometimes cut people off or whatever um and the other limitation that's not up here it's not really a limitation but it's something someone flagged um when I gave this uh a different version of this talk at a security conference is right now WebRTC is actually um quite invasive in that when you guys connect to that message board um the you can't the WebRTC connection is quite opaque you're like when you you know when you open your console and you see the network requests come going out WebRTC requests aren't in that and to me that's the browser vendors should really do something about that because it's not great that uses I I'm sure I'm sure that there are advertising companies right now using that to fingerprint people like opening up WebRTC requests back to their own servers and it people don't know that it's happening because it's not very visible um so I hope that that gets addressed as well um yeah so you can stay updated with what I'm working on uh at bugout.network or follow me on Twitter um feel free to email me or anything if you'd like to discuss and uh thanks very much for letting me come and talk at your meetup what is it called WebBundles oh wow cool how do you spell that WebBundles yeah so I've got and actually uh the other two weeks ago digital ocean deleted my server here in Singapore um and uh then sent me a $15 uh credit as as like sorry just like erased the whole thing anyway but uh luckily I had backups but um yeah so that's that's one of the problems is I have I I'm personally running the signaling server for the bugout stuff uh because it's built on a web torrent what I'm actually running is a web torrent um tracker and luckily also in the message board and the other stuff and the library itself it has two other trackers that are run by some of the other web torrent lead devs so it still kept working even after my signaling server went down so it is somewhat it's it's not as fragile as it could be and like I don't know those guys I don't know who those people are running those things which I think is a good thing that's that's that's part of decentralization is that like people independent of each other running these things but yeah it's I would like that to be a lot more decentralized than it is the signaling aspect so so right now the aesthetic front end is basically on github and then the connection is initiated via the RTC via that server via yeah no so from so your browser goes to github and gets the page and all the code and then the page is running in your browser and your browser makes a connection to the other browser in via the signaling via the signaling server that's right yeah and so if when I finish that signaling mesh idea what will happen is if you've got two different people with different browsers and they want to chat this person might connect to this signaling mesh node and this might connect to this one and then on the back end they use bit torrent to communicate with each other so it's much more resilient and if any if any one of them goes down it doesn't matter because the whole cloud is still working yeah so my brother works for the company that runs ipfs so yeah we're always fighting dirk is his name yeah yeah ipfs looks cool it's um it's interesting the way so what ipfs is like distributed file system so when you put a file into ipfs it's kind of sharded and run across a whole bunch of computers and I don't like that idea because I don't like other people and their computers so um no I'm only joking I like other people but it's like to me that seems quite fragile I know that they've got lots of awesome maths and stuff that solves it but then I really like the idea of when I put a file on a computer I know which computer it's on and especially if it's like actually my computer so like a vps is good but then digital ocean can just delete my droplet whereas if it's like literally in my house and um my kid flushes it down the toilet then it's my fault but it's like it's you know it's within my I can I can prevent that from happening I think there are two big companies but two companies here and it's important to work a lot with webRTC um one that's the entire intolerability testing for webRTC across browsers so long because it's a horrible problem when it comes to complexity to make sure webRTC works from different versions of browsers to different versions of browsers different operating systems and different firewall configurations and all that kind of stuff and there's another one that uh of officers for signaling and this whole firewall mitigation strategy and so on um to be able to run services is a really quality video right around webRTC and some data is kind of like a side effect of that yeah that's the funny thing about webRTC isn't it it's kind of like they built it so that they could do video chat because it's just much more efficient to send the video straight from one browser to another but then they kind of like left this data channel in there and to me the data channel is what's really exciting it's like you can have it's a socket between two browsers yeah have you used the ipfs stuff I haven't used the ipfs stuff I've had long conversations with a friend of mine who works all right about it and there were like a lot of interesting strategies in it especially it comes to caching because every content has a mini cache meaning if your computer downloads like content from friend like there's a certain cache on your site now meaning the content if labeled available is still kind of available from your cache meaning if your computer goes down because I loaded it from you with that specific version um people can still request it from me instead of from you because I have a cache copy and and having all that built in like a really distributed system for data storage yeah and it's fascinating yeah you know people can see always the limits yeah I mean I think yeah for what it for what it is I think it's kind of like aiming at a different area and also you know like my stuff is really experimental I'm just hacking on things whereas they ipfs are like doing it properly like they're really engineering it and they've got a big team and they've they've got like every language you know whenever I look at their whenever I go to one of their projects it's like there's like seven different github repositories with every language implemented so it's like yeah a big project yeah your friend probably knows my brother because he works at protocol labs yeah no it doesn't just like it probably would if you were doing something that was data heavy so um yeah if you wanted to do like video or audio I would say you would switch to the actual web rtc protocol because this is like layers on top um and then have the two nodes talk directly and use the what what that's good for but uh yeah no it it probably would be a concern I mean my main interest in developing this is is like the idea of social networks and chat and stuff like that so protocols that aren't super bandwidth heavy um yeah so there was somebody who had a decentralized social network and uh New Zealand government they can't get implemented in music players you the music player where like the moment you run an application your music becomes available and everybody can just stream it from you wow like so shared playlists and so on and so on like so it becomes like a social network around music where if you have somebody a friend like boom yes your friend's music and you stream it in a direct way via web rtc and you build this as a um but it was built on top of somebody else's work already to build a social network completely distributed is that the um there's one called scuttlebutt I think yes that one yeah there's also another one uh on top of something called gun with two ends yeah and that's built by Malmo Marti who was the first committed to the bitcoin code base before like after Satoshi Nakamoto so um yeah there's a Wow It was very fascinating but then there's no marketing money there's no company behind it and so on and it was like just getting a big push anywhere um so it's maybe not as interesting because the people making good music might be on it do you use this to like tunnel API requests to your local server like running in your browser I haven't but that's one of yeah that's one of the things I think you could do with that bug out box idea is like have the services running on the raspberry pi in your house and then you could get tunnel packets so right front ends that run in the cloud and then they talk to your own machine yeah yeah well uh yeah so oh I see what you mean so if you had an HTTP server running on the Raspberry Pi and then you make like a request through web RTC and then it comes out as a get request locally and then goes back in and yeah proxying it you could do stuff like that I mean yeah no and I think one of the interesting areas is also like internet of things I mean I don't like buzzwords but uh having you know a raspberry pi or something like that um and it's got the pins that you connect to physical devices and then you can you can have a situation where you can have a browser that talks directly to that controller controlling physical stuff without having to have the server infrastructure so you could just make it a lot cheaper and I think that's that might be one of the reasons why there's a lot of like activism around decentralized web and re-decentralize the web and all that but I think one of the reasons it might actually end up working out is because it because the economics of it are good so if you're if you're building like a competitor to Slack now and you tried to use this kind of stack you would you would need way less server infrastructure basically you can replace a lot of what the server does with cryptography so um yeah make a cheaper version and uh yeah yeah no they're just very very long so like the probability of two IDs colliding is like so astronomically it's the same as like bitcoin private keys um well yeah so yeah you could oh yeah you could do custom room names so the id comes from so every bug out node has an nacl key pair and you cannot choose the public key like because that's the whole point of how cryptography works you can you can take a seed which is a random string generate a private key and the public key will come out of that but you can't decide what the public key is that would take like the lifetime of the universe to choose your own public key but you can what you were saying before is right you can have a room name that's not the public key of either node or any node and all the nodes use the same room name and that means they connect together so if you're building a chat application that's what you would do like if you're building a chat for your family you would say to your whole family okay this is our room name um and everybody would type it into their phone and they would all connect to that one room name but they wouldn't be connecting to a server they would be connecting to the pool of all of them no it's just a big namespace so if you if you use a a key that anyone can guess you'll get all these other nodes joining in so yeah so I haven't addressed that part but what you would probably do is like some kind of you would hash you would take a password and do key stretching and then use that whatever that's generated and hash it with the room name and then you'd use that so the whole family knows the password and the room name and it would generate something unguessable um there probably is no I mean I haven't I that's something I should should know and I should have tests around but I don't thank you oh yeah cool thank you very much