Closed eliawk closed 7 years ago
Do we need to show the user that we are creating an anonymous keystore?
no, the idea is that this whole keystore complexity remains transparent for the casual user. So in step 1,the use can just play the vid immediately
oK, got it. (3) Do we need to create a new modal with the "continue Anonymous" option or the M44 does the job by clicking on the X button?
Good point. I'd say that we add a third option on M44: so we have "sign in", "sign up" or "continue anonymously"
@jellegerbrandy
I and @jrgarou were discussing it and we think the user may not know what continue anonymously means. We still think that closing the modal is the more natural behavior for the user to continue to navigate without logging in
Cases:
[ ] (1) user on virgin device user arrives on player -->
[x] create anonymous keystore with default password, which gives us an address but no (meteor) user account. At a later point , the user is asked to regiser or log in (for example, when he wants to buy a video, when he visits the profile page, at the end of a video...).
[x] (1a) In case the user creates a new account, we regenerate the keystore, using the same seed as the anonymous keystore, but with the new password (so the eth address remains unchanged and we do not need to transfer any funds);
[ ] (1b) in case the user logs in with an existing account, we continue as in (5).
[x] (2) new users on a device that has (only) an anonymous keystore no action required, the keystore can be unlocked with the default password, and the user continues as in (1)
[x] (3) non-logged user on a device that already has a user keystore this is a special case, in which a previous user has created an acccount, and then logged out. In this case, on landing, we show a modal in which we offer the user a choice to either log in, or continue anonymously.
[x] (4) user arrives and is logged in with the meteor cookie, a corresponding keystore exists at this point the keystore is locked with the users password. This is further discussed in #140
[x] (5) users arrives, is logged in in meteor, but a corresponding keystore is not found in localstorage. This happens when he logs in with an existing meteor account on a new machine, or somethig has gone wrong (because he delted local keystore). In this scenario, the user is asked to fix this situation, by either
[ ] providing the keyphrase
[ ] generating a new wallet.
The modal looks more or less like this: