Downgrades should gracefully handle local state in a newer version than expected

[jryans]

We should isolate state from different instances from Riot on the same domain such as (riot.im/app and riot.im/develop).

At the moment, you could open any version of Riot Web from the same domain, and they will all access the same browser state. Newer branches (such as /develop) might upgrade local state to a newer version, rendering it unusable by older branches (such as /app).

This kind of corruption caused E2E message keys to be lost (via crypto DB version changes) in #7734.

[ara4n]

in the past we've used this as a feature; letting users rapidly switch between /app and /staging and /develop without having to relogin and resync. also, we need to support people being able to switch riot version back & forth on a given domain (e.g. upgrading chat.example.com to riot 0.17; deciding it sucks and downgrading to 0.16; without destroying their users).

so i wonder whether the better solution is to 'just' correctly manage the versioning of localstorage & indexeddb to avoid corruption in the first place...

[jryans]

I agree that when it works, it's quite convenient. It's definitely nice to be able to test different branches quickly.

I think the most complex case versioning case comes from an older client reading a newer data format it knows nothing about. If we want to preserve the current world of rapid switching, we'll need to think carefully about what to do in that case.

[ara4n]

so i don't care /too/ much about rapid switching; i'd prefer that we had rapid login!

but we do need to protect against the scenario where chat.example.com downgrades without corrupting all their users.

[jryans]

I'll refocus this on the more general issue of ensuring that software downgrades gracefully handle local state in a newer version than expected.

One possible way to encounter a "downgrade" is via the different branches on riot.im, but it also includes the chat.example.com case of a single branch that has reverted to a previous version.

[lampholder]

I think the rapid-switching is a red herring - useful or not, the time saved on logging into two or three different clients is nothing compared to the time spent reasoning about (and fixing bugs caused by) the additional complexity.

However, giving people who deploy their own instances of Riot a downgrade path is important, and I'm not confident that we'd remember to do this right now if we weren't feeling the pain of incompatible versions running in parallel.

Is there a path we can take which guarantees robust downgrade paths for versioned releases? Then we could move riot.im/x to x.riot.im confident in the knowledge that we weren't breaking the downgrade path as well as not having to worry that in-development changes are going to cause unmanaged incompatibility fireworks.

[t3chguy]

This is no longer needed given we split them out into subdomains