Recovery key screen during sign-in in EX shows unexpected "Create a new recovery key" option

[pmaier1]

At least on EXI (tested with 1.7.5), the key reset flow shows an unexpected "Create a new recovery key" option. This option doesn't give you the means to create a new recovery key (which isn't even possible at this point). Instead it just starts the regular key reset flow which is misleading and a duplication of the "Can't confirm" on the previous screen.

All in all, I think this is a leftover from previous designs and should be removed. Please check for Android as well.

@mxandreas @manuroe @stefanceriu @bmarty

[stefanceriu]

Talked this over some more with Patrick starting here https://matrix.to/#/!kCCQTCfnABLKGGvQjo:matrix.org/$my1fMW-QsNxYJOuJcKnVpFft_fWFXv0kdjzuUxR7nQM?via=matrix.org&via=element.io&via=one.ems.host

We agree that this reset flow still makes sense for the "recovery out of sync" situation but that the copy is misleading. What we really want is to reuse the same as the identity verification screen i.e. replace Create a new recovery key with Can't confirm

[jmartinesp]

Kamino cloned this issue to element-hq/element-x-android

[bmarty]

To create a new recovery key, the user as to go back and click on "Can't confirm", I do not think this is a good idea to add another entry point to reset on this screen.

We previously had instruction to reset the key using another client but it has been remove in this PR: https://github.com/element-hq/element-x-android/pull/3355

[pmaier1]

To create a new recovery key, the user as to go back and click on "Can't confirm", I do not think this is a good idea to add another entry point to reset on this screen.

Exactly. That's why I've created this ticket. Android apparently already behaves correctly. Thanks for checking!

[pmaier1]

There is another case where the user has successfully set up the app but some of the (crypto) secrets are missing. In this case the user will see a banner like this

In this case there is no way to get to the "Confirm your identity" screen that has "Can't confirm". For this reason we need an entry point to identity reset here. I suggest to call it "Doesn't work?" since this can cover multiple cases

• The user does not have a recovery key
• The user has a recovery key but it's wrong
• The user has a recovery key but the secret storage on the server is broken / doesn't have all secrets needed

In all the above cases the user has to reset.

So, all in all

• The recovery key screen during sign-in should not show an entry point to identity reset
• The recovery key screen for "chat backup is out of sync" should show an entry point ("Doesn't work?") to identity reset

[mxandreas]

The recovery key screen during sign-in should not show an entry point to identity reset

Since this is already done in Android, I created a ticket for iOS: https://github.com/element-hq/element-x-ios/issues/3357 cc @stefanceriu .

The recovery key screen for "chat backup is out of sync" should show an entry point ("Doesn't work?") to identity reset

I will sync with @americanrefugee on the exact design of it. One thing is to have the button there so in principle user has the ability to reset. A totally different thing is to actually make it clear for the user why is it there and if/why they need to do it, etc.

@bmarty @stefanceriu - are there any technical limitations/nuances for distinguishing if the recovery key entry screen pops up as part of the nominal device verification flow or during this special flow when user needs to "confirm" the recovery key.

[stefanceriu]

are there any technical limitations/nuances for distinguishing

not as far as I'm aware, it should be pretty straight forwad

[bmarty]

Yes, same, there should not be any problem to distinguish cases.

[mxandreas]

We had a quick session with Aaron - he suggested that instead of adding any extra buttons to the "enter recovery key" screen, we would add the "Can't confirm" button (title TBC) right into the initial banner. I like this approach much more, as it is consistent with the nominal device verification flow and we do not have multiple different versions of the same screen.

Now, the major challenge is that it is still very hard for user to know when they need to press the "Can't confirm" button and do the reset, because:

1. Even if something went wrong with/in this device, they may have another device which is verified and works fine. So, the reset is not the only way out, right?
2. If they enter the key and it fails, are we able to distinguish between a) the key was correct and but fixing the issue failed regardless vs. b) the key was incorrect? If not, then it is even more confusing because the user might actually know the correct key but made some copy-paste error and needs to reset identity as a result.

