[Story] EX: Migration to SSS

[manuroe]

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_device events that could have been queued by the proxy. The transition will be divided in the following phases:

• Phase 1 — No support for SSS yet, nothing to do.
• Phase 2 — The SSS is supported, but transition is optional for the client.
• Phase 3 — The SSS is supported, client is forced to transition.

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

• The users encounter no other "friction" than a one-off logout.
• The users can postpone the logout for a period of time.

Size estimate

None

Dependencies

• None

Out of scope

• Nothing

Open questions

Questions

Beta Give feedback

No tasks being tracked yet.

Subtasks

Android

Beta Give feedback

1. Offer user to transition to SSS (Android) element-x-android#3427
   +0
   

iOS

Beta Give feedback

1. Offer user to transition to SSS (iOS) element-x-ios#3258
   +0

Rust

Beta Give feedback

No tasks being tracked yet.

Other

Beta Give feedback

No tasks being tracked yet.

[manuroe]

@mxandreas I am assigning this issue with you to check how to build this not smooth migration. @Hywan, @jmartinesp @stefanceriu will build it.

[Hywan]

What about the log out solution?

[manuroe]

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.

[mxandreas]

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?

[mxandreas]

easy ways to notify the users in advance

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.

[stefanceriu]

allow the user to postpone the logout

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.

[mxandreas]

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.

[mxandreas]

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:

• Phase 1 — SSS is not supported by the server
  • /versions indicates no SSS support
  • auto-logout flag in well-known is not set
• Phase 2 — SSS is supported by the server, and the client asks to relogin
  • /versions indicates SSS support
  • auto-logout flag in well-known is not set
• Phase 3 — Proxy is being removed, and the client enforces to relogin
  • /versions indicates SSS support
  • auto-logout flag in well-known is set

Updated copy for the logout prompt:

• 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".

[Hywan]

Ive also written a proposal here, https://github.com/element-hq/matrix-hosted/issues/9920#issuecomment-2275695372. Just so that everything is here :-).

[mxandreas]

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?

[bmarty]

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.

[bmarty]

About your remark in #2499 (comment):

It is not unusual for apps to do that.

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?

[Hywan]

@mxandreas It's here, matrix-org/matrix-rust-sdk#3889.

[mxandreas]

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?

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.

What will be useful for application developer is the expected behavior of the application and the expected design.

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.

[Hywan]

matrix-org/matrix-rust-sdk#3889 has landed in the Rust SDK \m/.

[manuroe]

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.
We will need to consider Phase 3 later for Android.