MetaMask / metamask-extension

:globe_with_meridians: :electric_plug: The MetaMask browser extension enables browsing Ethereum blockchain enabled websites
https://metamask.io
Other
12k stars 4.91k forks source link

Ability to have "profiles" with their own wallets + RPCs defined #67

Closed danfinlay closed 8 years ago

danfinlay commented 8 years ago

These would be signed in on a per-domain basis, so this builds on #12

kumavis commented 8 years ago

sounds a little bit like feature bloat, whats the primary use case / pain point this resolves?

danfinlay commented 8 years ago

Was requested by @nickdodson saying it would be nice in development.

I agree there might be a simpler solution to the same pain.

On Mar 23, 2016, at 6:48 AM, kumavis notifications@github.com wrote:

sounds a little bit like feature bloat, whats the primary use case / pain point this resolves?

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub

kumavis commented 8 years ago

@SilentCicero can you expand on this pain point

danfinlay commented 8 years ago

I've started coming around to this perspective, and I'll express why I'm starting to support it.

First of all, each site you visit may or may not be an ether Dapp. And each ether Dapp may use a different provider. And you might prefer to use a different account for each one. And since it's confusing to have the same account numbers/names between different blockchains, it is helpful if different blockchains are divided into different profiles, or as I think of them, vaults.

A vault has a configured provider. The providers could be Main Net, Test Net, and Custom RPC. The main/test providers could be opaquely serving our own RPC, or the etherscan provider, etc. The semantic configuration for those should be what the user sees.

The first change is integrating the config migrator (per #80). From there we'll migrate the existing config/wallet into a single instance within the vaults collection. Including config and wallet as part of a vault. Vaults should have a deterministically derived unique identifier, so they can be referenced by other data structures even through a drop/restore.

The other big config value would be a domains hash. This would map a given domain to a config object. This domain-config would dictate which vault to use for this site, which account from that vault to use for that site, and whether the account should be "unlocked" (visible) to that site. Those are just what I can imagine to start.

Anyways, this feature depends on having good UX, so I'm going to try sketching some up to get a better sense of how this could stay pleasant to users.

danfinlay commented 8 years ago

This starts to also include #63 and our whole "maybe we should log into an account first" idea.

img_4519

danfinlay commented 8 years ago

Ok I've gotten enough push-back on this to bump it to the next milestone (at least).

danfinlay commented 8 years ago

Reasons to push this back:

If we hold off, we can save some repeated effort.

kumavis commented 8 years ago

currently looks like this:

image

danfinlay commented 8 years ago

I think this feature is covered by items in other issues now, and no longer represents a path we're taking.

In particular, I think #328 plus #714 captures the spirit of this.