Design Views for Multiple Keychains

[2-am-zzz]

This is a design-centric version of #328

We are planning to refactor a core piece of MetaMask, allowing it to support multiple key signing types, and this has some pretty big UX implications, so we want designer input to keep it as simple and user-friendly as possible.

Right now MetaMask is entirely based around the idea of these "HD-Wallets", where a 12-word seed phrase is where all the accounts come from.

This makes the account list fairly simple, since we have a list of accounts, and you can only add them, and they are always added in the same order, like this:

In the future, there are other types of account we want to support:

• Import Geth account .json files
• Simple key pairs (maybe allowing vanity account generation, like 0xbad0dab0...)
• uPort accounts
• Hardware wallets, like Trezor or Ledger

We had an idea for what this might look like in the account list, where vault types might include sections, like this:

However, we are open to other solutions.

Key Terms

Before resuming, here are some terms we should clarify. We haven't really picked solid words, so feel free to propose the words we use as part of the design.

Keychain

A way of grouping accounts together. A keychain can be a simple set of key pairs, or an HD wallet series of wallets, or a uPort identity.

Right now, MetaMask only has one Keychain, a seed word keychain, but the purpose of this design is to allow multiple keychains.

Vault

The encrypted storage of MetaMask.

In the past, the Keychain has been the same thing as the vault.

Going forwards, we're thinking we'll encrypt all the keychains together, so they are all unlocked at once, so a user doesn't have to manage multiple passwords for different keychains, but that is a design decision, and up for discussion.

Wallet / Account / Key Pair

These terms are basically interchangable. They represent a single Ethereum identity.

This can be a simple key-pair, or an identity contract, but to MetaMask, it represents a discrete, selectable identity that is injected into a web dapp as a public address.

Long term, one of these might be a uPort persona, so a uPort Keychain manages many uPort persona accounts, but that's beyond our current scope.

Our current thinking

There are several views that might be affected, so let's step through them one by one.

First Time Screen

Now that we are supporting several wallet types, we are now discussing what the optimal first-time user flow would be like. Since we are no longer constricted to just one wallet, should we make a certain type of wallet the 'default' wallet type for first-time users, or give them the option up-front to decide on their first wallet type?

Another option is to have a single Keychain be the default, but include a small Advanced option, that opens up Keychain selection.

Vault Creation Screen

This screen may become mandatory on first-time use, because the password is used to encrypt all the Keychains. Otherwise, it may remain identical.

Keychain Creation Screen

Since we would not be offering many keychain types, we might not want to automatically show a seed phrase after the password screen.

The options we have come up with so far (not exhaustive) are:

• Defaulting to a specific wallet for first-time users
• Giving users a dropdown list of supported keychain choices
• A hybrid, where users have an advanced option to select a specific keychain, but otherwise will use a default keychain.

Once this keychain has been selected, there are other requirements in mind:

• Redirect users to a new view after keychain selection. This can either be through a new tab, window, or within the popup (or some other method).
  • Creating accounts in a new tab has the advantage that it is much easier for different keychains to render custom wallet creation views.
  • If creating accounts in a new tab, we still should indicate that MetaMask received the new account. Maybe via a notification.

Keychain Restore Screen

With multiple Keychains in mind, we have to consider what the account restoration should look like. Instead of requesting the seed phrase right away, users will be required to select a wallet type to restore.

Keychains may require different information to restore.

Account List Screen

As we discussed above, this screen is going to have to be different if there are different account types within MetaMask.

It is worth noting that a single account type, like an HD seed-phrase wallet, may have many accounts under it. For this reason we are calling these account-types "Keychains", because they can have many keys.

This is why I initially suggested having sectioned Keychains, but I understand the + signs also become a little confusing then.

We had one thought that maybe instead of a + on the Keychain header, we have a settings gear icon, which would take the user to a custom view for that Keychain, maybe in a new tab.

This would make some sense since each keychain may have its own way of generating and managing keys, and a simple web view is the most flexible interface we could offer a Keychain developer.

