|
| 1 | +# MSC4383: Client-Server Discovery of Server Version |
| 2 | + |
| 3 | +### Proposal |
| 4 | + |
| 5 | +An object is added to the top-level of `GET /_matrix/client/versions`[^1] named `server` with |
| 6 | +parity to the eponymous object returned by `GET /_matrix/federation/v1/version`[^2]. |
| 7 | + |
| 8 | +Example of the `server` object: |
| 9 | + |
| 10 | +``` |
| 11 | + "server": { |
| 12 | + "name": "My_Homeserver_Implementation", |
| 13 | + "version": "ArbitraryVersionNumber" |
| 14 | + } |
| 15 | +``` |
| 16 | + |
| 17 | +Example of a full response: |
| 18 | +``` |
| 19 | +{ |
| 20 | + "server": { |
| 21 | + "name": "My_Homeserver_Implementation", |
| 22 | + "version": "ArbitraryVersionNumber" |
| 23 | + }, |
| 24 | + "unstable_features": { |
| 25 | + "org.example.my_feature": true |
| 26 | + }, |
| 27 | + "versions": [ |
| 28 | + "r0.0.1", |
| 29 | + "v1.1" |
| 30 | + ] |
| 31 | +} |
| 32 | +``` |
| 33 | + |
| 34 | +### Alternatives |
| 35 | + |
| 36 | +The status quo requires a client to query the federation version endpoint. It is the only known |
| 37 | +example of a cross-boundary request to have any use[^5] to an implementation[^3], motivating |
| 38 | +this proposal to reestablish a clean partition. This status quo alternative is problematic: the |
| 39 | +partition in the `/_matrix` URL hierarchy is understood by site-administrators to allow for distinct |
| 40 | +middleware configurations. Sites commonly employ WAF rules covering the client and federation |
| 41 | +hierarchies with source and destination assumptions. Some sites disable the entire federation |
| 42 | +portion, rendering the status quo as unreliable. |
| 43 | + |
| 44 | +MSC2301[^4] enriches the discovery information, including some identifying information about the |
| 45 | +server, though specific formal vendor and semantic version information appears avoided |
| 46 | +(see: potential issues). |
| 47 | + |
| 48 | +### Potential Issues |
| 49 | + |
| 50 | +Server vendor and version information has been considered counter-productive to the motivations |
| 51 | +of Matrix as a unifying communication standard. Matrix believes any use of implementation |
| 52 | +knowledge as a condition in its applications always represents an accidental failure of its |
| 53 | +implementations or the standard binding them; the solution to such problems is thus found in |
| 54 | +cooperation, community and conformity, precluding the need for bug-for-bug conditions and |
| 55 | +workarounds. This MSC has the option of including a normative statement which inhibits the use |
| 56 | +of vendor information to determine functionality. |
| 57 | + |
| 58 | +### Security Concerns |
| 59 | + |
| 60 | +The federation endpoint is the only location which presently reveals this information. |
| 61 | +Site-administrators which have taken some measure to hide, or obscure, or modify it (i.e. with a |
| 62 | +proxy) will have to note their implementation's new exposure of it when upgrading. |
| 63 | + |
| 64 | + |
| 65 | +[^1]: https://spec.matrix.org/v1.16/client-server-api/#api-versions |
| 66 | + |
| 67 | +[^2]: https://spec.matrix.org/v1.16/server-server-api/#server-implementation |
| 68 | + |
| 69 | +[^3]: https://github.com/matrix-org/matrix-rust-sdk/blob/d228bde8ef51a98da10a6b7d4b9f3e5b8f49ad3c/crates/matrix-sdk/src/client/mod.rs#L581-L616 |
| 70 | + |
| 71 | +[^4]: https://github.com/matrix-org/matrix-spec-proposals/pull/2301 |
| 72 | + |
| 73 | +[^5]: Server version information can provide useful context in logs and may be essential for |
| 74 | +effective crash reports. |
0 commit comments