You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
matrix-spec-proposals/proposals/1804-advertising-capable-ro...

60 lines
3.0 KiB
Markdown

# Proposal for advertising capable room versions to clients
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.
## Proposal
Building off of [MSC1753](https://github.com/matrix-org/matrix-doc/pull/1753) (capabilities API) and
the [recommendations laid out for room versions](https://github.com/matrix-org/matrix-doc/pull/1773/files#diff-1436075794bb304492ca6953a6692cd0R463),
this proposal suggests a `m.room_versions` capability be introduced like the following:
```json
{
"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"]
}
}
}
```
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.
Clients should prompt people with sufficient permissions to perform an upgrade to upgrade their rooms
to the `m.recommended` room 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.
## Potential issues
Changes aren't pushed to the client, which means clients may want to poll this endpoint on some
heuristic instead. For example, clients may want to poll the endpoint weekly or when the user relaunches
the client. Clients may also wish to provide users a way to upgrade without considering the capabilities
of the server, expecting that the server may not support the user-provided version - the intention
being such a feature would be used by eager room administrators which do not want to relaunch their
client, for example.