Update MSC to match how room versions work
As per 1773.
This commit is contained in:
parent
853d7ede30
commit
50eba23669
1 changed files with 14 additions and 24 deletions
|
@ -3,7 +3,7 @@
|
|||
Currently clients need to guess at which room versions the server supports, if any. This is particularly
|
||||
difficult to do as it generally requires knowing the state of the ecosystem and what versions are
|
||||
available and how keen users are to upgrade their servers and clients. The impossible judgement call
|
||||
for when to prompt people to upgrade shouldn't be impossible, or even a judgement call.
|
||||
for when to encourage people to upgrade shouldn't be impossible, or even a judgement call.
|
||||
|
||||
|
||||
## Proposal
|
||||
|
@ -16,37 +16,27 @@ this proposal suggests a `m.room_versions` capability be introduced like the fol
|
|||
{
|
||||
"capabilities": {
|
||||
"m.room_versions": {
|
||||
"m.development": ["state-res-v2-test", "event-ids-as-hashes-test", "3"],
|
||||
"m.beta": ["2"],
|
||||
"m.default": "1",
|
||||
"m.recommended": "1",
|
||||
"m.mandatory": ["1"]
|
||||
"default": "1",
|
||||
"available": {
|
||||
"1": "stable",
|
||||
"2": "stable",
|
||||
"state-res-v2-test": "unstable",
|
||||
"event-ids-as-hashes": "unstable",
|
||||
"3": "unstable"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The labels picked (`m.development`, etc) are based upon the categories for different room versions.
|
||||
Note that `m.default` and `m.recommended` reinforce that there is exactly 1 version in each category.
|
||||
|
||||
Clients are encouraged to make use of this capability to determine if the server supports a given
|
||||
version, and at what state.
|
||||
version, and at what level of stability.
|
||||
|
||||
Clients should prompt people with sufficient permissions to perform an upgrade to upgrade their rooms
|
||||
to the `m.recommended` room version.
|
||||
The default version is the version that the server is using to create new rooms with. Clients can
|
||||
make the assumption that the default version is a stable version.
|
||||
|
||||
Room versions might appear under multiple categories under some circumstances. In particular, it is
|
||||
expected that anything in `m.development` or `m.beta` appears exactly once in the whole capability
|
||||
whereas `m.default`, `m.recommended`, and `m.mandatory` may duplicate a room version. The duplication
|
||||
is possible due to the definitions of each category:
|
||||
|
||||
* `m.default` - This is the room version that the server is going to apply to all new rooms by default.
|
||||
* `m.recommended` - The version clients should be prompting people to upgrade to.
|
||||
* `m.mandatory` - The version the server is going to enforce on all pre-existing rooms.
|
||||
|
||||
With these definitions, it is possible that a room version fits multiple criteria (ie: "please upgrade
|
||||
your rooms to version X which is also the default for new rooms"). Clients will generally only be
|
||||
interested in the `m.recommended` room version, leaving the rest as informational for users.
|
||||
Clients should encourage people with sufficient permissions to perform an upgrade to upgrade their
|
||||
rooms to the `default` room version when the room is using an `unstable` version.
|
||||
|
||||
|
||||
## Potential issues
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue