[Story] EX: Migration to SSS #2499
Comments
manuroe
added
App: ElementX Android
App: ElementX iOS
T-User Story
Team: Element X Platform
X-Needs-Design
X-Needs-Product
|
@mxandreas I am assigning this issue with you to check how to build this not smooth migration. @Hywan, @jmartinesp @stefanceriu will build it. |
|
What about the log out solution? |
|
yes. This is about the logout solution. That's why I am saying the transition will be not smooth. I added logout term in the description in the user story. |
|
I was trying to think of effective and easy ways to notify the users in advance, but could not come up with anything useful. Nobody sees or reads the release notes - e.g. if we were to put a warning in there in some previous release? I guess giving the user an option to postpone the logout would require significant development effort already? |
We discussed that with @manuroe and @amshakal on Mon. Manu mentioned that there might a simple way to allow the user to postpone the logout (for limited period of time like a few days). @stefanceriu can you check it (or any similar alternatives) - but do not spend too much time on it. If we need to invest more than 1 day into this, then it is not worth it. Let's then just logout the users. It is not unusual for apps to do that. |
Well we can easily build a mechanism that does that but I don't see how it improves the experience for anybody: people on matrix.org won't have a proxy to use the delayed logout session against and the ones that run their own infrastructure don't want to logout period. (Syncing releasing SSS and the apps through the various stores and droping the proxy will most likely result in disaster) I believe most non-controversial solution would be to detect that the proxy the logged in session was running against is no longer available and that its homeserver has SSS support, and only force logout in if both of those are true. |
|
We had a conversation with @stefanceriu and @pixlwave . The most straightforward approach is to detect if there is SSS support and then use this (forcing the user to log out if SSS was not used before), otherwise fallback to SS. In order for this to be reliable, the server needs to publicly expose if SSS is supported, because the client needs this information before login, e.g. if you are a new user (or new device) then the client does not know if to use SSS or not (and may choose a wrong option). Using "heuristics" to detect if SSS support may cause more confusion. It would be ideal to agree on the API ASAP so the logic can be implemented on client side and it reaches as many phones as possible. For the logout prompt I would suggest something generic: "Your homeserver has been upgraded, and to benefit from the improvements you will need to login again. Apologies for the inconvenience." When it comes to the question of what happens when server supports SSS but EX has not been updated yet, we arrived at the conclusion that this should not be a problem, because the SS is still available and EX will continue to support that. |
|
After a follow-up with @erikjohnston we decided to make the rollout a bit more granular and allow the existing users to opt-out from SSS for some period of time. The latter will also be controlled from the server side so the phases will look as follows:
Updated copy for the logout prompt:
|
|
Ive also written a proposal here, https://github.com/element-hq/matrix-hosted/issues/9920#issuecomment-2275695372. Just so that everything is here :-). |
|
For visibility purposes: @Hywan is currently working on providing a (generic) API that would allow the apps to implement the logic agreed in this ticket. This is hopefully finished in a few days, after which the apps can actually implement the logic. @stefanceriu and @bmarty - would it make sense to create a ticket for each platform to track that work? |
|
Yes, you can create ticket for each platform, and link to this issue (which will be done automatically if you add the created issues to the subtasks in this issue description). What will be useful for application developer is the expected behavior of the application and the expected design. |
|
About your remark in #2499 (comment):
I agree that it's not unusual: it can happen on applications but it's really a pain for the users, especially here since the application does not remember the homerserver and will fallback to matrix.org. This is tracked by #2477 we should maybe start to implement this issue first, WDYT? Or the user story for this particular logout case may try to reuse the same homeserver URL if possible? |
|
@mxandreas It's here, matrix-org/matrix-rust-sdk#3889. |
We're still in the early adoption phase with EX, thus I think it is not necessary - I think people know their homeserver is currently just matrix.org or element.io.
I'd let the design to be driven by whatever is easier to implement, since this is temporary - only the current EX users would see it, and only once. |
|
matrix-org/matrix-rust-sdk#3889 has landed in the Rust SDK \m/. |
|
Phase 1 & 2 are now available on EXA and EXI. EXI even has Phase 3. I am closing this issue for the sake of project management for prod ready. |
Description
In order to migrate existing users of EX over to SSS, we need them to log out and log in again. One example of a technical blocker for a transparent transition (without logout) is the the
to_deviceevents that could have been queued by the proxy. The transition will be divided in the following phases:The copy for the logout prompt is as follows:
Phase 2: "Your homeserver has been upgraded to support a new and faster protocol. Log out and log in again to benefit from this upgrade and avoid forced logout in the future when the old protocol is removed." The options are then "Logout" and "Cancel".
Phase 3: "Your homeserver no longer supports the old protocol, you must log out and log in again to continue." The options are then "Logout".
Acceptance criteria
Size estimate
None
Dependencies
Out of scope
Open questions
Questions
Subtasks
Android
iOS
Rust
Other
The text was updated successfully, but these errors were encountered: