Instruct user to open EX app before starting verification

[mxandreas]

When verifying the device with another device, the EX app needs to be open before the verification is started, otherwise the request is lost. This is not ideal, but there is no trivial fix for it. Therefore have chosen to instruct the user to open the app.

On EX side there, there is an extra step between selecting another device as means of verification and actually starting the verification. To keep things currently simple on EW, simply update the copy in this modal:

"Verify your identity to access encrypted messages and prove your identity to others. If you use another mobile device, please open the app there before you proceed."

This has already created confusion, thus important to bring some clarity ASAP.

[t3chguy]

The user could be using any device to verify it, including another session on the same device, so saying "another mobile device" is very confusing

[mxandreas]

Yes, they could. That is why it is says that if you use a mobile device.

[t3chguy]

"another mobile device"? I don't have "another mobile device" I have just the one

[t3chguy]

When verifying the device with another device, the EX app needs to be open before the verification is started, otherwise the request is lost. This is not ideal, but there is no trivial fix for it.

Where is the issue with context for why this is not fixed?

[mxandreas]

"another mobile device"? I don't have "another mobile device" I have just the one

I do not think many users run EW on their mobile device, if that is what you meant. "Another mobile device" does not in my opinion suggest that you have multiple mobile devices - it is another device that is mobile. However, I do not mind alternative wordings which may be more clear.

[frebib]

the EX app needs to be open before the verification is started, otherwise the request is lost.

Classic Element (Android) doesn't have this issue so it doesn't sound like it's impossible to implement. Is this an iOS specific limitation, or just a Hard Problem™ that isn't going to be attempted to be fixed?

[stefanceriu]

The underlying issue here is that in order to bootstrap the session verification listeners we need access to the user's identity which is dependant on a keys query response. Normally that would be handled through an olm machine listener but, as I understand it, those get reset often due to missing cross proccess locking. As such, we use sync callbacks as a retry mechanism until we can actually get our hands on a session_verification_controller. Obviously, this isn't ideal but the fix isn't at all straight forward.