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

[danfinlay]

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

[kumavis]

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

[danfinlay]

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

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

• Dan

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]

@SilentCicero can you expand on this pain point

[danfinlay]

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]

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

[danfinlay]

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

[danfinlay]

Reasons to push this back:

• Does not use proxy identities
• Does not use future BIP paths (per net, per dapp)

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

[kumavis]

currently looks like this:

[danfinlay]

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.