Refine notion of plugin state per account

[danfinlay]

There are some use cases where the notion of account is a bit broken under the current alpha plugin system.

A few things that indicate the issue

• When logging into a site that needs a plugin, the user selects one account to log in with, and can select a different account to connect to the snap with.
• the plugin account becomes the source of its appkey, regardless of the account connected to a connected dapp.
• The plugin's provided assets currently show up in the token list regardless of the current selected account.
• A plugin can be connected with one account, and then be contacted by a dapp with access to another account, and in turn a plugin can leak account information via its API.

Possible Solutions

Approach one: Plugin per account

We initialize an instance of a plugin per account, so when logging into a site that needs this plugin, they can share keys and permissions.

Problem: This prevents plugins like ipfs from sharing a cache between sites.

Approach two: Multiple scripts per plugin

Much like the WebExtension standard has contentscript and background scripts (one per site, one per browser), we might want to introduce a similar concept:

• per_account script, for managing resources per account.
• per_wallet, for managing global state.

Possibly also per_site? This is a very early phase concept, and needs a lot of honing, so opening the issue so others can contribute to it before it takes further form.

These scripts would be able to intercommunicate, since they're all in the background, we could probably allow them to pass objects directly, or maybe just proxy/membrane representations of each others' objects. Maybe only hardened objects?

Also, the asset management API probably needs to be per-account.

Approach Three: Plugins can initiate from any account

The sendTransaction method doesn't need to enforce the from field, as the user is already going to be prompted with the transaction, so perhaps a simple solution is to stop enforcing the from/eth_accounts validation, and allow plugins to propose transactions/signatures (which are then presented to the user) from any of the user's addresses.

[danfinlay]

Related to our persona EIP.

[danfinlay]

New proposal: https://docs.google.com/document/d/1vrxRwR5oD2QWtBuDln0UoFgmbLdW685_XDzvbFLgUGE/edit#

[danfinlay]

Defining Personas