You would not have to design the view for every type of keychain, but it would be nice to design basic views for HD wallets (the current type), and normal keypairs with geth wallet importing. I think the uPort team will want to design their own views.

This view may be split up into multiple views, but the goals for replacing it would be:

• Allow adding new Keychains
• Allow Keychains to dictate if/how to add new accounts with them.
• Allow keychains to define custome interfaces for account creation.

Conclusion

None of our suggested designs are hard requirements, they're just our ideas so far on the issue. Feel free to borrow or discard whatever ideas you'd like, to make the best UX possible.

Our goal is to simply give MetaMask a way forward for the many types of accounts users may choose to use in the future, making it easier for a user to choose their account type, and making it easier for us to add new types in the future.

[eshon]

Creating a special view for Keychains sounds weird for a Chrome plugin. I think it'd be easier to just label each account with the keychain or type.

Upon hitting the plus sign, you get a form asking what type of account you'd like to create or import with the various options. One option could be a new account within the HD 1 seed tree, another could be a new seed tree, then geth, etc.

[danfinlay]

I like how flat & simple that makes it. It also keeps a sort of chronological order to the account list.

The "new account" view would carry more of the weight of complexity, but it's not actually that much more.

Nice idea, fresh take, thank you!

[eshon]

I hope chronological means Most Recently Used.

Maaaybe clicking a tag would animate right to a list (with back button) of all accounts with the same tag as well, but just a nice to have. The alternative to that is adding "Sort by... (recent, tag, creation date, amount...)" to the above screen somewhere, or having both of these features eventually, but this would be for users with lots of accounts to manage so lower priority.

[2-am-zzz]

#722

This is also in the works, thinking of integrating search as well, will try to implement sorting alongside.

[VladTod]

Sorry for the delay on this guys, some other things came up...
Over the weekend i did a bit of brainstorming on this, and some research.
I do have one thing i would like to address. And this is the Vault (first layer of a Matryoshka).
As far as i understood, the vault is were users will keep their keychains, and keychains are were they will keep the wallets. This means that users will be able to use the wallets and keychains only with the Vault password?
If the above is true, than i think we are just adding another layer to it that i'm not sure it's going to be much use. I don't see many use cases for having more keychains in a vault. I can see why having more wallets in a keychain is good though.

I also recommend that if we move forward with the idea of Vault, than we need to change the name, i asked a few of the people here in the office what a vault is related to blockchain, and 90% of them referenced the Xapo Vault, that is a cold storage, physical vault. And i don't think its the case just in the ro-ro office.

[2-am-zzz]

Just to clarify that we're on the same wavelength, keychains are defined by their wallet implementation, so a uPort keychain is very distinct from say, a geth keychain. Wallets are defined as individual addresses / instances of these different implementations.

This then warrants a discussion on what kind of wording we want to settle on so that users don't get confused. The hierarchy now is that a vault has many keychains (implementations), where each keychain has several wallets (instances).

On the topic of vaults, would you have any suggestions off the top of your head @VladTod? Maybe the word 'Safe'?

[eshon]

