MSC4472: Deprecated room version kind#4472
Conversation
Signed-off-by: timedout <git@nexy7574.co.uk>
Signed-off-by: timedout <git@nexy7574.co.uk>
timedoutuk
changed the title
timedoutuk
changed the title
There was a problem hiding this comment.
Implementation requirements:
- Client
- Server
turt2live
left a comment
turt2live
left a comment
There was a problem hiding this comment.
Review from an early and brief read of the proposal
| Alongside `stable` and `unstable`, `deprecated` is added as a stability category. `deprecated` | ||
| should be treated the same as `unstable` (i.e. users should be discouraged from using them), but | ||
| with the following restrictions: | ||
|
|
||
| * `deprecated` room versions MUST NOT be the server's default room version. | ||
| * Clients that allow users to choose the room version when creating a room MUST NOT offer | ||
| `deprecated` room versions as an option. | ||
| * Clients that allow users to choose the room version when upgrading a room MUST NOT offer | ||
| `deprecated` room versions as an option. | ||
| * Clients SHOULD encourage users to upgrade rooms with a `deprecated` version. | ||
| * In order to make a distinction between unstable support (potentially stable in the future), and | ||
| deprecated (potentially removed in the future), clients SHOULD present a different message to | ||
| users to what they would normally present for unstable rooms. For example, instead of | ||
| "Your server administrator has marked this room version as unstable, some things may not work | ||
| correctly", the room's limited future lifespan may be highlighted instead: "Your server | ||
| administrator has marked this room version as deprecated and it may stop working in the future". |
There was a problem hiding this comment.
I'm not sure if I mean this as a suggestion yet, but why don't we apply these restrictions to unstable instead of adding a new definition/state?
There was a problem hiding this comment.
I think the semantic difference between deprecated (most likely previously stable, but end-of-life, and expected to be removed in the future) is significantly different to that of unstable (implementation may not be 100% up to scratch, and/or it may be stable in the future).
I'm not sure if this is the intended use of the categories, but in practice servers tend to assign room versions as stable or unstable depending on their confidence in their implementation support stability. For example, the Conduit family typically classifies room versions 3 through 5 as unstable for the reason that they typically work, but may not be fully supported, and this mechanism is used to prompt administrators of these rooms to upgrade to more widely supported versions.
With this in mind, room versions seem to have a lifecycle of unstable -> stable, and adding a deprecated classification allows that cycle to continue into unstable -> stable -> deprecated, and then eventual removal.
As far as I'm aware, users are not discouraged from creating rooms of unstable versions, with unstable prefixes at least, although are urged to upgrade to the stable versions when the unstable prefix no longer applies (such as the hydra phase 1 room version).
You could argue that the effects could just be applied to unstable, but personally I think making the distinction between unstable and deprecated is one that is more beneficial. If you disagree though, happy to hear your thoughts!
There was a problem hiding this comment.
From memory, the intention of the unstable/stable designation was to use it as a spec tool, not necessarily leave it as an implementation decision. Implementations wouldn't advertise v11 (for example) at all until it was complete, instead preferring to use an org.example.v11-style unstable prefix to evaluate the v11 implementation. Then, when the v11 implementation is ready for usage, rename org.example.v11 to 11 and change the designation at the same time. (In shorter words: it's unexpected that an implementation would say 11: unstable - they should have org.example.v11: unstable instead).
An aside: that does make it difficult for implementations to test existing room compatibility, though that would likely be addressed in a different MSC (if at all). An implementation could have enough logic to accept a join/invite to an "unknown" room version then internally rewrite the room version from 11 to org.example.v11 in their database, for example. This is how policyserv, as an example, can be tricked into supporting "close enough" room versions: https://github.com/matrix-org/policyserv/blob/404897426c3ed228c7ac1a507273d48574071093/migrations/02_room_info_up.sql#L1
With the idea that the spec gets to decide whether a specified room version is stable or not, I'm inclined to add a condition to unstable room versions along the lines of "SHOULD NOT allow rooms to be created with unstable versions" instead of adding a new designation to manage. We'd use a SHOULD so developers can actually test their changes via implementation-specific bypass flags ("only server admins can create rooms with this version" for example).
We're also pretty unlikely to actually remove a room version from the spec because there will be rooms which exist under those versions indefinitely. Removing things from the spec is also hard in general, especially when the stuff to be removed is likely to be in use for a long time. The primary issue being that implementations often want to support older spec versions, which means they're required to implement all of the removed functionality, so does it really count as "removed" from the spec? (this is also a problem for switching room versions from stable to any other state: implementations don't have to support unstable room versions, but they would need to support those room versions anyway if an older spec version they also support says they're stable).
Finally, we very much intended to use the mechanism to explicitly mark v1 as unstable, stopping use of the room version. We've never actually used the mechanism, so there's room for reinterpretation, but the original design intended to mark these old versions as unstable for age and security reasons (as noted in the spec itself).
There was a problem hiding this comment.
FSG-Cat was requesting a room version status that signifies that the version is old, but was previously stable and isn't going to get removed suddenly like MSC unstable versions will.
Exactly that. I may have been unclear when I referred to lifecycles and removal in my previous thread comment, I don't expect these room versions to be removed any time soon. On the other hand, however, I don't expect new servers to implement deprecated room versions, which means that over time it may become harder to join these rooms without specific software, and eventually they might be removed from newer spec versions going forward (it's worth remembering that you can always go back and visit old versions of the spec to see removed things)
I haven't had time to read your full reply Travis, but I do believe that while closely related, deprecated and unstable are different concepts that it's important to differentiate between. I think deprecated should be used exclusively for age, and unstable should be used to reflect actual stability (such as newly discovered vulnerabilities per the spec page linked, or implementations that may change wildly until they're stabilised in the spec). Although I do agree that using the stability flags to indicate server support for stable versions is probably optimistic misuse of the flags.
There was a problem hiding this comment.
Deprecation implies a plan to remove, so is probably not the word that's meant here. I still feel as though "unstable" communicates the intent adequately, though the spec itself likely needs clarification about what it means to be unstable.
There was a problem hiding this comment.
Maybe "legacy" would be better?
turt2live
added
proposal
| still happen, so the downside isn't major. [MSC4453] will allow servers to prevent the creation of | ||
| new deprecated rooms altogether, so this is seen as a growing pain more than a problem. |
There was a problem hiding this comment.
Why was preventing creation kept in the other proposal instead of bringing it to this one?
There was a problem hiding this comment.
I was aiming to keep the changes required for this proposal as narrow as possible so that it's more of a UI flag than anything until MSC4453 gets moving. I think bringing the functional restriction of preventing the creation of deprecated room versions would have too much overlap with MSC4453, MSC4472 is primarily intended to provide the flag before the functionality.
I could bring the prevention over but I just don't think it's a good fit
There was a problem hiding this comment.
It would make sense to have all the functionality ready to go beforehand in this proposal and leave MSC4453 as a simple proposal that only switches the status of the room versions
3 participants
Rendered
Implementations: