Introducing Web3 Plugins
What’s behind the fox? It’s you! It always has been, and soon it will be more than ever.
Ethereum has always been about enabling the potential of future innovation. If we knew what it was good for, it would have shipped with all of those features, instead of a virtual machine. And the innovations have kept coming.
State Channels. Plasma Chains. Contract Accounts. Meta-Transactions. Name Systems. Smart contract analysis. Identity systems. Universal Logins. Progressive Security. Bonding curves. DAOs.
Here’s to the BUIDLers, the ones no one can keep up with!
During the last four years, MetaMask has had the privilege of helping a huge community of visionary developers establish footing in a new kind of computing ecosystem: One where users control their own accounts, where accounts control their own funds, and where the speed of innovation is the only gatekeeper.
There’s the problem. While the MetaMask team has long been passionate about permissionless innovation, it wasn’t long before we started feeling the weight of responsibility on our shoulders that comes from building a platform that aspires to meeting the needs of such a diverse and brilliant ecosystem. We enabled the ecosystem, but in many ways we also dictated the pace of innovation. The features we added were becoming a kind of gatekeeping, a bottleneck on innovation. The tokens we listed. The signature schemes we supported. The networks we display by default. We took some initial steps at moving these choices back into users’ hands, but we knew it wasn’t enough. We had to do more.
Permissionless Extension
MetaMask has extended the browser in important ways that bring Ethereum to normal web sites, but that is not the last feature that we need to build the web of tomorrow.
MetaMask itself was first a browser WebExtension, and early on, many users felt the pain of this installation: For MetaMask to work, users are forced to consent to some truly excessive permissions. These aren’t because we demand them, or need them, but because they are the least powerful permissions that allow MetaMask to do what it needs.
Adding extensions to the browser today is a dangerous process, with coarse permissions, and so each new extension has the potential to do enormous harm to its users. Meanwhile, adding functionality is an incredibly powerful pattern, arguably the hallmark of open computing.
Huge and important innovations are happening all around us, from scaling strategies, to new smart contract protocols, and many of these require interacting with a user’s accounts, and running a persistent script on the user’s behalf, either to monitor state, pre-process transactions, or even just to serve up a new peer to peer file transport to different sites with a shared cache.
To serve all of these use cases and more, we’d like to introduce Snaps: The Metamask Plugin System.
A MetaMask plugin is a script loaded over a verified and permissionless protocol like ENS, IPFS, or Swarm. These scripts have zero privilege by default, but will be able to request a variety of powerful wallet APIs from MetaMask, via a new API we call the wallet API.
The wallet API is an extension of the classic ethereum or web3.currentProvider API, but with some extra features designed to facilitate some of our favorite use cases, like layer 2 scaling strategies, and soon more features for contract account support. You can start reading the docs now here.
We deliberately are making our APIs very granular, so that MetaMask plugins never need to ask for large excessive authority, and many will be able to operate with little knowledge of what is going on. For example, a file-sharing plugin doesn’t need to know what page you’re on, just what hash you want to load or set.
Every plugin has the ability to provide its own API to the sites that a user visits, as well as to other plugins, allowing plugins to build on each other, in a sort of decentralized dependency graph. For example, a state channel plugin might rely on a whisper plugin.
It’s all made possible with our EIP 2255 permissions system, so let’s look at some of the permissions that enable some kinds of new kinds of plugins.
Some Plugin Possibilities
Smart Contract Security is a huge issue, both because you can’t be secure enough, and no matter how many layers of checks you add, you always have to ask who watches the watchmen? With an auditAddress plugin API, plugins could add warnings or endorsements of accounts wherever MetaMask displays them.
Decentralized name systems are an exciting opportunity for loading content outside of the traditional certificate authority system, and we don’t want to dictate what name systems a user can subscribe to, and so a resolveName API can allow the addition of new name resolving strategies.
Privacy-centric protocols require unique forms of cryptography, so rather than try to implement every kind of signing algorithm in existence and audit and merge them, we can allow plugins to play this role: The first team that requires a new curve can use our wallet.getAppKey() API to get a unique private key for their domain, generated from the user’s own seed phrase uniquely for the plugin’s origin, which is now treated as the authority for that key type, which can also use our confirm API (which is rough for now, but will eventually support custom confirmations) to get user consent for that type of signature.
Contract accounts unlock limitless potential in Ethereum, but they are also an active subject of innovation, and so rather than commit to a single contract account, we will be able to support any conceivable contract account with a set of account-centric plugin APIs. In addition to allowing new kinds of accounts, by supporting arbitrary contract accounts, MetaMask will be able to onboard users who initially created temporary accounts, burner accounts, and universal-login accounts, and load these accounts directly into the extension with a single permission.
Scaling the blockchain is one of the hardest and most active subjects of research into the entire ecosystem, and at MetaMask, again, we don’t want to choose a single strategy and then try to force everyone to use that for the next few years, so instead, in the Meta-spirit, we worked closely with a number of layer 2 scaling teams, found the features they have in common, and have abstracted them into a suite of plugin APIs that we hope will unlock dapp development to innovate decentralized agreements far off the main chain. These include the getAppKey() method discussed above, as well as a new wallet_manageAssets() proposal.
One large category of contract scalability is for counterfactual assets, or assets that you would have if you submitted a signed message that you hold to the blockchain. For a counterfactual scheme to be useful, the wallet needs to know how to store these messages, how and when to submit them to the blockchain, and how to render them in the user’s wallet. With our wallet_manageAssets() method, anyone can devise a new scheme for minting tokens or collectibles with a simple signed message, and so now we can “instantly” mint assets for each other, and we can avoid going to the blockchain until we actually want to send the asset to someone else.
The New Role of MetaMask
The prefix “meta” means beyond, and by providing this API, we believe MetaMask finally lives up to its name, and becomes a Meta-Wallet, which will no longer be required to approve each new innovation in the wallet field, but instead will focus on implementing APIs that enable second-order innovation, like the APIs above.
Each of these APIs will be resulting in EIP discussions soon, and we hope that the developer community will help us define a set of API surfaces that make the wallet the versatile yet secure platform that we all need to build on each others’ best work.
A Decentralized Standards Body
At Devcon 2, I went on stage and I called for a decentralized standards body. I begged the other web3 wallet developers to come together, rally around a shared test suite, and give developers a platform that is stable across clients. While there was some real passion and interest (shout out to Casey Detrio), ultimately inaction and coordination costs relegated this dream to the space of fantasy.
Well today, building on our permissions and plugin system, I’d like to ask you again, how can we build a decentralized standards body?
What if instead of requiring that every wallet developer stay in lock-step with every method that every app developer wants, instead we just let portions of our shared API be managed by different quorums in the ecosystem, and other developers can rely on those components as they desire? To me, that’s a more decentralized standards system than trying to get a group of otherwise competing wallets to agree on a test suite.
This makes it easy for any plugin author to create their own API for the sites a user visits. These APIs are exposed via the ethereum RPC for now, but we have tooling in progress that will allow plugins to expose arbitrary objects full of promise-returning functions or event listeners as their APIs to websites and other plugins.
How is this Possible?
The isolation of these plugins is made possible by the visionary JavaScript sandboxing coming out of Agoric’s Secure EcmaScript project. Thanks to an ongoing partnership with Agoric, we (as the JavaScript community) are beginning to have the tools to truly build secure distributed systems. As Mark Miller of Agoric likes to say,
If you lower the risk of cooperation, you get a more cooperative society.
If you’re ready to dive in and try it for yourself, please head down to our plugin-beta wiki. For some real-time support you can join team metamask_plugins. There’s lots to read and try out, and we look forward to your feedback and use cases. We made this to really unlock the potential of this ecosystem, so please tell us:
What would you like to make the wallet do?
