Status-react: [Multi-Account] Migration path for existing users

[rachelhamlin]

Goal

An existing user who installs v1 either 1) on top of an existing build, or; 2) by recovering from their seed phrase, should be offered the option to create a new Whisper ID, but not forced.

Those who create a new key will still be able to access their old account from the login screen, like so:

Open questions

• What is the most seamless way to move user's funds from old wallet to new wallet?
• What is the most seamless way to move user's ENS name from old wallet/Whisper ID to new wallet/Whisper ID?
• How do we distinguish legacy accounts from 'new' accounts? With the legacy badge? With nudges in-app to encourage migration?
• Users who do not create a new account, but instead keep only their old one, will still benefit from the option to manage multiple wallets inside, correct? e.g. I can import my MetaMask wallet to use alongside my existing Status wallet, and Whisper ID.
• For how long do we support old accounts? (This has not yet been discussed)

Stories

The current design explorations (Onboarding > Migration B) are WIP. We need a better understanding of the options for moving a user's funds and ENS name to their new account.

Current idea is to notify the user right after log-in/recovery, like so:

User stories

• As an existing user installing or recovering Status v1, I want to understand the changes, and choose whether or not to create a new account.
• I want to move my wallet funds to this new account, to improve my privacy.
• I want to associate my new Whisper ID, with my existing ENS name. _Will it be transferred to new wallet key? We should potentially notify users again of the privacy sacrifice involved with using ENS._
• I want to easily access my old account, contacts, chats, etc.

---

• As the product team responsible for this work, we want to minimize the amount of screens + logic required for the above (!). :)
• We want to ensure that the ENS migration is handled in the simplest possible way—if it is easier to do so as part of the ENS feature or even in a stand-alone DApp, we should consider it.

Notes

Related user stories
Brand new user installing v1 from scratch

• Onboarding with keycard: user’s wallet is stored on keycard; Whisper ID stored locally.
• Recovering account from outside Status: follows ‘regular’ recovery flow.
• Creating brand new Status account: new wallet key, new Whisper ID.

Existing user installing v1 but setting up keycard

• User downloads new build, chooses keycard onboarding. Must lose old Whisper ID.

Notes from migration strategy call #2, when this plan was decided.

[guylouis]

One question for clarification: any one who imports a mnemonic in status in v1, will be asked if he wants to use it as a legacy or as a new one ?

In any case, legacy account should be prevented to be used with a keycard.

E.G a user downloads a fresh V1, imports a mnemnonic, decides to keep it as a legacy account -> he can't store his key on Keycard

[hesterbruikman]

@guylouis the idea so far was to offer the show the same dialog whether you're unlocking or recovering. You would not get asked if you want to use a recovered account as new or legacy. Instead you're asked if you want to create an additional, new account.

The user will need to know if the account they use is already 'new'.

I see a potential issue with Keycard here that if the user recovers a Keycard account, they will have to create a new account in order to use it. Is that right?

[yenda]

@guylouis @hesterbruikman In order to minimize confusion for new users I would consider only supporting legacy accounts that are already on the device. Recovering with the seed phrase will work as if it is a v1 account and therefore have a different whisper key

[yenda]

Also I think we should consider doing some work at the communication protocol level regarding these migrations.
Saying that topic negotiation is a solved problem as I heard in the dev call is wrong. It will only theoretically reduce bandwidth over time, but since all clients are still going to listen to the discovery topic, it is going to be an easy target for spamming. If someone decides to keep the volume high in discovery topic, clients are going to keep consuming an enormous amount of bandwidth which is more ridiculous for a v1 than breaking compatibility with beta. If they stop at some point, backward compatibility is broken.
Are we going to stamp V1 on a product that most people will find unusable due to very high data usage because too much effort has been put into maintaining backward compatibility instead of iterating on lessons learned during the alpha and beta stages?

[guylouis]

@yenda @hesterbruikman
thanks for the clarifications, that helps! if we don't propose users to use their recovered wallet (they entered the seed) as a legacy, then there is no problem with keycard anywhere.

@hesterbruikman
"I see a potential issue with Keycard here that if the user recovers a Keycard account, they will have to create a new account in order to use it. Is that right?"
-> not an issue, because there are no such users. No one uses keycard in beta.

To wrap-up that would be (to make sure we have covered all cases)

