-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use recovery keys rather than recovery pass phrases #13825
Use recovery keys rather than recovery pass phrases #13825
Comments
Covers #13766 too |
Questions on the design:
|
Why did you close this, github? |
Also, the option to back up message keys is gone: do we always back up now? |
Another one: we currently have the "keep it safe" and "you're done!" screens after setting up: are these going away? |
My questions:
Some answers:
We still need to give the option. We are not forcing people to back up message keys.
These feel redundant to me? We are trying to simplify rather than have redundant dialogs, imo. Some thoughts:
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
We reverted the PR, so re-opening |
I watched the demo from friday – very nice! However, I’d like to add that when I think about my friends, I’m pretty sure that a lot of non-technical users would be confused by getting displayed a recovery key after they have set a recovery passphrase. Would it maybe be a good idea to a) either replace that recovery key field by a button like “Generate an additional (alternative) recovery key” which then would not show that key before being pressed, Then users would better understand of what that key is about – because currently there is absolutely no context to that key (see below). And the case that the “continue” button is green directly, does not make anybody realize that the recovery key is optional. I’d like to mention this, because I’m sure pretty much none of my non-technical friends understands this (and even the technical ones are partly confused), because they may not have dealt with such things ever before, or just rarely occasionally. It’s very important to make everything as clear as possible in an easy language – especially right at the time of registration. I’m also sure that most friends of mine skipped this dialog back in the time, and then later got/get surprised by not being able to recover encrypted content. And the ones who are able to recover, will have set the recovery passphrase equal to the user password. You really have to take care about people, which don’t care at all – because these people will definitively block others of using Matrix or at least get annoyed. (Believe me, that’s my current problem in our organization.) |
We plan to soonish move this setup later in the process after registration: #13895 |
Place holder issue - more context to follow but in short we want to reduce sign up friction caused by asking a user to provide two passwords.
Current preference is for option B
https://www.figma.com/file/wwqBo5oAFfk8XKmtd2YaIs/Cross-signing?node-id=5050%3A31796
The text was updated successfully, but these errors were encountered: