Sessions is temporarily moving to YouTube, check out all our new videos here.

Decentralizing the Internet with Serverless Single Page JavaScript Apps

Larry Salibra speaking at JS Monthly London in February, 2017
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

Larry will introduce the building blocks available to add decentralized features into javascript apps - including payments, identity, authentication, storage, directories, and more.


[Larry] I'm here to talk to you about decentralizing the internet with JavaScript. A little bit about me. This is a picture of me, in case you can't see me here down on the floor. My name is Larry Salibra. I'm based in Hong Kong. But here I'm traveling around in Europe. That's why I'm out here to talk to you guys today. I'm a principal contributor to the Blockstack project. Blockstack is an opensource project. The main team is based in New York City, but we have contributors around the world. You can see a list of some of the projects that I contribute to in the project, some of the repositories, and some of the technologies that we use. I also am a serial entrepreneur based in South China. I've built businesses in a couple of different areas, all involving software. I've also led a development shop based in Guangzhou, China for several years, making products for the financial service industry. I'm also the co-founder of the Bitcoin Association of Hong Kong. So I want to ask everybody a question. Raise your hand if you think the internet has any problems. Okay. That's a lot of hands. Somebody tell me what you think one of the problems are with the internet. Raise your hand up. I'll call on you. Right here. Security. Great answer. What about you, sir? - [participant 1] [inaudible]. - Can you expand on that a little bit? What about infrastructure? - So it's challenging to set up, or... - That's true. Anybody else? One more. Okay. - [participant 2] [inaudible] - Neutrality. Okay. All great things. So we like to think about why the internet didn't turn out the way we hoped it would. If you look here, we have a list of some of the problems that we have with the internet. Honeypots and third-party hacks. So we have these repositories that have tons of data and are just really great places for hackers to focus their energies to get data. Tracking, passwords being cracked, authentication is a big problem. Users often use one password. They don't change them. They don't use password managers. Sites have crazy rules that don't let you use good passwords. They force you to use bad passwords. Platforms lock you in. So people get you to develop on things like parse, and the next thing you know they're sold to a company you may not like, or they decide to shut them down. The power of the profits go to a few. So we have a few big companies. We've got Google. We've got Apple. We've got Facebook. These companies, they make lots and lots of profit, and it's very hard for smaller developers and companies to compete. So here's one of their examples. These are some data breaches from last year. This is about a year out of date. Hundreds of millions of people have private information compromised. Governments, social networks, it's crazy. Last week, we had Cloudflare with Cloudbleed. How many of you heard about that? Raise your hand. Okay. Well, for those of you who were watching, Cloudflare is a web proxy. So what it does is it proxies a large percentage of the internet data through it, decrypts it, has access to passwords, then sends it to the origin server. What happened was they were, unknown to anyone else, leaking passwords and private information into webpages that were being cast by Google and Bing. So you could just go to Google, look up some webpages, and find some private information on them. So what's the problem here? Now, we think that the problem is actually one thing in general. We think the problem is centralization. So this fact that in the internet everything sort of tends to go to a single actor that has all the power in the middle. So imagine a world where you have no data silos. Imagine if all of the data that Facebook had was accessible to all of your users, anybody that wanted to build an app on the platform, without having to go in to agree to their terms of service. Imagine no middlemen, no ads, no tracking. Imagine being able to log in without having to choose a password, having to manage it with a password manager, and imagine being able to take your data from one app and move it to another app. That's sort of the world that we envision at the Blockstack project. We think we can do better, and we think that decentralization is the way that we're going to get there. So today, I'm going to talk to you a little bit about how to decentralize your apps, and some of the technologies we can use. Then, hopefully, get some feedback from you on what you think about this whole concept. Do you think it's useful? What problems doyou see in your own apps that perhaps could be solved by some of these technologies. The way we decentralize, though, is to move apps and data to the edge of the network. So instead of data being in Facebook, data is in your each users' personal data store. Instead of the app is running on a server, the server runs in a browser on a single-page JavaScript app. So to decentralize, we think of four different things. We think of decentralized serverless apps, a decentralized payment network, directories for names, public keys, and pointers to storage locations, and open protocols that let us do authentication and controlled identity in a decentralized fashion. How do we get these things? We can use some of these tools. Single-page JavaScript apps give us the ability to run code in any platform that has a browser. Bitcoin gives us a decentralized payment network. Some of our projects, Blockstack Core and Blockstack ID provide some of the other features. Today, I'm going to give you two examples of how you can add decentralization to your app using JavaScript. They're code examples, since we're all developers, and I think they're pretty straightforward. But I want you to raise your hand if you have any questions. So the first thing is, imagine if you have an app and you want to have money in the app, and you want to be able to programmatically control this money. Now, we could do something like Stripe. But we don't want to use Stripe, because Stripe is centralized. You have to use Stripe's API, and you're sort of... Once you build on top of Stripe, they have the power of lock-in over you. So if they decide, "Hey, the API is free to use right now, but we're going to raise our fees," you have to invest a lot of money redeveloping your app. So we're going to try to add money to apps and do it in a way that's decentralized. So the way we do this is by adding a Bitcoin wallet to our app. If we have a Bitcoin wallet in our app, then our app can programmatically control the Bitcoin in the wallet, and then use it to spend money on APIs or services, or products that the user may want to buy. So what is a Bitcoin wallet? In its essence, a Bitcoin wallet is actually just a public/private keypair. How many of you are familiar with public/private typography? Raise your hands. Everybody. Great. That's what I like to see. So in addition to normal public and private keypairs, we also have something called a "Bitcoin address," and that's essentially a hash of the public key. It comes onto a nice string that's too long to be easily user memorable, but it's easy to copy and paste. So in our first example, we're going to add a Bitcoin wallet to our JavaScript app. We're going to use two libraries here, a Crypto library and Bitcoinjs-lib, both of which are available on NPM. All of my examples today are using ES6 code. So you have to do a little bit of a conversion if you want to use JavaScript as browser is currently implemented. So this is pretty straightforward. To create a Bitcoin wallet, all you need to do is to make a random keypair of public and private keys using this library. Then, you just need to get the address. Then, once you have this address, you can provide it to users so they can copy and paste it into their Bitcoin servers or wallets of choice. You can generate a QR code with an external library, which makes it very easy for people to send money to your wallet or to your app. Then, you can program out of the control the keypair to send the money other places and to buy things, and that's what we're going to talk about next. How do you spend funds in the wallet that's in your app? It's a little bit more complicated, more lines of code. I'm going to walk you through line by line. Can everybody see up on the screen? Is it clear? Okay. So what you do here, if you look at line number two, we create something called a "transaction builder." For those of you that aren't familiar with Bitcoin, what you have in Bitcoin is you have a series of addresses. Each address either has no money or it has some money. If it has some money, that means that somebody has sent money to it in the past and each of those transactions is either spent or unspent. So if it's unspent, that means that there's still that money that you can spend. So what you want to do is you want to loop through these... First, you want to collect these transactions that haven't been spent. Then, you want to loop through them, and then add them to your transaction so that it equals the amount of Bitcoin that you'd like to send. It either equals or is more than. So in this example, what we're doing is we're sending all of the Bitcoin that's at a particular address to the recipient's address, which you see later in the code. So first, what we do is we use an external service to get a list, to get an array of all the transactions. The transactions are actually identified by their hash. Then, we go through each of these inputs. We see how many Bitcoins they have, or how many Satoshis, which is the smallest unit of Bitcoin, and then we add each of those inputs to the transaction. Once we've done that, we have to tell the transaction how much money we have to send and to which addresses we want to send it. In this example, we're only sending it to one address. So what we do is we add that address, the recipient address, and then we add the amount to send. The amount to send in this example is supposed to be the total Satoshis. It's actually written incorrectly. But there's a reason we can't just use that amount. We'd like to send all the money. But because Bitcoin is a decentralized network, we need to pay money for people to process our transaction and that's the fee. The way the fee works in Bitcoin is that any amount left over when you send money to an address counts as the fee. So just to say that again, whenever you move money out of an address, when you move out of a transaction, you have to move all of the money. So you either have to send all the money to someone else, or you have to send part of the money to someone else, and then send the rest of it back to an address that you control, which is called a "change address." So if you have a destination address of one Bitcoin, and then the change is also one Bitcoin, and in total you had 2.5 Bitcoins, you would have a 0.5 fee that is not being sent to anybody. What would happen is the miners in the network would take that money, and they would claim it as their own and that would be part of the profit they make for processing your transaction. Any questions on how that works? I want to say $600, $700 U.S. dollars. That's a really bad example. You don't ever want to be paying half a Bitcoin in fees. But the numbers are easier to work with. Any other questions? Okay. Cool. Show of hands, how many people here own Bitcoins or have used them before? One, two, three. Okay. Cool. So the next thing we're going to talk about is how you add decentralized authentication and identity to your JavaScript app. This will let you do things like log in with Facebook, but without Facebook. You can log in with Blockstack. To give you a little overview of what our project provides, we provide the ability to make apps that are serverless. So instead of rich storage APIs, it lets you store and retrieve data either for a specific app or structured data in general, for example a user's photos or a user's profile, where they're from, their different profile pictures. Our libraries have identity built in, payments built in, the ability to encrypt data. There's a rich keychain library that provides a set of keys that you can use to both encrypt data that the user wants to only do himself or herself, or allow other people to send you encrypted data. So very simple. Imagine you have a Java application, and you'd like to add the ability to log in, in a decentralized fashion. Very simple. Import Blockstack from Blockstack. Let user =Blockstack.loginuser. What happens when this runs, is it redirects the user to another single-page JavaScript app that's being served locally on their machine. Ask them to approve your login and approve the data that you're requesting as part of that request. Then, a JWT token is generated, which is sent back to the app and the app can verify that. This all happens in our libraries. Then, once it succeeds, the person is logged in, and you can use that token to access a whole bunch of other APIs that are running locally on the user's machine. So it suddenly becomes as simple as getting the user's folders or adding more photos to the users photos. What this does behind the scenes is it actually abstracts a very complicated... Not that complicated, but a very complicated set of services and layers. We can go briefly over how Blockstack works. You see here we have four different layers. Now, the base layer is the blockchain layer. So it could be Bitcoin. It could be Ethereum. It could be Zcash. It could be Guy's new coin that he just invented yesterday. So we actually use Bitcoin for our production deployment of Blockstack, and what we do is we store a series of transactions in the Bitcoin blockchain. So we send Bitcoins back and forth, and store data in op return which is a freeform field where you can store whatever data you'd like. Then, we've written software that reads through the entire blockchain, pulls out these special transactions, and uses it to build up a database of names and the values to which they point. So think of it like a DNS system that's based on top of the Bitcoin blockchain. So that second layer, the virtual chain layer, is actually the layer that reads through the blockchain and pulls out specific transactions and creates its own virtual blockchain, and then generates the table you see with domain name, public key, and zone file hash. Then, on top of that we have a routing layer, which is, we divide names... So we have names and names point to zone file hashes. This is sort of the blockchain. Then, you take the zone file hash, and then we have another network, which we can talk about in the future. But you plug in the zone file hash, and you get back a Profile file, which is essentially just a JSON document that's signed. Then, from that document, you can get information about the user's keys, their sign-in keys, their profile information, their links to their data storage. That data is often stored in the storage layer, which can be anywherereally. It can be in Amazon. It can be in IPFS. You can write a storage driver for whatever platform you'd like. We're supporting Dropbox as of now, because it's easiest and it's widely deployed. Dropbox and Amazon S3, but we hope to bring on some other ones soon. So we try to abstract all that complexity through a nice JavaScript API that's easy for [inaudible] to use. So if you want to learn more about our technology, you can go to our website and there's three different peer review papers that have been published and presented at several well-known conferences. A little bit more about us. We're the largest non-financial blockchain protocol on top of Bitcoin. So about half of transactions that are not financial are from our project. This is sort of the core community, people that are writing code and contributing. You may or may not recognize some of the people up there. Ryan and Maneeb here on the right are the founders of Blockstack, the company. I'm one of the early community members. This is a very great group of people. We've got about 1,500 people in our online community, Slack Forum. We've got meet-ups around the world, so we'd love to hear sort of what problems you have that you think might be able to be solved by decentralized technology and Blockstack, and what you could build on top of it, if you think it's useful. If you'd like to contribute some code, we'd love to hear from you. So that's sort of my overview of how we think you can decentralize the internet with some of these technologies. I'd love to take questions or hear what you guys think. Please? - An application besides financial? I think a really good use would be a decentralized Twitter, for example. Particularly in the U.S., we've seen a lot of censorship. People that have certain political views get their Twitter accounts deleted. So that's sort of a problem. Any place that you have censorship is a really good application. So whether it be a government that doesn't want you to say something, the centralized control of the platform. Like maybe if you came out strongly against Mark Zuckerberg, for example, maybe he would delete your account. So apps that let people who don't have a voice have a voice are particularly useful. Yeah? - Okay. Sure. Yeah. No, I understand. So to log in, it's relatively instantaneously. It should be faster than login with Facebook, because it's all running on the user's computer. In terms of what is slow, if you go to register a name, that's on the Bitcoin blockchain. So it takes several hours to actually confirm so you can use it outside of your own computer. So that process is about a quarter of a day. But we're working on a solution where you can use free, one-time use. Like you can generate a Bitcoin keypair. You use that as your identity, and then if you choose to keep using this system, you can go register a name later, and it'll be owned by that Bitcoin keypair. So the way names are owned in Blockstack, every name is owned by a Bitcoin address. So if I want to send my name to Guy, for example, I would make a special Bitcoin transaction from my address that owns the name to his address that he wants to own the name. Anything else? Please, sir. - I think our vision is... I mean, there's our vision and what may happen. What may happen is there probably is going to be coexisting... There's a cost in some ways to decentralization. But personally, I think that what will happen is that a lot of the things that we see that are centralized and capturing a lot of value today, we can just aggregate those, whether that be a Facebook or whatever. Then, I think other businesses will get built on top of this. So we'll be able to hopefully decentralize the data. But then, once you have decentralized data, you can sort of build another layer of centralization on top of that. Right? Then, maybe at some point in the future we'll have to go and figure out, "How can we decentralize that as well?" - Yep. We're using the same Bitcoin that everybody else uses. We originally started the project on Namecoin, which Namecoin was an early fork of Bitcoin that was modified to provide DNS-like features. We ran a production system on that for about a year or so, and we ran into a bunch of problems. Some of the problems that we had with not running on Bitcoin are that Namecoin turned out to have the majority of an [inaudible] controlled by one miner. So we hoped it was decentralized, but actually it was controlled by one person. Because it wasn't very widely used, there were a lot of bugs in the codebase. So our view is that... So our system is built so you can run it on any one of the blockchains that I talked about before. But if you want the characteristics that make the blockchain unique, the censorship resistance, this consensus mechanism, if you want those, you really want to be on the strongest, most powerful, hardest to attack, most secure blockchain. So right now, that's Bitcoin. I don't know what it's going to be in the future, and we've tried to build our system so that we're Layer 2. So Layer 1 is the blockchain, so Bitcoin, Ethereum, whatever. If for whatever reason down the line it turns out that, "Hey, Ethereum now is harder to attack than Bitcoin," we have mechanisms to... We've already migrated from Namecoin to Bitcoin. We have mechanisms and protocol to make another migration in the future. We also have this ability to make namespaces. So for example, think of top-level domains. Right now, there's only one in the system. It's ".id". So if you were to register a name, you register your, and you can use that to log in places. But you can also create new namespaces by spending Bitcoin to buy them. The way we envision the system is you can create a namespace, maybe a namespace .eth. Maybe that namespace actually points to the Ethereum blockchain. So it's possible to have a system where different namespaces that have different characteristics are backed by different blockchains. - Yeah. So the question is scaling in anything built on top of a blockchain. Is a very good question. You're right. It's a very challenging question. So just to rephrase what you said, the challenge is not so much that it makes mining more complicated. Mining is already very specialized. You need to have specialized hardware to do it. It's pretty much all made by one manufacturer in China, which is a whole other problem. But what it does is we have a limit to the number of transactions that can be processed per unit of time, and it's very low. [inaudible] I think seven transactions a second. So our vision for that is, first of all, to use our system, if you're registering a name, you only need to make a couple transactions. Once you've registered the name, unless you're transferring it to someone else, you don't need to make any blockchain transactions. Upgrading your profile is free. You just sign in with your private key, and then upload it to Amazon. So by using a few number of transactions is one way that we help that problem. Another way we're looking at the future, We're looking at a couple different ways, one of which is to have subdomains. So for example, I pay to register something .id, and then I issue subdomains to all of the people that register, or whatever. There's ways where you can do that. I mean, you get some centralization, but you can move some of it off blockchain. Also, ways that we can pack multiple registrations into one transaction. It's a very challenging computer science problem, though. How do you maintain these characteristics that we want, but make it so that it scales? If you're very interested in that, we have a conference not related to Blockstack, but I'm a program organizer for - It's called Scaling Bitcoin. We've had three there, and the last one was Milan, Hong Kong, Montreal. You can check that out, Lots of really smart people there presenting papers on their research on how you can scale blockchain. Very interesting topic. Anything else? Thank you very much.