• Vaults have nothing to do with blockchains - in Metamask its means a browser vault. A safe place in the browser where you store your account stuff.
• Vlad's right about that the term 'Vault' sometimes implies longer term storage - this is true in the Coinbase UI as well.
• Maybe 'Account Library' is another possible name, but 'Vault' implies more assurances of safety - its password-encrypted local storage in Metamask right? 'Locker'? I feel ilke 'Vault' is still ok though. Metamask as a browser wallet is a hot or mostly warm account tool, and there's no indication of 'cold' with 'Vault'. Another cute option could be 'Den', as in a fox's den or 'Cubbyhole' but there might have to be a cave with a fox tail coming out of it somewhere to explain those.
• Instead of 'Wallet' I thought Metamask was going with 'Account' (since Wallet is confusing - a wallet can hold multiple credit cards? Maybe that's just my confusion with 'Wallet', as it is used in the Ethereum community sometimes to mean Account.)
• Vaults hold Ethereum Accounts. Keychains are an Account Type ("implementation" says the developer up there). If you create an Ethereum Account via geth it will be a little different from creating an Ethereum Account via uPort or Lightwallet/Metamask.
• How are they different? Geth creates a single account public-private keypair with a special kind of format when you try to read the key files. A user could roll their own public-private keypair with a different format to those keyfiles. uPort Accounts are...? Linked to some service that pays for gas for you? Not sure about uPort. Metamask (like Lightwallet) creates an HD Account Type which has a 12 word seed that produces a tree of Accounts - each Account in this tree is unique and has different amounts of money but the same 12 word seed can reproduce all the keys to this tree of Accounts. So the Accounts are linked to each other via this 12 word seed, but they will be separate Accounts.
• It gets hairy when a user has multiple 12 word seed trees in their Metamask vault, so if using tags it might need to be like HD 1, HD 2, HD 3... but regardless, it just means they have more Accounts and more Account Types.

[kumavis]

'Vault' implies more assurances of safety - its password-encrypted local storage in Metamask right?

yes

Instead of 'Wallet' I thought Metamask was going with 'Account'

yes

Keychains

keychains are collections of accounts. Keychains have different types.

• One type of Keychain is for loose individual keys you can add and remove any time.
• One type of Keychain is deterministic, you cant import a loose key but you can recover all of them with a seed phrase ( this is the only type we currently have )
• Another type of keychain might be "remote" as in managed by an external key service or by a phone or something.
• Another account type might generate a fresh address for every dapp, and only fill it with eth before you try to use.

maybe this ^ thought model (Keychains > Accounts) is not the best, but it matches in that the different types of keychains have different methods for creating/importing/backing up keys

Vaults are just encrypted local storage

[danfinlay]

Good points, Vlad. We've definitely noticed the word vault sucks for this;

I had a thought, what if instead of vault, we just call it the MetaMask password?

The #1 tricky part making me want to support key rings is because we have this notion of Hd wallets and I haven't come up with another way to allow a user to generate related accounts.

But maybe I'm over thinking it. By all means, forget the word keychain, think of it as wallet types, and show us a design for that, it may meet all our design needs.

I do want us to address what will happen to users with a seed word that generates several accounts they want to restore, or if they want to add another account under a seed word.

The seed words have been quite an educational burden, I'm also open to finding ways of making them a less mandatory concept

• Dan

On Oct 24, 2016, at 5:15 AM, VladTod [email protected] wrote:

Sorry for the delay on this guys, some other things came up...
Over the weekend i did a bit of brainstorming on this, and some research.
I do have one thing i would like to address. And this is the Vault (first layer of a Matryoshka).
As far as i understood, the vault is were users will keep their keychains, and keychains is were they will keep the wallets. This means that users will be able to use the wallets and keychains only with the Vault password?
If the above is true, than i think we are just adding another layer to it that i'm not sure it's going to be much use. I don't see many use cases for having more keychains in a vault. I can see why having more wallets in a keychain is good though.

I also recommend that if we move forward with the idea of Vault, than we need to change the name, i asked a few of the people here in the office what a vault is related to blockchain. And 90% of them referenced the Xapo Vault, that is a cold storage, physical vault. And i don't think its the case just in the ro-ro office.

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

[danfinlay]

Sorry, that last post I wrote earlier in the weekend, and it only sent now! Some of those ideas were covered by others (Thanks Eva!)

To help move the discussion past specific words, into the conceptual realm, I've made a diagram of the relationship of these things:

The wording I presented originally is all up for grabs. I actually really like thematic wording, because it breaks people out of thinking "This must be a special blockchain word", and establishes it as its own thing, so Den instead of Vault might actually be easier for people to understand, if we just say "Enter the password for your Den". By being associated with a password, I think it may do the job.

@VladTod I think the confusion is that you thought the Vault was the new thing, but really it's these "account types", and the only reason we're introducing that is because we want to allow people to sign transactions with a variety of methods, like their phone, or a hardware wallet, or importing a wallet from somewhere else.

This could've just been types of accounts in a list, except for the HD wallet type, and kindof uPort, and some hardware wallets, where that "type" contains multiple accounts, and it can generate more accounts that it owns, so we need a way of showing the user that association, and a way of managing it.

You don't have to think through the uPort persona generation yet, we just need an open ended way for these "account types" to define what it means to create a new account within them.

My first proposal was just "open a new tab when hitting new account", and let those accounts provide whatever UI they want.

There may be better solutions, but that's about how open ended we probably want our solution long-term, allowing some degree of UI customization.

This task is not about the individual UIs (although covering the UX of a simple single account, or the HD seed account type, would be good first ones, to prove out the concept).

Sorry this is a lot to take in, maybe we should schedule a call sometime to talk through it all, but hopefully this helps!

@eshon Thanks for all the input, please keep it coming, this feature still needs quite a bit of realization.

[VladTod]

Hello guys, and thanks for all the answers :)
I asked Eva, Yesterday to have a call with me, because i had some things that still weren't clear and wanted to go over some ux issues. So we had what i think a very productive call.

Your are right Dan, the thing that stood in my way was this "new" thing, called a Vault. I thought it was a new feature that it didn't make much sense to me, since we already had this feature, so i thought i was missing something :)

Will get to work now, will keep you posted on the progress.

[danfinlay]

we had what i think a very productive call.
will keep you posted on the progress.

Can't wait!

[VladTod]

Hello Team :)
So after some thought and research i came down to this design.
Screen 1 - First comers.
I think we can safely assume that the big majority of people that will see the first screen are people that don't have a back-up DEN. So it makes sense to me to prioritise a new DEN creation.

Screen 2 - Accounts
I think in order to make it easy for the user to understand, navigate and keep track of all the accounts and account types, we need to allow them to Edit the name of the account.
So the add | edit will take you to a page were you can add a new account to that keycain. Having it like so will help users add a new account without trying to figure out to what keychain they have to connect it to.

Screen 3 - Add Keychain
The + sign would be for adding new keychain. And it should have 2 tabs, one for adding new and one for importing. And after selecting type, the second section ( settings ) should come up, depending on what kind of acc it is.

Let me know what you all think. Feedback is crucial :)

[VladTod]

I also remember Kevin mentioned something about adding search and filter. So i tried to "eat" to rabbits at the same time.

[eshon]

I don't think "Add Keychain" is necessary. Just "Add New Account". I don't think in terms of Keychains but in terms of Accounts or Wallets where I have ether. We don't have to teach users about Keychains, just support the different ones they might happen to already have.

"will help users add a new account without trying to figure out to what keychain they have to connect it to"

Do users ever need to connect an existing account to an existing Keychain?

I think instead of the "Add Keychain" screen it should be "Add Account" like this:

After import or create new is clicked, the next screen will change based on what type of keychain is selected, passwords might be needed.

Also @kumavis once said when geth accounts are imported they are mapped to a new account in the default Metamask HD keychain. That's changing now right?

2 minutes later: just realized the Create New button also needs to be disabled if its uPort, Trezor, geth, Simple keypair, etc. Its only enabled if its a HD keychain type.

[VladTod]

Ahoy!
here are the changed screens that we talked about.

This is the version with the import and create as separate tabs.

And here is the version that Eva illustrated above.

This last version is alot cleaner, but the next step for some of them would still similar to Account Details from the first version. So you still get the seed and all that.

I personally think that although the version that Eva did has an extra click, it looks cleaner and easier to use. So i vote for the second version.

[danfinlay]

Thanks, @VladTod!

These look great, there are still some questions that remain.

• What does it look like to add an account to an existing account type, like an HD Key-Tree?
• What does it look like to restore from a seed phrase?
• What does it look like to upload a file for the wallet?

Two other approaches that would be nice to see:

