 Hey, how's everybody doing? I'm Aaron Davis. I also go by Kamavis, whichever you prefer. And today we're going to be talking about MetaMask and how we get Ethereum into the browser. So our core goal is ease of adoption. And one way we sort of measure that is time from first account to first ether to first transaction. And I'm going to bring Frankie and Kevin on to talk about that. Yeah. Hello, dear devs. Let us make you roar about MetaMask made by us four. I'm sorry. OK, this is not good. OK, oh yeah, OK, sorry. A browser extension for Chrome more, but there's even more browsers and mobile coming up in store. MetaMask injects web three in your pages real lazy. Web dapps running in a normal browser, that's crazy. There's no need for a local full node. First time user, you've hit the mother load. We protect you with contra screens so that you don't lose your ether like spilling the beans. On top of that here, have some wallets to hold all that ether so that you can haul it. We love dapps. Ether needs them in stacks. Give us more of them like Flapjack. I don't have anything else to say. So here's Frankie. Yay. Thanks, Kevin. Hi, guys. I'm Frankie. And I'm going to talk about MetaMask from a user experience from first installation to dapp use to first transaction. Louder. Louder? Even louder? God. OK, we are live on the Chrome store. So user goes and downloads MetaMask. And we create a vault. It is a deterministic key ring. I had to remember this this morning. After copying the 12-word C phrase to a safe spot, we now head over to Token Factory, which is a dapp that generates your own tokens. We go through, we fill it out, we hit Create Token, and our beautiful MetaMask confirmation screen will pop up. And you can either accept or reject it. Now, in the case that you don't have enough ether, a Buy Ether button will pop up, and you have two options. If you're in the US, you have Coinbase or you have Shapeshift. Very simple. Just enter your email in, confirm your email, enter your phone number, confirm phone number, and then enter your credit card information. This has a $5 a day limit. Very go straight to your account. Unfortunately, when you get there, you can accept and reject. Once you've gotten your ether, we'll hold the transaction, and voila. You've created your token. Unfortunately, though, if you are not in the US, you don't have access to Coinbase. So if you guys know any products or are working on something that offers fiat to ETH, that would be amazing. Please come talk to us. We would love to hear from you. Our status right now is Public Beta. We have done 44 releases since March. We have weekly updates. We have over 2,000 users and 14 million RP receive requests per day, thanks to Infira. We are Chrome Live, Opera Edge, and Firefox. We are pending and ready. We're just going through the process of getting it into the extension store. Unfortunately, we won't really be pursuing Safari. They don't follow the extension standards. And as far as mobile goes, it's hard to get. We really don't have any mobile browsers that support extensions. And now to talk about how it works, I'd like to pass it off to Aaron. Hello, hello, hello. Cool. So MetaMask, how does it do that? So yeah, you want an Ethereum in your browser. So just take an Ethereum client and throw it in an extension, right? Unfortunately, that won't quite work. You're blocked on networking. The networking uses TCP, UDP. You don't have access to that in the browser, even in extensions. So what are you going to do instead? Oh, yes. Also, for the kind of adoption flow we're looking for, the mandatory sync time is kind of a non-starter. The light client protocol has improved that significantly. But so what are we left with? We can do RPC against the trusted node, where we'll run the nodes for you. And so you have the zero sync time. What do you do for ID management? We do RPC interception. So anything like send transaction or sending a message that involves usage of private keys. We intercept that, sign the transaction, and pass that on as a raw transaction to the trusted endpoint. So here's a little chart of how it works. You have the user at the top. They're looking at the DAP in the browser and the MetaMask UI. The DAP has the UI code in it, as well as the Web3 injected by MetaMask, much like you'd see in MIST. The Web3 generates RPC requests that are forwarded onto the background. This goes to the provider engine, which I'll explain in a second, and onwards onto the trusted RPC. So the provider engine is a tool for making your own Web3 provider. It's basically a stack of RPC handling middleware. It might look something like this. You have a cache layer. For example, if you're asking for the balance of an account twice in the same block, it's going to be the same. You don't need to hit the network for that. Then you got your ID management. That's where your private keys are. And then the rest of the data look-ups fall back to the node. A node on filters and load balancers filters. You install them, and then you check them. You pull against them. As soon as you start using a load balancer, like we do, where we have a bunch of geth nodes, you'll end up installing on one machine and then checking on another. But this turns out to be something that's pretty easy to solve in the provider engine level. So MetaMask has a bit of a different trust model than, say, Mist. Because we provide out of the box, by default, the trusted nodes, the trust model is different. But we could add optimizations. New features quite easily using custom API. But we want you to be able to switch over to your own local node at any time, if you want. So we use 100% RPC to maintain that standard. Again, if we use custom API, you'd kind of be locked into our MetaMask servers. And we think the lock-in sort of devalues the product. And now Dan's going to talk about lessons from working with DAP developers. Thanks, there. Hey, guys. So since we make a product that injects Web 3 into a browser, we get to talk to web developers pretty much all day. And that's great, not just web developers, web DAP developers. And so we hear cool projects. And that makes the job very inspiring and a lot of fun. And also, we end up being kind of the front guard of questions and frustrations and things like that. So I'm going to talk a little bit about the lessons and things that we've learned about the expectations of a web developer in the context of writing Ethereum web apps. So Web 3 right now, it's your portal to the blockchain. So it's so cool. But right now it has a very constrictive API surface. So we want to find ways to make that do what we want. One way that it's kind of opinionated right now, and it may not reflect the truth of a blockchain, is that it kind of has a single callback nature. We've got callbacks. We've got putting to wrap things in promises. But these paradigms that work well in web development, where there's a single resolution, aren't completely representative of the kind of statistical certainty of a blockchain, where you might have a single confirmation, but you don't know how many blocks forward it is or how many additional confirmations. There's a lot more, there's kind of a gradual trust process. So yeah, if you want one callback, you're kind of trusting it. But what else could that look like? Well, coming from JavaScript and Node, sometimes you might want like an event listener. So this is a kind of suggestion. This could be done as a layer on top of Web 3, but it could be optimized much better if it was implemented at the RPC layer. So in this case, you might get an additional callback whenever there's an additional confirmation or whenever there's an additional block or maybe there could be a callback when there's a fork in the blockchain, because right now the RPC doesn't really give you any indication when there's a block fork, short of you querying the latest block and going back because you're querying by block number, not by hash. So for an RPC trust and client, like a web browser, you have to pound your server very hard just to answer these very basic questions. And these are things that the user interface should reflect anyways. Also, web developers always want to just query the database and some things are very simple questions in relational databases, but end up being very difficult on the blockchain. Consider the case of a decentralized Twitter, you just want the 50 latest tweets. The current basic model is somebody basically querying all the tweets in the blockchain. A lot of developers are coming in and they're saying, oh, the cheapest gas thing is logs, so I'm just gonna use logs as my database. And then the method is basically logs since the genesis block, and now the server gets every tweet of all time and then sends it and it all gets loaded up in the browser, which is the interface thread, which then does all the sorting. It's impractical, right? So what are solutions to that? One solution is to write your sorting logic in the contract layer, and so now it's kind of inflexible and it gets run on the chain. It's still one batch, but you could write some kind of pagination logic maybe. There's a cool EIP out there, 144, which would let you send some custom bytecode, some EVN bytecode up to the server, that it would run so you could actually request like a custom result for the state tree. That's an interesting one. I encourage you to check it out, throw in your two cents. Oh, there's also another idea like maybe there could be an additional method on the RPC, like a SQL like query method, but this kind of requires like indexes, and so maybe we need incentivized indexes because logs aren't incentivized indexes. Maybe they could be a contract. Maybe we should have standards around those. Those could be helpful. Sometimes people ask us, why is this method not acting like geth? And it turns out that there isn't really a standard right now. We go to the wiki and then if that doesn't do it, then sometimes we have to go to the individual GitHub repos or oh, it turns out they were using parity. There are fine distinctions and there isn't a singular source of truth right now. So I would just kind of like to take this opportunity to say, hey, how about we develop a Web3 standards body? Maybe we could be decentralized and cool on a blockchain or something. Have votes, have a maybe signing key per implementation and they could say we definitely support this implementation and maybe there could be on chain validation. I don't know, whatever. I'm sure you guys have lots of great ideas about that. MDN is a great example of a standard documentation. So that's the time I'm gonna spend on that. Now to talk about the future of MetaMask. Here's Kumavis. Thanks guys. Hello? Oh, okay. The future in space. So one thing we've been asked for a lot is multiple account types. Right now we just do the deterministic key chain and that's nice, really easy to back up and recover but people want to use proxy contract identities like those being developed by Uport, maybe remote key stores, like you have Coinbase hold your private key and we use an API to get over there. That's in the near future. Also there's some experiments coming from the Ethereum.js community like turning the browser into a light client by having a separate WebRTC based peer-to-peer network and some bridge nodes. A little experiment we've been working on is the Ethereum transaction visualizer. Visualizer, yes. It looks a little something like this. This is one of the DAO attacks and so when you play this one you can see it spiraling in this circle using that attack vector. And so my favorite project right now is this little thing we're calling Masquera and it's sort of a polyfill for MetaMask. So if you have MetaMask in, oh yeah, so it's a little JavaScript file you just drop in your DAP. And if you're using Mist or MetaMask it works fine and if your user doesn't have MetaMask but you have Masquera installed it'll work just as if MetaMask was there. You'll get a little pop-up with your identity management. The keys are stored in a separate context so the DAP can access them. We still assume the DAP is a potentially evil actor. And likewise you can, any DAP that uses that polyfill can send transactions to that thing and your accounts are already there. So thank you very much. Thank you team. MetaMask.