 Thanks so much for MetaMask. How you guys doing? Woo! All right, a3.com. End of the day. I hope you have some energy because, yeah, yeah, I'm going to ask it of you. Okay, so I'm going to share some stuff that I'm really excited about. We've been working on it for a while. We've been thinking about a lot of things. There's a lot of challenges in this ecosystem. You know, I think MetaMask at this point, we're like the thing that you love to hate. It's like, you know, we forget the joy of being hated because you use us too much, you know? So we're constantly thinking about, like, what's the next step? How do we get you guys where you want to go? How do we get your users where they want to go? How do we get out of your damn way? How do we unite these three things? That's going to be a kind of theme, security, utility, usability, and to clarify, because some people think that usability and utility are the same. I'm going to say for my purposes, when I see utility, I mean functionally, like a command line coder could do it, but when I say usability, I'm talking about like accessibility, like anybody could do it. So how do we make something that's so secure that anybody could do it but that they could do kind of anything, right? That's the dream, right? And we want to make that possible for you. So right now modern wallets are limited in these three axes. The first one, innovation, right? We don't add new networks fast enough. We don't have your favorite chain, your favorite proof of authority, whatever. We don't add new EIP features. There have been better token standards than you got ERC 20 for like five years, like longer than the period. So like, we don't support the latest scaling tech, right? Today, if you've got a new plasma thing or you've got a new, you know, layer two thing, you're basically going to make your own wallet. So it's like that beverage theme will be like, well, you make a new wallet. You make a new wallet. Contract, you make a new wallet. You've got a new hosting service or alternative. Make a new wallet. You've got a new hardware wallet. It's not supported by us when our versions pass up. You're probably going to have to make it into your own wallet. Now, you've got a new kind of cryptography. You've got some obscured stuff. Make a new wallet. Too slow to merge FloraFest. Did we not get that feature in in time? Fork us. Make a new wallet. We're not secure enough. We're a JavaScript runtime. Now, I hope that you saw Aaron's security talk on Lava Mode. He's been in it a couple of times. He's talking about how we're working to isolate our dependencies better. And you should check that out. You know, it's a little bit on Twitter. But you know, that's scary. And the average wallet. It's a big pile of dependencies. And every new feature increases the attack service. So you're simultaneously furious at your wallets for not having enough features. And you should be terrified the more features your wallet has. Because each one of them is making you more vulnerable. And there's account management trade-offs, of course. And we all have our favorite ones and like to crap on the other ones. You know, if you make the users record their keys, or memorize passwords, they can just lose them. You might have some new great contract account idea. You know, maybe you can get the parody team to put their funds in it. And then lastly, the wallets just aren't usable enough, right? You've got a... Sorry, it's not a good one. Yeah, I'm sorry. I don't know the wording of that. But yeah, you want to upgrade. You want the procedural and progressive security. You want to be able to say, look, if you've got nothing in your wallet, don't back it up. How easy on-boarding, all that. Seed phrases that are passive and annoying. You should have options, right? You should be able to onboard your users as gracefully as you can conceive of. And, you know, first crypto is a pain, but we've got solutions for that. You know, why won't the wallets merge these solutions as fast as they deserve to be? And confirmation screens, of course, are obnoxious and tedious. And while they're secure, there's so many of them that they can lead to user fatigue. And even if the users are looking at them, they're basically unreadable because, you know, you're trying to confirm something on a Turing complete computer. We cannot anticipate everything that you've got. We just can't. So how do we leverage this big decentralized ecosystem, all of your creativity in this room, and make something that's secure and usable and scalable so that we can all make it together and so that we can just solve this? So how do we do it? Well, I'm going to propose that delegation is a really powerful thing in the hands of a user. If you do delegation right, you don't grant any authority by default. You have a nice, peaceful, safe place to start. You've got a wallet that doesn't do anything. It doesn't risk your funds. It's conservative, but you're safe. But with human-readable messengers, you can have machine-enforcible authorities that themselves can be delegated, allowing for large networks of transitive extensibility of the system. To facilitate this, you might have seen in the last couple of months we released an EIP. It's in the draft stage. You're welcome to peek it and help improve it. It's our Wallet Permissions API. It's a method by which we propose to suggest users log into websites with a series of machine-enforcible permissions that are human-readable too. And so we're increasingly making that mask a place where it grants no authority by default, keeps users perfectly safe, but gives them the power to grant authority as they see fit. The API looks something like this. You've got an RPC method called Request Permissions, and the parameters as an object, or you request the functions you want access to, which each has a configuration option. Those options can include limitations, self-imposed, maybe the allowance that you need, the duration. Really, the sky's the limit in terms of the option that we might extend here. So this is really just the beginning of a standard. So what Wallet Permissions are we interested in adding? Why are we pursuing this? What do we think we can really add? Because we've been doing a lot of interviews with daffodils. We're not just doing this in a box. So what are the most useful ones? Well, people want privacy. You don't want to ask users to switch the network every time they log in. It would make a lot of sense to make that part of the login flow. A lot of apps use a signature when they first start, but also why not delegate a key? Give permission to do signatures on the user's behalf. Decryption, the ability to establish an intent and encrypt a channel within a DAF, that would be the beginning of truly private DAFs. We could have token management become decentralized rather than each wallet having a centralized repository where it tells you what tokens are legitimate. You could opt into whatever kind of authority for that. You perceive spending limits, obviously. And what else? What do we think is maybe the single most important permission and the thing that I'm really excited to share with you guys today, the thing we think closes the loop, the thing we just renamed five minutes before this thing because we got a new traffic, thanks, Christian. The permission to add permissions, which we call metamask snaps. This is a metamask plugin system about five minutes ago. Snaps is awesome, right? Is it a little side work? Yeah. Okay. Thank you. So, what is it? Oh, I made two slides of it. I like it so much. What's the concept? What's the concept? It's a script that you can suggest someone adds to their wallet. It's JavaScript. It's a script that can ask for permissions in the same format that a DAF can. This script gets no other authorities except for what the user explicitly consents to. And this is made possible by the great work at Oracle on their secure ECMASKET project, which allows us to basically evaluate with very explicit endowments. There's obviously caveats. Security is an ongoing process. It's never perfect. So, we're going to have strong user cautions, especially early on into the system, but we think that this is the kind of path that we believe is very right to pursue. And the plugins can then provide APIs to every website that user visits. Whoa. Yeah. That's what puts the loop. So, here's the IP 2255 for the next generation. That's the wallet permissions. Now, one of the wallet permissions you can request, it's this kind of weird namespace thing where you say you want a wallet plugin and then there's a domain stream. In this case, I made a plasma.e. Let's say that plasma.e is a pointer to my ifs file, which is a plugin bundle. We'll learn a little bit about that in a minute. Now, when the user sees that, they get a confirmation, just like a normal login stream, but one of the permissions would be the permission to connect to this new protocol. You know, Uniswap.e wants to talk to Unipig.e. You know, and it wants to, and then it would also have its own permission too. I kind of edited this on the web. So, it would maybe want to show custom assets, connect to the network, you know, and whatever else. I'd have to talk to their protocol devs about exactly what would be their least authority required. So, what are a few possibilities we're thinking about for these plugins? We think that new asset types are finally in the hands of the developers. We think new token standards. We're really excited to see subscriptions. We want to see, yeah, new kinds of collectibles, more secure tokens that actually keep you safer. Yeah, credit lines. You may want to put your CDPs in there. Like, why not let your users decide, you know, one of my favorite Reddit comments ever said, MetaMask, the internet is an RBG. MetaMask is your inventory. So, how do we just plug this to your inventory? Just put what you want in it. And bring it on cryptography. We're adding an experimental API that's been in EIP for about six months now, this GetAppKey proposal. So, within your plugin context, you can get a private key that only your domain has access to. And that means you don't have to ask us to merge your encryption or signing method. You get to decide, you get to define your own cryptography type. If you need a new elliptic curve, if you need a ZK snark, a start, whatever you need, you build a script that defines just that signing type and you get to expose an API to the websites the user visits so that they can now sign using that type. And you'll be able to show custom confirmations as well. This makes Layer 2 suddenly feasible of writing the normal wallet. There's a lot of great teams doing security audits as a service, but where's their channel to currently show that? Why not let the wallet... Now our job is just to extend the API surface that lets them be useful. So we say, okay, our API is the permission to warn you about a dangerous contract. Now you can ask for the permission to warn a user about a dangerous contract. That's the pull request. You're no longer saying, hey, could you lock your users into my service and pull in all my dependencies while you're at it? No. You ask the user if you can just warn them about addresses they're sending to. You don't get to see anything else. Your code is securely isolated. We don't have to merge pull requests anymore, and people get to be safer because they're permissionlessly getting warned by a whole network of auditors. Potentially you can charge for these plugins too. We are excited to support new protocols. We actually have an examples folder we're going to show you in a little bit. There's an IDFS example. It was like 10 lines. You'll be able to make custom confirmations. The current beta build that we have just uses alert and confirm, but we are going to let them be pretty eventually too. And new account types. There's really an endless number of account types. Had we figured out the last one, the account types rule them all, or maybe even account types deserve to be extensible. One of the coolest things about the GnosisSafe is it supports add-ons itself. So why not make a plugin that accepts plugins, perhaps? And, of course, you're getting fewer confirmations because when you delegate some capabilities to a script, you can potentially delegate things that you would normally be repetitively confirming and so there's just opportunities for reducing user confirmation. Okay, so then what do you want to see? Is there anything that I didn't say there? In use cases, is anybody like, my thing? Finally, I don't have to build a wallet. Am I covering up? Yeah, you have them? No, okay, that's fine. You don't have to share. Free money? What's that? Free money. Free money? You can make a free money plugin. We have a sample plugin that's just a memory app. Yeah, we'll show you how to make free money in just a minute. Oh yeah, here's a screenshot. We have a very simple MVP right now. Here's an example of a contract audit plugin. We whipped this up in an hour this morning. So it's incredibly easy for us to add new features that then are just surface area for the ecosystem to extend on. This also allows for kind of new onboarding, those confirmations that we use to onboard people. They can also be used as onboarding links. So we kind of have an idea that in the future, if you want to onboard somebody to crypto, there could be a single link and it could incorporate both the redirection to get onboarded with the wallet, but also the configuration of the dependencies that your application needs in the wallet, right? So if your pointer sale requires a certain state channel, why not just give a person a single link? They suddenly have a wallet. The only thing in their wallet is your stores redemption frequent chopper points, but that's the only thing they care about. So what are they getting into crypto for it? But your product, right? This is about what you're building. It's always just been an honor for you. And wait, what was that last one? We can make it essential. We can build this. This is all JavaScript. We could make this a single-page thing. We could do a burner equivalent of this and gradually progress it. And I know there's someone calling for that. It's kind of a bandwidth thing for us. We're kind of, you know, obviously. So the way we approach this is iterative. We added this permission system. We're pretty happy about it, but it's a mere RPC. RPCs are pretty coarse, but they will get us started. The plugin system uses the RPC permission system to allow users to request permission and then pass those permissions onto scripts. And from here, we basically want to know what API surface unleashes your projects the most. I gave a lot of examples, and some of those are accounted for. Some of those APIs we're making, we're going to show you some docs in a second. Do you have one? Do you just come to mind? Yeah, I'm curious about books. So how is it that we actually put our plugin and do we actually need to have a modified user experience beyond just confirmation screening? So initially, we should probably do a Q&A a little bit later, but initially we're looking at very discreet, deliberate changes to the user experience where we're still controlling it but we're like permitting parts of it longer term as there are more secure options available for extending the user interface in a safe way. We're open to exploring that, but I think a very gradual iterative approach is the one we're looking at. It's already a pretty big leap. Can the plugin also change the UI and branding or is it like not yet? I mean, not yet, but that's like the kind of conversation we can now have. We can say, would you be interested in the API to rebrand and take your commission? You're like, well, we are going to need dinner at some point, but we can talk. Now we've elevated the EIP conversation from like, is your specific protocol part of the wallet and all wallets not have to integrate it to you can now define your component and you can just define the surface area where you need to expose your neighbor and that can be the politic. Just a quick question around, so in theory, do we like purchase full plugins so there's like a little store? We've been considering that. We are pre-revenue less like pretty much every wallet is. It's possible that a curation of a store or something like that could be an option there. But this is the beginning of the developer beta. We're not selling or walling this at all yet. So yeah, we've got a lot to cover and I do want to help you guys build a little bit on time, but I'm hoping that we have a majority of the workshop for you guys to actually try it out in a period for questions. So I'd like to thank some of the early teams that we gave, we got some feedback from, we used our research, some teams even pulled out some early prototypes. So now to talk a little bit about what a Hello World plugin looks like, I'd like to welcome you to the stage, Mr. Eric Mars. Now, so for my first trick, let's make this area up here just a little bit more intimate. We have two seats over here, two seats over here, one seat over here, please move forward. Come, come. So this is the first stage, as it works, it is. But if you happen to have internet and you scan that QR code, it will take you to the page where you can download things to actually start building something. Yeah, yeah, yeah, that will take you to the weekend, it's got everything. You can basically scan that and move through the line. Right, yes, because we're dropping the videos and all sorts of stuff. Yes. But anyway, I'm going to have to drop this mic because I need both of my hands. So when everyone has finished moving up, if they want to, go. I'm going to say that that's good enough. There's like two seats up here, there's a seat here, there's like two more seats here if you want to come sit. Is that sort of visible to people? Is it looking good? No. No. More. Better. Can you go to the QR code page? QR code page again? Sure. Did you get the QR code? Yes. Also, do we have the local thing? If you'd like, I do. Actually, no. I'm going to do that. Well, yeah. Well, everything will be uploaded and available later for one of you guys have. After his presentation, we'll even post it locally for anybody can check out on the internet. Okay, so, there are, first of all, we just now made public the two relevant repositories for this. I'm going to talk about what a plugin is under the hood for the devs in the room so you can take this away and start building with it. We have a fork of the MetaMask extension that supports the plugin system. It is MetaMask plugin beta. We also have a command line utility called MMPlugin that you can use to build, configure, watch for file changes, serve them locally for testing, for local development. We have on the MetaMask plugin beta repository, a wiki that should contain everything you need to get started. So, as far as the MetaMask extension is concerned, a plugin is two things. One is a package.json file following the conventions established by NPM which should be super familiar to most of you. And second is a source file bundle. And we made the tool MMPlugin as I said to help you get started with that. And on the wiki, we also talk about the plugin API which is the API that the extension exposes to the plugin context. As Dan mentioned, we take the plugin bundle, we load it into the extension, and execute it inside of a SES container. That container doesn't get any sort of global by default. So, we inject some stuff into it by default at the moment such as the Fetch API, XML, HTTP request, and so on. We are also injecting this global wallet object which basically contains most of the methods that MetaMask uses internally to construct our user interface. And also a bunch of provider methods. So, you can think of it as a super set of the Ethereum provider. And we're still changing stuff and we're thinking about like, we're definitely going to add methods. We may also remove some methods as in flux, but at the moment a plugin can request basically any method that we use internally except for some super critical key management stuff that nobody should ever be able to request. A plugin can request that as a permission to use for whatever it is it's trying to do. And for my next trick, I'm going to show you how to get started with developing MetaMask plugins or SNAPs if that rebrand sticks. And so, we made a tool, MM plugin. So, all I've done here is I've created a folder for my project. I'm going into the world. And we're just going to call MM plugin in it. And so, the first thing it's going to do is it's just going to walk you through the usual NPM in it workflow to create the basic package.json. So, we're just going to click through this. Hello plugins, entry point, no test, no repo. All of us off. Great. And so, we're going to go ahead and accept that. And now, once it's gone through the regular NPM in it, then we add some more stuff that MetaMask uses to identify that it is a plugin and how to load it and so on. And so, we're just going to use the defaults here, but I'll just show you what it looks like. So, we define the local server port, like where we'll host it locally for development, an output directory, and the initial permissions that the plugin is going to request upon being involved. And we're just going to run except that. And then, it did a bunch of stuff, but all it really did was it just wrote the files that we'll need to work. And inside this disc folder, we have the bundle itself. We wrote these files with, like, the most sort of minimal Hello World plugin you might want as a framework for you to get started with and also build it. And we can start by taking a look at the package.json. And you'll see that it looks just like a regular package.json, except for this Web3 wallet property here. It contains a bundle property, which tells MetaMask where the bundle lives. So you have the local, which just says, like, where is the bundle relative to the project route, and then the URL, which is where it will be hosted. And if this were for production, that would be, like, the URL of where you are hosting the plugin bundle online. And we hope to support DNS and other things after that, but for now it's just HTTP. And the initial permissions, that's just, as I said, those permissions that it will request when it's installed. And so now I'm going to call watch, so we can rebuild on change and serve. So we can ask. Okay. Here, refresh. Ah, it's the front-end hour of our plugin. And inside the project directory, it's just built an index.html file just so you have a user interface as you can work with and get a feel for, like, what it will actually look like in practice. And so in my extension here, I have the plugin version of MetaMask loaded. I'm just going to make sure that my state is clear. Usually you should not have to do that, but we have those buttons just in case for development purposes. And then I'm just going to go ahead and connect. And that will initiate this request. And this request here is the DAP saying, hey MetaMask, can I talk to this plugin and also install it if it's not already installed? So this is the DAP asking permission to use the plugin. And we're going to go ahead and say yes. And now this request, so we're still working on exactly what this is going to look like. But this request is the plugin, which we just now installed, saying, hey, can I, the plugin, get the permission to show alerts on the user's page? And as Dan mentioned, currently we're just using the browser defaults for alert and confirm, but we're going to eventually, we want to allow plugin developers to build their own sort of custom confirmation screens. So say that you have some interaction. You build a plugin for your DAP. The DAP calls the method in the plugin and you want to display a custom confirmation screen that's initiated from inside MetaMask. You'll be able to do that eventually. That's the plan. But we'll submit that. And this plugin, being very simple, it has a hello method, so we're going to send the hello method. And that super tiny tag says, hello local host. And the big deal... Did anyone from the page came from MetaMask? It came from MetaMask, yes. So because it uses the alert method that we've defined inside MetaMask, which is the permission it asked for when it was installed, and that's where the notification came from. And so the big deal here is that now we've effectively extended the MetaMask in-page provider with an RPC method that belongs to a plugin running trustlessly inside MetaMask in an assess container. And so if we look under the hood here of what's going on, we can start with the index.html. So this was the webpage we were just looking for, our front-end as it were. It has the buttons and stuff. And the first thing I want to bring your attention to is this connect function here. So this follows the EIP 2255 API that Dan showed earlier in his slides. And so this is again the DAB asking for permissions to talk to the plugin. And so the method is wallet request permissions. And the permission is this plugin origin string that we construct here. And so basically what that is, it just takes this permission and namespace prefix and then the plugins origin string and just tax it on and just joins them together. And that becomes a permission identifying the plugin. And then we have the send handler here which again just uses the in-page provider to send a message to MetaMask. But now the method, we use plugin origin as the method which tells MetaMask, hey, I want to talk to the plugin that's identified by this string. And inside here we send an object that can take whatever shape the plugin developer wants it to take. But we just use the same RPC request object format. And there's one. And the method is low. And if we look at the plugin source code, it is 10 lines, and we see that it defines a single method called hello and it sends back hello whatever origin it came from. And the origin here, that's the origin of the DAB that sent the request. And so to just go over what we have going on here, we have this, as I mentioned, the global wallet object which is the API that MetaMask exposes to the plugin. And this register RPC message handler is what you use as a plugin developer to effectively extend the MetaMask in-page provider API. And so that takes an origin string which is the string of the requesting context like the DAB's origin and then a request object that can be whatever shape you want. It doesn't even have to be an object, it could be a string, it could be whatever. By convention, an RPC would be its object. And it just says hello origin string is what it returns and if it doesn't get a method that it recognizes, it throws an error. And so we can very simply alter this and since we're at the account 5, we'll save that and we'll write and it's rebuilt and we'll go back to the in-page. And now because I rebuilt the plugin, we're just going to do the connect flow again and reinstall it and now if we send a low, we get Konichiwa, local host instead. Wait and see what these examples can do. And before I do that, was there a question in the back? What happens when the remote bundle gets changed if you update your app? So we will have some well-defined way of handling updates to plugins. We have yet to define what that's going to look like at the moment since we haven't defined it yet since nothing is in production yet. But there will be a way for plugins to essentially issue updates to themselves, like let users know that they're updated and we'll also provide a way for Mike to say because the plugins can persist their state also and we'll also expose a way for updating without erasing its local state inside the user's extension. But for now, every time you update, you just reinstall it and it wipes everything for the time. Ben, mobile too or just desktop? So how this is going to work with mobile is we absolutely want it to work with mobile. But how are we going to accomplish that? The beta is on desktop. The beta is on desktop. This works on desktop. No pressure. You're right to ask. We want to go there. Ask Bruno. Can the plugin itself be an Angular app? Probably. The thing is, you try and tell us what errors you get when you try to build. We'll talk about that in a second because what the build script does, it will pull in all of your dependencies when you build and we run them through browser file currently. So there are some types of issues that arise when your dependencies are being too clever with JavaScript globals or when they do dumb stuff that they should've been and throws errors. Yeah. Oh, not at all. You're asking about desktop. Yeah, the front end. I was going to ask about desktop application. Yeah, it's not a desktop application. It's a browser extension. This is my question. Can I use this plugin in a desktop application? Eventually, something. We would have to go to a native layer. It's not the feature we're introducing here. Yeah. But any event, thank you for your question. And here for the examples, there are a couple. We have a number of them. We're constantly adding to them. Hello plugin here is the one you get when you run MM plugin init. And the first one I want to show you is this recipient address auditor, which is just basically, we've added an internal API method that allows you, the plugin developer, to tell MetaMask what is an unsafe or a safe address. And so if we look at the package.json here, the initial permissions requested is new unapproved transaction. So that's an event inside of MetaMask that's fired when a new transaction is created that the user has to approve. And then this new address audit is a way for the plugin to modify that screen. And so here we've created this mock audit API, which it looks at whether the final hex character of the recipient address is a letter and then from there it determines if it's safe or unsafe. And here, and so what this plugin looks like is we say we create a listener for a new unapproved transaction. And whenever a transaction appears, we call this add address audit method and it will indicate in the send screen if this particular plugin thinks that the recipient is safe or unsafe or perhaps unknown if the plugin doesn't have an opinion. So now we can add all sorts of smart, like contract security, recipient security plugins with this API. The second example is custom tokens or free money. Yeah, whoever has that question, pay attention. So here, our only permission is this wallet manage assets method. And if we look at this source, we define our own free money token here that we call asset. And this one lives in memory, so it won't be very, it won't make you rich for very long, but we can imagine that it's some ERC interface that's unknown to MetaMask, but that you the plugin developer know about. And so we define this object that tells MetaMask some basic stuff, like presumably if it's an asset it has some sort of symbol, a balance, an identifier, maybe an image, maybe some decimals. And then we have an RPC message handler. So from the in-page, the user can get the balance of this custom token. It can mint more of them and it can burn them. And then here in this update UI function, it basically keeps track of like what is the status of this asset. So imagine like if it's actually on chain, you could query the chain somehow, you could actually send a request to MetaMask to like read from the blockchain to see what your asset is doing, and then you can update it using this wallet.send method. So here, this is actually the plugin sending an RPC request from inside MetaMask to MetaMask in order that it should update the assets. And that asset will be displayed like in the token list or in the asset list inside MetaMask. And finally, one cool thing you can also do is add new forms of cryptography to MetaMask, which previously was hard, but now is very easy as you will see. This plugin has confirmed as a permission just for like UX purposes for the demo. But if we look at the index here, we import this BLS12381 library and we use the wallet.get app key that Dan mentioned. So app keys is something we've been researching internally for some time, and we essentially, we get a private key, we treat the app key as a private key, we call the getPublicKey method of this BLS library, and now suddenly we can sign arbitrary data and do all the usual key pair stuff with this app key and this new public key that we created. And if you think that's cool, we have Tom from Starkware here who is actually doing something useful with this. Yes, we all know this. Hi everybody. Very cool. Thank you so much. You're welcome. Okay, so just a quick intro. My name is Tom Brand. I'm a protocol research and product manager at Starkware, a company based in Israel and we're a development and productization of zero-knowledge proofs, basically Stark's, our first product, which is also here announced today on the main stage, is a very two-skillability solution to enable self-custody trading, which hopefully will be live and main in January together with our partners, the Versify, which was key things a month ago. And what we're going to show you today is basically a nice, we'll get into a second. Basically it's a very nice variation of BLS signer, which allows us to give the users the ability to sign on our specific elliptic curve parameters. I will give a bit in front of it. So, zero-knowledge proofs, in order to have efficient proving, you have to tweak a bit the curve parameters of a normal ECPC. If you sign over the SECPY 256, which is the normal curve in Ethereum, Bitcoin becomes very inefficient. So you have to fix specific parameters in order to have an efficient option. But then it gets very hard to use MetaMask, for example. So with this plug-in system or SNAP system, what it does do is very easily create a plug-in, which we'll show in a second, that allows users to use MetaMask with the derived private key to sign over our specific elliptic curve. So I'll try to show. Please tell me if you don't hear me or don't see anything. So, I'll just start first with the plug-in, then I can go a little bit over the code. So, should you see it? Is the text big enough? Okay. Make it bigger? Okay, sure. Slightly bigger. How is that? So good. Okay, great. So, just to remind what we're doing, so we're building... Okay. So, we are here in the plug-in directory. We have everything we need. We just build it, and then we can start it. Basically, now we have it here. So this is like some kind of nice UI. Basically, this will be in the client of the exchange. You want it to look like that. It will be just a simple client of the exchange which will enable us to connect to MetaMask and sign on orders which we want to submit to the exchange. So, same way that we did before, we're connecting to installing the plug-in and then allowing it to conditions that we're asking for. I hope not our plug-in to make it slow, but maybe it is. And once we have it, we can just get the public key. And just to make sure you understand, this is the public key based on our elliptic curve, which was derived from the seed MetaMask, with the exact same method of get up key. Right? And after we get the public key, we can sign any message we want, specifically an order message, which says, I want to buy, maybe we don't sell it and be in debt one, right? So I want to sell die and receive ease, and this is the account that they have off-chain. I won't get into it. This is like the order I did. And then we get a prompt. So do you really want to sign this message and the parameters that we have? In one sense, I basically received the seed. Okay? So I can go over some of the codes in one? Yeah, you can. Where's this BLS key backed up? There's not BLS, it's a simple ECDSA. Sorry, where's the key backed up? As a plug-in developer, are you responsible for... No, the key is inside the MetaMask, and I also called, what? Yes. Good question. Okay, great. So first of all, we can look at just what we have here. So again, we have only two codes. One is get account, which just give you the public key, one is the sign message. And the nice thing about the way MetaMask did it, and they don't pay me, is that... Really, I can show you in the... So we previously had our own module for signing overall. We're currently using only the elliptic module that MetaMask is using. And once we had it, we only needed to import it here, and it all gets bundled together in the bundled JavaScript. And then whatever you have already, you can just incorporate it into the plug-in, and you don't need to do anything new. So once we have our signatures, all we need to do is get the public key, I'll show you in a second, and you just get it from our own crypto library. And same with the sign. Once you want to sign the message, you just... I don't mind, but you just get the message you want to sign, and you call our own module. Okay, great. What else do you want to see? That's probably pretty good. Okay, maybe just... I don't know what... Is there any questions? Yeah. So you're like off-skating, like start, start with your plug-in, so that, like, adapts up, doesn't actually have to deal with it. So this has nothing to do with the proofs. We want to allow the user to sign a slightly different signature scheme. Right? So this is our way to do whatever we want with the elliptic care, like changing the care that we sign over, but in a very simple way. So it took us literally a couple of hours to do this. Maybe just the design of the HTML was pretty hard, but other than that... It was pretty exact. Did you have to change... So you said you had a lot of the stronger script already written. Did you have to change anything to make it run under your desk? Nothing. Okay. What modules are you using? What modules are you doing things with, like the browser file, like the net-native library at last? I get to you. So you're asking about whether we expose any native node modules? Right. There are no... I don't think you're using any node-native modules, right? Because we don't inject any ambient authority from the node environment. A browser file, I guess, does provide some, but it will work here, because they're only getting loaded at run time, so there's no FS that you can access at the end of time. Well, the crypto is an example. Oh, right. So a browser file inserts a crypto library, and so it would, I guess, get a bundle in here. If we use the crypto library, it will provide. Right, right. So the way browser file works, if you require crypto, it's going to provide it. And, yeah, and at the moment, I don't know if Eric made it perfectly clear. Our goal is to provide zero ambient authority for right now, for convenience. We do have some APIs that we're just kind of leaving in for the sake of convenience, because mocking the entire fetch library behind our permission system is a little bit tedious, because it's a very complicated API. But, yeah, that's where we're headed towards. Andy Gilles? Okay, thank you. This is awesome. I have a lot of plugin ideas that I would want to build today. And I'm sure there are companies that have a lot of plugins they would post bounties for. Yeah. So, you know, right now with the remix plugin system, there's no forum or community to coordinate the creation of the plugin. It's all a getter and someone posts in. That's fine. But I would like to see the best and the most needed plugins put forward and worked on immediately. And so, if the answer is, like, no, that community doesn't exist, I'm willing to put forward the framework to create it with your input, because I want to see, like, some new plugins. Yeah. Awesome. Just to recap that for anyone who didn't hear, because I thought it was really wonderful, it was a call to community action and organizing. For the people on the video, but, yeah, let's get a forum or let's get a community going where we list the plugins that would be most beneficial. Right now, we've got the kind of plugin repository. We also started a key-base team channel called Metamask Plugin. Zoom. I think within S. One of them is a Fisher, probably, by the time I said they're online. So we'll figure that out. I think it's on the wiki if you're on the repo. But yeah, I agree. We should get those. We should get bounties on them. Because things like a stark signer, that's a thing where one person makes it, every dot can use it. And those accounts are portable between dApps. I have a question about the free-money example that Eric showed where you were listing that sort of criteria that typically users now do manually to add a token. Right. So does that actually, could that, like, replace that process so that theoretically, a developer, let's say you're doing some better transactions and you want to use a token, and then you can kind of add that token, does that understand that correctly? Yeah. The question is whether the API we're exposing for managing assets could replace the manual process of users adding tokens. That's totally the point. The NSDEM on here actually had it. Well, the EIP747 hasn't gotten real popular with y'all, but it already does better suggest the API to add a token. So you can do that today. But this is the way that a whole plugin can do it. So if you've got, like, not just one plugin, but you've got, you're a directory or something, and also most of those APIs like that, that is like a proposal, right? Basically, all these APIs are EIP, draft stage, like, we're trying to get to you as early as we can so we can get feedback and not feel hurt if we change the quality of the APIs for this. Okay. Yeah. Yeah. As a plugin, can you get access to, like, the Mono? No. As a plugin, you do not get access to the Mono. What you get is you get the app key proposal that we're using. The idea came to, it was from a Remco from Xerox Protocol. It was a very simple and elegant solution, I thought. We take your current account. For each account, we take its private key combined with the plugin's domain. So it's the most secure identifier we have of it, hopefully in the NS name or something. We hash those together. It's a generated new private key that is exposed to that plugin. So your plugin has a private key that is deterministically generated from the user's seed in a way that only your plugin has access to. And that's why, you know, the Get App Keys proposal had some kind of a critique when we first posted it because, oh, these keys aren't portable between sites. But by plugins, they absolutely are. So now, a single plugin can represent a single signing strategy and every account can have any number of key types associated with it. Yeah. One thing I'll call the back question is, if the plugin idea is going to be deterministic based off of the script of the plugin, then you won't be carrying that key to upgrades. Sorry, sorry. He's thinking that it's based on the source. What does he think? So the key is not based on the source code of the plugin. Okay. Right now, it's based on the origin string, which still introduces a problem if you host it somewhere else. Which is why we would like to support EMS and then hopefully it can just be hosted at the same place and you can just point it elsewhere. Right, yeah. Yeah. And that lets us, like, these plugins could be updated by now or something like you could imagine a very, very secure resilient process for updating them, which is something we're envious of because the Chrome extension store doesn't give us that. And they give us very coarse permissions that we have to request. Yeah. You'll never have to ask for the ability to rewrite everything out of sight to expose an API using this system. The other question I have is are you going to be converting the EPRC plugin support into the plugin given that now tokens should all become plugins? You know, there's definitely a thing that we toy with now that we've been playing with this is, bit by bit, we can move our architecture into the plugin system and we get this great kind of code isolation for free. It's funny because it's kind of a great counterpart to the work that Erin is doing about, where we are procedurally sandboxing all of our dependencies using the exact same agoric secure atmosphere system. So yeah, I think it's a really cool opportunity for modularity and really tight security between our own infrastructure, but yeah it's just kind of internal housekeeping. With that, yeah, for example, yeah, yeah, and for example, yeah, not just tokens, but like almost everything that we do. I don't want to go too deep so the user prompt was just an alert, like an old-school browser alert, is there going to be any so we've said it a few times, just to reiterate, Pedro is concerned that we're just exposing the browser alert, no, that's just the MVP. We actually have an opportunity to let you render what's the original notification you want, which seems like a pretty big opportunity. There have been a number of different proposals from different wallets, how to let dApps propose a custom notifications and a lot of basically the problem with all of them to me, the thing that has given me apprehension about every proposal that I've seen, is they all end up pointing at some central repository and they're just like, they're like, they're like decentralized magic, like, yeah, once it's a DCR it's not a problem or something. Here we're saying, no, very explicitly, there is there's going to be a mechanism for each plugin to moderate and manage its own way. You can have a different governance protocol for each confirmation screen, you can have a different confirmation screen for each contract. Those are, that's the kind of conversation that we can have now that we can say what is the amount of granularity we want over these confirmation screens? What would be most empowered dApps to feel coherent to use it? Oh, yeah, yeah, I wanted to just wrap this up because this is a, this is a, we're coming up on one of our two hours and our dream was that we could actually get some of you like, because I bet a number of you here have like a library like StarCore had where it's like, this thing you might be able to just drop in. So I'm going to just give you a few caveats, like current issues that you might want to know when you're using the system. Oh, yeah, so you're going to, you might learn through the build system. You might get some errors that are strange or new to you. These are usually things about your dependencies tried to mutate the prototype of string or tried to change function or tried to mess with what promised it. And that's what Eric meant when he said, too clever, okay? Your dependencies are doing things that are downright dangerous and they're basically the same thing an attacker would do. It's going to fail. It's going to fail in the build system. It's going to fail when you try to load it into metamask. So this is an opportunity for you to get off of insecure dependencies and to push security updates to your dependencies. Which is a cool side benefit of this. If you use our plugin system, you're making your dependencies more secure. Sweet, right? We're also going to add big, fast security warnings, okay? None of these things are perfect. We're not claiming that SES is perfect. It's not a panacea, but we have this fire for it to be. And this is the kind of thing that the community should rally around. This is something worthy of a mall locked out. The community should get around formally verifying tools like SES that let us all benefit from greatly increased security. Okay? This is a huge, huge community resource. We're going to give a lot to you, excellent. This has been very rough. Sorry for the alerts and all that. We really just wanted to get it into your hands as soon as possible. We're also going to try to incorporate much better signals about what's a reputable plugin. We know that one of the reasons our users don't get phished very often is that the Chrome Store has reviews and user accounts. We would like to extend similar opportunities, but perhaps in a more decentralized manner. Obviously, we're going to put above boundaries and we're going to have a security audit and all sorts of stuff. You can't audit this enough. This is about the scariest thing you could do, but if we do it right, it just could be the coolest. And then, of course, we're going to improve the performance. You've probably noticed the pop-ups are already so unmasked. This did make it a little bit worse. We're going to be tooling and we're going to be improving and tweaking and all that kind of stuff. And then, of course, we're going to allow plugins to specify settings pages because we don't know what you need, but you do. You can basically already hack it together because your plugin gets the requesting origin string, so you can basically just say my domain is my setting string and give it special methods, which is kind of a cool side benefit of getting to define your own permissions. And, yeah, adding a plugin, update mechanism will be coming. That's something definitely required before production. And before production, we're going to be locking down all global Ambient Authority plugins. We'll get nothing that they didn't explicitly ask for from users. We're trying to make the most safe environment we can. And then we've got to just refine those APIs. Beyond all that, it's just about getting you guys to communicate rally around the plugins that are the most effective and the APIs that enable those most effective plugins. And those can be the things that we really kind of focus on as a community and standards type of group of people. So that is all we have to say to get you kind of started. We hope this was a big push on the slide. Yeah, thank you. If your internet is bad, you can connect to the Wi-Fi MetaMask right now and point your browser at metamask.local and you've got all the docs and a built-up metamask that supports plugins and the MM plugin built so we're like really paranoid about how this would happen. Yeah, other than that, just scan this. If you do have the internet, you'll go to the GitHub Wiki. The repo is open now. It's got a video that's very similar to the presentation we just made so that people outside of this room can be learning this right now. Yeah, so let's spend the rest of the time. Yeah, that was exactly one hour. Maybe like five minutes or something. Maybe just like a few questions if you want us to just start building. We've actually got a whole team full of metamask members here ready to answer your questions. Actually, Oma, are you a researcher who would maybe like to say a couple words before you get started? Yeah. Someone in the back there said that they have lots of ideas on what plugins they want to build. We want to listen to you on what plugins you would want to build and why. So we are all the teams here. We've come and talked to us. We want to hear you so that you can find out what the most impactful use cases are and what we should be building first to test the system out. If you don't have an idea of what plugin you might want to build but you can think of what is missing in the wallet, experience for users. We also want to hear from you on what in your opinion is missing from the wallet so that we can think of a potential solution for that and not as a plugin or not. And the third thing is if you can think of challenges or implications that you might see or foresee coming into the system we also want to hear your thoughts and your ideas and your questions. So, a lot. But we are here for the next hour and we'll be there for the rest of the conference. Please come talk to us when we are here. What's that? Subscriptions. Subscriptions like two events or subscriptions like automated payments. You should group up with this plugin team over here and we're going to have a little hackathon for the next hour. I bet you they can drop one in. The custom asset thing you can just hack around right now when you click on it you get to just open a page. Hopefully that's enough to show a group of content. Cool. If you want to shout out plugins that you're hoping to whip up you can help connect people. That seems like a good use of my time. Any other plugins that people maybe think they might want to try to do over the next hour? No. Okay. You don't have to go. You can do some questions. April. The wrong room. Yeah. It's like a generated interface so you can call any function like a universal interface that lets you connect to a contract. So I guess the question would be where do we put it? So you want a place where you can customize within the master interface. So what you can do right now is you can hack our custom asset thing. The custom asset thing is very flexible. You basically just show something in our token list you get an icon and a name and it links to something. So you can just show a contract there and you can link to a universal interface. So I think there's an opportunity to build out an output if there are other events that will help that. I guess like, I think it's bringing it right so I think I'll just let it roll. We're going to move the address out and you just go to the right. Yeah, you can probably go back there. Thanks.