• upgraded v1, user access an existing wallet (no such wallet are keycard based)-> he can keep it on his phone as a legacy, or create a fresh brand new wallet (new seed, and in this latter case he can use keycard with it)
• upgraded or fresh-installed v1, user creates a new wallet (new seed)-> we create a v1 type wallet (of course), he can use Keycard.
• upgraded or fresh-installed v1, user recovers a wallet (enters the seed)-> In any case, we don't create any legacy wallet here. We either (exact user flow to be designed) create a v1 type wallet with the seed the user entered, or propose him to just generate a new seed for him (is it really necessary?). In any, he can use Keycard to manage this wallet.

[errorists]

so, a dumb question but one I just need to ask. Couldn't we release 1.0 as a separate app to the store? So there would still be the legacy one, no longer supported or found in distribution, clearly labeled beta with only legacy accounts inside and a single screen added asking to upgrade. And 1.0 with no support for legacy accounts whatsoever? This way you can keep running both and transfer your stuff on your own, however you like it?

[rachelhamlin]

Also I think we should consider doing some work at the communication protocol level regarding these migrations.
Saying that topic negotiation is a solved problem as I heard in the dev call is wrong. It will only theoretically reduce bandwidth over time, but since all clients are still going to listen to the discovery topic, it is going to be an easy target for spamming. If someone decides to keep the volume high in discovery topic, clients are going to keep consuming an enormous amount of bandwidth which is more ridiculous for a v1 than breaking compatibility with beta. If they stop at some point, backward compatibility is broken.
Are we going to stamp V1 on a product that most people will find unusable due to very high data usage because too much effort has been put into maintaining backward compatibility instead of iterating on lessons learned during the alpha and beta stages?

cc'ing @oskarth in reference to this.

so, a dumb question but one I just need to ask. Couldn't we release 1.0 as a separate app to the store? So there would still be the legacy one, no longer supported or found in distribution, clearly labeled beta with only legacy accounts inside and a single screen added asking to upgrade. And 1.0 with no support for legacy accounts whatsoever? This way you can keep running both and transfer your stuff on your own, however you like it?

@errorists we discussed this and it was shot down, but that was also when we were considering full backwards compatibility and support for multiple Whisper IDs per account. Perhaps it is. Doesn't seem like a great idea from a comms perspective though. We could have people inadvertently routing themselves to the beta version of the app.

[rachelhamlin]

• upgraded or fresh-installed v1, user recovers a wallet (enters the seed)-> In any case, we don't create any legacy wallet here. We either (exact user flow to be designed) create a v1 type wallet with the seed the user entered, or propose him to just generate a new seed for him (is it really necessary?). In any, he can use Keycard to manage this wallet.

Hmm, I don't understand this last case @guylouis. What seed is this user recovering from? Another wallet, e.g. metamask? In which case, sounds right—user recovers a seed from outside Status, that becomes his default wallet, he gets a Whisper ID, and he can use keycard. Correct?

[guylouis]

This last case is the general case where a user wants to enable a new wallet in status by entering a mnemnonic. We actually can't know if this mnemonic was used in the past with one wallet or an other, including status, if we don't ask explicitly to the user.

So in the case described above, the only users we don't serve are those who

• have used status in the past
• don't have their beta status app where they used their wallet any more (because they changed phone for instance)
• would still want to use their wallet as a legacy one (edited: meaning with old whisper ID)

[yenda]

@guylouis what do you mean by would still want to use their wallet as a legacy one, you mean with the old whisper id and associated ethereum account? In that case yes we wouldn't.

[rachelhamlin]

Oh right, good about about not being able to distinguish—user still needs
option to specify if it was a beta account. :/

On Wed, Jun 26, 2019 at 11:09 AM guylouis [e-mail] wrote:

This last case is the general case where a user wants to enable a new
wallet in status by entering a mnemnonic. We actually can't know if this
mnemonic was used in the past with one wallet or an other, including
status, if we don't ask explicitly to the user or don't want to have have
legacy wallets supported on freshly downloaded v1.

So in the case described above, the only users we don't serve are:

• have used status in the past
• don't have their beta status app where they used their wallet any
  more (because they changed phone for instance)
• would still want to use their wallet as a legacy one

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/status-im/status-react/issues/8496?email_source=notifications&email_token=ADWA6Y6JPJ3G3T66G2LSEHLP4M54ZA5CNFSM4H3MG5IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYTBB5Q#issuecomment-505811190,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADWA6Y36BYCABKBSOWSEF7LP4M54ZANCNFSM4H3MG5IA
.

