Maybe: Add API for declaring/requesting a specific protocol

[danfinlay]

Today, we have exposed two methods for plugins to provide APIs, but when dapps or other plugins want those methods, they have to reference the providing plugin by origin, which is a very concrete form of version control.

In some cases, multiple plugins may choose to compete to best implement an equivalent protocol API, and a user might choose one over another.

For example, in the short term, the MetaMask team might implement some proof of concept plugins, but we'd ideally have a graceful transition path to allow dapps and plugins that build on it to move to a more "official" implementation as it becomes available.

A proposed way of doing this would be two part, but would involve effectively defining a parameterized version of our API-providing/requesting methods, where the new parameter is a protocol-identifier string, which is not unique between plugins, but that the user may be expected to choose between in the case of a conflict.

Example:

wallet.registerRpcHandlerForProtocol('protocol://ipfs', usualRpcHandlerFunc)

I'm not sure this idea has any real-world applicability, but the idea has come to me a few times in a few contexts, and so I'm recording it here for discussion and recording any ongoing justifications for this idea.

[danfinlay]

One important use case is ensuring that accounts managed by these app keys could be migrated in case that a plugin domain is no longer maintained.

One permission could be to manage accounts on behalf of a former domain, like a sort of import.

Another possible permission is requesting the right to manage keys for a given bip39 path. Known paths could easily be represented as their target protocols: btc, etc...