@pmaier1 Do you know answers to the questions above or I should take this up with the Crypto team? I think if we're just going to rename the button something like "Can't confirm or did not work", then I do no think it makes any difference for the user - they are just as confused and would not know if reset is the right thing to do or not.

[pmaier1]

we would add the "Can't confirm" button (title TBC) right into the initial banner. I like this approach much more, as it is consistent with the nominal device verification flow and we do not have multiple different versions of the same screen.

Well, the user probably doesn't know that they "Can't confirm" before trying, right? Might be a little weird in terms of user flow. Not sure why consistency with the other flow is important here. The reason why you have this flow is a different one (normal verification vs. "emergency" to get the secrets). That's just an opinion, though.

Even if something went wrong with/in this device, they may have another device which is verified and works fine. So, the reset is not the only way out, right?

If they have managed to get past the initial device setup (by verifying with another device) and still something is wrong (secrets are missing), then there are two ways forward

1. Enter recovery key, get missing secrets from secret storage
2. If that doesn't work, you need to reset

If they enter the key and it fails, are we able to distinguish between a) the key was correct and but fixing the issue failed regardless vs. b) the key was incorrect? If not, then it is even more confusing because the user might actually know the correct key but made some copy-paste error and needs to reset identity as a result.

We can certainly detect whether a key was correct or not. But I don't think it makes a difference to the user. If the key was correct but the secret storage was broken and you don't get the secrets therefore, that's the same outcome as if you've entered the wrong key. There is only one way forward and that is the reset.

[mxandreas]

Might be a little weird in terms of user flow. Not sure why consistency with the other flow is important here.

IMO, it is primarily the sake of clarity of not having the same screen with a number of different options / buttons depending on the context, but I agree that it is not the most important factor in here.

But I don't think it makes a difference to the user.

It makes a big difference in guiding the user about what is going on. If we can confirm that recovery key is correct, but did not fix the issue, we can guide the user in a straightforward way to do the reset. If the recovery key is not correct, then we might say to the user to double check - perhaps they did not copy the key properly, took a wrong one, etc. Yes, eventually it might happen that they might not find the correct key, but there is a lot less ambiguity in navigating the situation.

[pmaier1]

It makes a big difference in guiding the user about what is going on

Well, of course. That's why I'm saying you should first try to find out whether you can "confirm" or not. If the key isn't correct, the app should obviously tell you about it so that you can try again. Still, in any case, if you don't have the correct recovery key (or no recovery key at all) or you have it but it still doesn't work, you need to reset.

So I would expect in most cases that people would try it first, then either succeed or fail and need to reset. You would only directly go to "can't confirm" from the banner if you knew that the app will ask you for your recovery key and you know for sure that you don't have it.

[BillCarsonFr]

FWIW we have some metrics about incomplete states https://posthog.element.io/dashboard/1200

[mxandreas]

During yesterdays session with @americanrefugee @BillCarsonFr and @richvdh we concluded that the flow is structurally correct (e.g. we can't think of a better one). After the session we made some copy enhancements with Aaron - to be more literal/explicit what the options are. Might be worth reviewing.

The main challenge still around the reset as such - because there is a lot of room between worst and best case scenario (e.g. what the user will lose in terms of message history); but it is impossible for clarify that for the user.

[mxandreas]

We have now concluded on the design of the flow:

• iOS
• Android

@stefanceriu Made a comment that the language here is "key storage" (and not "chat backup" which is what is currently used in the Settings of the app). I can confirm that "key storage" is what we eventually want to get to; and there is an item on the roadmap for update the Settings. I will have a look if I can get it done by just changing translations in Localazy; but I would not block this task because of that.

Let me know if there is still any comments or questions from the engineering side.

[mxandreas]

Since this ticket was originally raised just for the excessive button on iOS, I am closing it because the latter has been done.

For adjusting the copy / design of the entire key storage out of sync flow a new ticket has been created.