[Multi-Account] Account overview + individual wallet UI

rachelhamlin commented 5 years ago

User Story

As a user, I want to see both an overview of all my wallets and a detailed view of each specific wallet, so that I can manage my multiple accounts confidently.

Description

Type: Feature

Summary:

Implementation plan for multi-account from Core UI POV is as follows:

@yenda to build the Account explorer and Wallet UI for just one account.
Underlying multi-account creation work in progress in parallel from status-go.
Add account flows built either for real or dummy accounts, depending on progress of item 2.

Notes

What changes must be implemented by design to help clarify the purpose of the user's 2 default accounts (chat and 'main')?
How are we handling backwards compatibility with user's existing chat account?

Expected behavior

The following screens are pixel perfect for one account:

Short tapping on one of the wallets from the overview screen loads the wallet (bottom row).
Long tapping on one of the wallets from the overview screen pops up the send/receive bottom card (top row, second screen).
Tx history is shown per wallet but not for the overview.
Add account button opens bottom card with options, but options are not yet active.

guylouis commented 5 years ago

How are we handling backwards compatibility with user's existing chat account?

When discussing this subjects a couple of weeks ago, we came to the conclusion that given the current number of Status users, we shouldn't even work on specific (complex) protocol to insure backwards compatibility. It will mean that with a given mnemonic, the user will lose his chats and he will have a new '3 words' when he upgrades to Status v1. However, He will not lose his funds which will be in his default 'fund' account.

hesterbruikman commented 5 years ago

A note on the above designs: we still need to define how to show the current 'backup seedphrase' warning which currently comes up as soon as you have received assets in your wallet. Will put some more thought into this and follow up here asap.

yenda commented 5 years ago

@guylouis who did you discuss that with? Because there is a mountain of useless legacy and backward compatibility code that we could get rid of if that is the case, we shouldn't even bother migrating to the partitionned discover topic for instance.

@cammellos @mandrigin

guylouis commented 5 years ago

@yenda just to be sure we are talking about the same 'backwards capability' I was referring to the fact that from Status v1 the whisper key will be m/43'/60'/1581'/0'/0' and not any more m/44'/60'/0'/0/0 like today. So for a given mnemonic (unless we build a specific backward compatibility mechanism) the user will have a new '3 words', chat 'identity' and history.

@gravityblast has been leading these discussions, Andrea, if I am not summing up our situation correctly please correct me. If there is 'backward compatibility' work to be performed because we introduce from Status v1 a new whisper path, then we need to add it to our tasks to be done before v1 because it's not for now.

We mostly discussed that during keycard calls with some focus on this from @jarradh @corpetty

There were some links about this issue at the beginning of this post https://discuss.status.im/t/musings-on-key-management-aka-whisper-decoupling/1034

rachelhamlin commented 5 years ago

Okay, thanks @guylouis, that makes sense.

yenda commented 5 years ago

@guylouis yes that is what I mean if the whisper key is changed the communication protocol backward compatibility is useless because the identity would have changed

mandrigin commented 5 years ago

cc @oskarth

StatusWrike commented 5 years ago

➤ Rachel Hamlin commented:

Guy-Louis Grau just to get my head straight, why is it renamed to 'proposal and discussion'?

StatusWrike commented 5 years ago

➤ Guy-Louis Grau commented:

this is a mistake :) I just write that on the wrong line :( sorry, and correcting right now

status-im / status-mobile