1. What if on your version, the account types are all laid out and visible on screen, and clickng one goes to the detail view that is custom per keyring type?
2. Along similar lines, what if we opened a new tab, like MyEtherWallet does? Could we see what that might look like?

[danfinlay]

Also, @eshon, do you imagine people are able to rename their account types? If not, at what point do we teach what "HD" means, for example?

Also, one "account type" is basically "just a normal account", but it could be imported from Geth, MyEtherWallet, Mist, or a private key. How would we label those?

I think one simple solution is just "reasonable defaults": We auto-nickname things based on how they were initiated. One might be sub-titled geth because it was imported from a geth style account. The second account imported in that style might be nicknamed geth 2, and so forth.

[danfinlay]

Aaron had a very different take on this issue:

As you can see, he had the idea that we could separate the concern of selecting an account from managing the accounts.

Thoughts on that take?

[eshon]

do you imagine people are able to rename their account types? If not, at what point do we teach what "HD" means, for example?

Not sure if this is worthwhile right now, so to start just keep it simple and impose what types makes the most sense to you guys? "HD" or "HD tree" could be in the docs with the info button: "This account type belongs to a family tree of accounts that can all be re-generated using a single 12 word seed." or a better phrasing.

Also, one "account type" is basically "just a normal account", but it could be imported from Geth, MyEtherWallet, Mist, or a private key.

Can you tell if an account has come from MyEtherWallet, Mist, Parity, etc.? If no, then maybe some phrase that means "normal" or "default" makes more sense. If yes, i still like thinking of MEW and Mist as "geth" accounts if they go off of the geth keyfile standard and maybe label the "parity" one separately. My opinion is subject to change.

[Sketch above]

Forces user to think in terms of keychains. I'd rather think in terms of accounts. uPort isn't out yet so I don't know how people will want to think about that one, but it'll probably be a special case in the UI. Not sure they will even have multiple accounts/personas in their Q4 release either because it seems like its about KYC and attestations so seems like TMI to worry about multiple uport personas right now.

[Extra flows based on Account type request]

I can work on sketching some out on Friday, have a deadline for Thursday this week. If that will hold you guys up let me know and I can try to finagle something sooner.

[danfinlay]

Hey look guys, I organized all of our current design proposals into a Quip folder of documents, so we could revise & discuss the individual aspects more easily:

https://quip.com/XXbAOAXPtRe

[danfinlay]

Can you tell if an account has come from MyEtherWallet, Mist, Parity, etc.? If no, then maybe some phrase that means "normal" or "default" makes more sense. If yes, i still like thinking of MEW and Mist as "geth" accounts if they go off of the geth keyfile standard and maybe label the "parity" one separately. My opinion is subject to change.

I guess the smart move for now is just save whatever metadata we have about an account's origin, so we can label it better later on if we come up with better ways. I agree let's skip nicknaming those for now, for simplicity.

[danfinlay]

Forces user to think in terms of keychains. I'd rather think in terms of accounts.

I agree this forces that layer of confusion on top of users who may only have the simplest use cases, which is why I have further developed my add-account button concept, check it out (quip link):

I think we could avoid a lot of complexity on a subsequent page by providing a simple + button default at the bottom of the accounts list, with a split menu to allow more options.

The menu could either have:

• A list of account types
• Two items:
  • Create
  • Import
• A concatenation of the two above, like:
  • Import JSON file
  • Create new HD Key Tree
  • Create uPort Account
  • Sync uPort Account
  • Add Ledger

“+” by itself could be a new HD account in the short term, and long term maybe it will represent a new uPort persona, or maybe it becomes that once they set up uPort, because it had a pre-checked

• Make uPort my default Account Manager

[bdresser]

is there a separate design story for this @danfinlay @cjeria ?

[cjeria]

@bdresser not yet! It's come up several times in conversation and I've even done a few wireframes for this (quite big) feature but obviously something that's been on the backlog for sometime now. I think this ticket is related #605

Would be good to put this one on the (long term) road map? This will have a lot of design implications!