You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your request related to a problem?
The original problem has been described in #828: it is possible for the library to end up in a logged-in-but-no-E2EE state when a keychain is not accessible, and client code has to explicitly check for that state.
Describe the suggested change/improvement you'd like
Since E2EE support is unconditionally compiled these days, and an inaccessible keychain is not the intended failure mode in any case, it makes sense to emit loginError() when it's apparent that keychain is not in a usable state. This both protects the user data and make the problem much more apparent than it is now.
Describe alternatives you've considered
We can stick to the current logic and simply document that E2EE is not guaranteed to be in order even if it's explicitly turned on on the connection. This will lead to crashes with the existing (at least) NeoChat codebase (see #828), while the suggested change will prevent the login but the client will stay alive.
The text was updated successfully, but these errors were encountered:
it makes sense to emit loginError() when it's apparent that keychain is not in a usable state.
I think there should be some way that the client can discern what the issue is.
If the client presents to the user "login failed", the user starts to doubt that the credentials are correctly remembered or the matrix homeserver functions correctly, but it does not give a hint that the local(!) keychain is not accessible.
Is your request related to a problem?
The original problem has been described in #828: it is possible for the library to end up in a logged-in-but-no-E2EE state when a keychain is not accessible, and client code has to explicitly check for that state.
Describe the suggested change/improvement you'd like
Since E2EE support is unconditionally compiled these days, and an inaccessible keychain is not the intended failure mode in any case, it makes sense to emit
loginError()
when it's apparent that keychain is not in a usable state. This both protects the user data and make the problem much more apparent than it is now.Describe alternatives you've considered
We can stick to the current logic and simply document that E2EE is not guaranteed to be in order even if it's explicitly turned on on the connection. This will lead to crashes with the existing (at least) NeoChat codebase (see #828), while the suggested change will prevent the login but the client will stay alive.
The text was updated successfully, but these errors were encountered: