Motivation
As the oldest Dapp-login system, the MetaMask team has been through several cycles of innovation on various levels of the Ethereum platform, and have basically felt like we (and any single team) can't really keep up.
- New Tokens
- New Token Standards
- New Networks
- New L2 Scaling Strategies
- New Contract Account Types
- New Name Systems
- New Security Enhancement Strategies
- New kinds of cryptography, for both scaling and privacy
We have tended to get lots of requests for direct integrations, and ultimately we have often been put in a position where either we are choosing a winner (like the ERC-20 standard), at the cost of improved innovation (like the ERC-777 token standard), or we are merely frustrating everyone equally.
Early on we tried to keep our scope as small as possible, by avoiding "choosing winners", not even showing tokens in the wallet for quite a while, if you remember, but eventually we caved to what the users wanted, and they wanted to see more of their account at a glance in their wallet.
Networks would ask us to get in our network list, which we are forced to either expand indefinitely or curate carefully, putting us in an uncomfortable political position.
New tokens would ask to be added to our token-detection registry, putting an audit burden on our team that is dangerous and uncompensated, and so we suggested EIP 747 as a way to let users to delegate some of the wallet's functionality to the sites they trust.
This was nice, but it was too small. Dapp developers don't want to list just one token, they want to define new kinds of tokens, on new kinds of networks, that are stored in new ways, with new cryptography. Ethereum attracts developers who see the power of a turing-complete platform, and that's what they deserve.
The plugin system was conceived as an answer to the question: What is the simplest extensible wallet architecture? One that ends the need to develop a new wallet for every new network, or contract account, or asset type that comes along?
This was an early sketch, drawn the summer of 2018, showing how an "add network API" could turn MetaMask into an extensible system. The concept of "Network" here has since evolved into what we are calling a "plugin".
In particular, we are interested in general-purpose permissions that can enable the most use cases with the most obviously safe implementations, and always with a very human-readable description, because that description is how the permission will be represented to an end-user.
Some example plugin-centric APIs that we are likely to be interested in:
- The ability to mark a displayed address as safe or dangerous, with a warning or endorsement. (For security plugins)
- The ability to display additional assets in the token list, with the ability to render a custom view when selecting that asset. (For new token standards, layer 2 networks, and potentially other networks entirely)
- The ability to provide an additional account and handle transactions for that account. (For contract account support)
- The ability to interpret a name as a particular address or resource type. (for alternative name system plugins)
Also, still coming is the ability for a plugin to provide its own API to sites that the user visits.
One of the primary uses of this beta program is for you to figure out what the most important permissions you would need to make a wallet work with your use cases. We're going to be looking for the highest-impact APIs to expose, and we expect managing those, integrating them into our design, and reviewing them for security to become an important part of our work.