[hesterbruikman]

@yenda If we force upgrading for the recovery flow. Would people still have their original contact list?

I'm not a fan if forcing upgrades altogether. Kind of goes against being censorship resistance and liberty. @guylouis is it an option to explicitly inform people that they will not be able to use Keycard if they don't allow Status to give them a new Whisper ID?

[guylouis]

@guylouis is it an option to explicitly inform people that they will not be able to use Keycard if they don't allow Status to give them a new Whisper ID?

if we allow user to chose to create a 'legacy' type of account from their recovered mnemonic (seems to be one of the main choice we have to do here), then we have to tell them they can't chose keycard to put their wallet. The slight design difficulty is that this question (where do you want to store your wallet ? in phone or keycard ?) is asked quite early in the flow, so we have to see where we ask him about his choice for v1.

The ideal situation would be to design this migration so that the number of 'legacy' users decreases over time. That's why I liked @yenda proposal to force upgrading users who recover a mnemonic :) I mean ideally at some point (in a couple releases), it would be good to not ask every user that recovers a mnemonic if they want to use an old type of whisper key.

[hesterbruikman]

if we allow user to chose to create a 'legacy' type of account from their recovered mnemonic (seems to be one of the main choice we have to do here), then we have to tell them they can't chose keycard to put their wallet. The slight design difficulty is that this question (where do you want to store your wallet ? in phone or keycard ?) is asked quite early in the flow, so we have to see where we ask him about his choice for v1.

As far as I recall we don't have "where do you want to store your wallet" in case of recovery. If the user recovers a wallet stored on Keycard two things can happen.

1. They recover through the _'regular' recovery flow_, upon which the recovered wallet will be stored on the phone
2. They recover through _Keycard recovery flow_. Tap the card to the phone on the onboarding screen, which prompts to unlock, recover, pair. upon which the wallet will remain on Keycard.

If (1) happens, users will get the notification of V1 and option to create a new V1 account, next to their legacy account.
If (2) happens there are two solutions to decide between:

• The user gets notified that their wallet is recovered and they have a new Whisper key.
• The user gets the option to add the new Whisper key or Recover their account on the device (route to 'regular' account recovery). Where they can keep the recovered account as legacy account and add a V1 account next to it.

[rachelhamlin]

The user gets notified that their wallet is recovered and they have a new Whisper key.

Sounds the simpler solution to me, no? I would go with this.

Also in this event:

They recover through the 'regular' recovery flow, upon which the recovered wallet will be stored on the phone

If they later want to add keycard, they can't do so without creating a v1 account. Correct?

[guylouis]

An update on this: after discussion with @dmitryn @vitaliy @hesterbruikman @andmironov , we will enable the following keycard use case for v1: a user importing a mnemonic can put it either on his mobile or his keycard. Just like in onboarding (when he generates a new mnemonic and we ask him where to store it).

[rachelhamlin]

Is @yenda also on the page? Is there a design check-in/hand-off for these flows?

[hesterbruikman]

Will plan a review for next week. Designs haven't evolved in the meantime. Need to review additional requirements, update and mature.

[guylouis]

In the summary I tried to make above (adding numbers here to help)

i. upgraded v1, user access an existing wallet _that's already on the phone_ (no such wallet are keycard based)-> he can keep it on his phone as a legacy, or create a fresh brand new wallet (new seed, and in this latter case he can use keycard with it)
ii. upgraded or fresh-installed v1, user creates a new wallet (new seed)-> we create a v1 type wallet (of course), he can use Keycard.
iii. upgraded or fresh-installed v1, user recovers a wallet (enters the seed)-> In any case, we don't create any legacy wallet here. We either (exact user flow to be designed) create a v1 type wallet with the seed the user entered, or propose him to just generate a new seed for him (is it really necessary?). In any, he can use Keycard to manage this wallet.

It's obviously a bit tough to keep all inline on our understandings there, so if anyone that has some doubts on these could you raise it so that we converge ?

My doubts are:

• for iii. I think we are going in another direction than the one wrote here where we actually let the user use this mnemonic he has entered as a legacy wallet. We will have to ask him because we cannot detect if a mnemonic is a status one or an other. The exception is if the user decides to store the new wallet on a keycard then we can't let him use it as a legacy wallet.

[oskarth]

Why was this closed?

[StatusWrike]

➤ Hester Bruikman commented:

Looks like a Wrike-Unito-GH integration bug. Task was put On Hold in Wrike