MSC4383: Client-Server Discovery of Server Version#4383
Conversation
jevolk
force-pushed
the
jevolk/client-server-info
branch
from
2e7318e to
e934a35
Compare
There was a problem hiding this comment.
Implementation requirements:
- Client (ideally multiple)
- Server
turt2live
added
proposal
| @@ -0,0 +1,80 @@ | |||
| # MSC4383: Client-Server Discovery of Server Version | |||
|
|
|||
There was a problem hiding this comment.
This proposal appears to be lacking a problem statement and/or introduction, making it difficult to review with an aim to include it in the spec.
There was a problem hiding this comment.
The problem is stated in the Alternatives section. I didn't feel the need to make a redundant introduction given the status quo alternative is prominent and it's a small proposal otherwise. Should the first paragraph be moved to the top?
There was a problem hiding this comment.
Relevant information and background should always be first. I didn't feel the paragraph in the Alternatives was suited as an introduction because it lacks background and context.
jevolk
force-pushed
the
jevolk/client-server-info
branch
from
e934a35 to
63cdb4b
Compare
|
(please avoid force pushing after review is given - it makes review more difficult. We do not require clean commit history) |
| Client applications utilizing the Matrix SDK[^6], a Client-Server[^7] library, have been observed | ||
| making requests to `GET /_matrix/federation/v1/version`[^2]. It is the only known example of a | ||
| cross-interface request to have any possible[^5] use to any implementation[^3], motivating this | ||
| proposal to reestablish a properly clean partition between client and federation interfaces. |
There was a problem hiding this comment.
Why do these applications query the SS API in the first place? Also, do they query the SS API on their own home server or on remote servers?
There was a problem hiding this comment.
In the found case, the information is logged and not used to determine application-logic. The logs are then included in rageshakes.
The query is only to the local server, as remote servers would require server name resolution which the client is not capable of—arguably the local server also requires the resolution for the federation interface which is itself another concern for why the status quo is untenable.
There was a problem hiding this comment.
Thanks! I think both of these would be good to include in the main text as they help understand the proposed solution. For instance, if querying /versions on a remote server was a use case, you would need a different API shape that allows to pass in the server name.
There was a problem hiding this comment.
Are you suggesting morphing this proposal into a client API where the homeserver can run version queries on any other server on behalf of the client?
There was a problem hiding this comment.
Sorry, no. I just meant to use that as an example to illustrate that without describing the use case it's not clear why the proposed solution is the best one.
|
Implemented in Tuwunel (shipped in v1.6.2). Source: src/api/client/versions.rs#L32-L38. |
Folds several housekeeping items into a single chore: - Retroactively adds Signed-off-by trailers for prior commits 63cdb4b and 7904077, rather than amending and force-pushing the original commits. - Renames the section heading "Security Concerns" to "Security Considerations" to match the upstream MSC template. - Switches the two fenced example blocks in the Proposal section from bare ``` to ```json so renderers highlight the JSON shapes. - Splits the long matrix-rust-sdk source footnote ([^3]) URL onto its own line under the footnote marker. The URL itself is 137 characters and cannot be wrapped without breaking the link; the split keeps prose lines clear and lets the URL sit as a delimited footnote block. Signed-off-by: Jason Volk <jason@zemos.net> Pre-trailer-sha: 63cdb4b Pre-trailer-sha: 7904077
Adds an Implementations section listing the shipped Tuwunel server support, the open Ruma protocol-types pull request, and the open matrix-rust-sdk client pull request. Footnote anchors carry the linking URLs. Signed-off-by: Jason Volk <jason@zemos.net>
States that GET /_matrix/client/versions remains unauthenticated, is not rate-limited, that guest-access restrictions are not applicable, and that no new error responses are introduced. Closes the endpoint-conventions clauses of the SCT checklist for this MSC. Signed-off-by: Jason Volk <jason@zemos.net>
Adds a Backwards Compatibility section covering the additive wire shape, the net.zemos.msc4383 detection flag, and the SDK fallback pattern that lets application consumers acquire the partition correction with no code change. Closes the backwards-compatibility clause of the SCT checklist for this MSC. Signed-off-by: Jason Volk <jason@zemos.net>
Adds a non-technical lead paragraph addressing turt2live's review request that background and context appear first. Folds Johennes's review clarifications into a dedicated paragraph: the use case is logging only (the identification is included in rageshakes and similar diagnostic submissions, not consulted to determine application behaviour) and the query targets the user's own homeserver only. Renames the section heading from "Motivation" to "Introduction" per upstream template convention. Incidental fixes carried by the rewrite: corrects the "reestablises" typo to "reestablishes", drops the incorrect "as" from "rendering the status quo as unreliable", removes the hyphen from "site-administrators", and switches "utilizing" to "utilising" so the document is consistently British spelling. Signed-off-by: Jason Volk <jason@zemos.net>
Adds a parallel citation to element-web's rageshake collector, which calls the Synapse-specific administrative endpoint GET /_synapse/admin/v1/server_version with a federation-side /version fallback. The pair illustrates the two workaround shapes in production client code: cross-interface (matrix-rust-sdk) and vendor lock-in (element-web), neither of which functions when its corresponding interface is restricted at the deployment edge. Signed-off-by: Jason Volk <jason@zemos.net>
Adds explicit MUST/SHOULD/MAY/MUST NOT obligations covering server population of the new server object, parity with the federation /version response (with an escape valve for federation-disabled deployments), and the prohibition on clients gating application logic on the object's contents. Signed-off-by: Jason Volk <jason@zemos.net>
Extends the unstable-prefix table with rows for the net.zemos.msc4383 support advertisement and the net.zemos.msc4383.stable companion advertisement that signals the accepted-but-not-merged interval, so clients can detect support and migrate reads to the unprefixed server key without coordination. Signed-off-by: Jason Volk <jason@zemos.net>
Folds minor textual corrections identified during a pre-submission review. Signed-off-by: Jason Volk <jason@zemos.net>
github-project-automation
Bot
moved this to Tracking for review
in Spec Core Team Workflow
turt2live
moved this from Tracking for review
to Proposed for FCP readiness
in Spec Core Team Workflow
3 participants
rendered
Implementations
serverobject onGET /_matrix/client/versionsand advertisingnet.zemos.msc4383inunstable_features.Serverstruct and theResponse.serverfield behind theunstable-msc4383Cargo feature.Client::server_vendor_infoto prefer the client-server source, falling back toGET /_matrix/federation/v1/versiononly when the object is absent. The feature is enabled by default inmatrix-sdk-ffi, so applications consuming the FFI binding acquire the client-server path on rebuild without an app-side flag.Pre-acceptance checklist
GET /_matrix/client/versionsremains unauthenticated.)errcodeand HTTP status code? (N/A.)errcodeis introduced, is it clear that it is new? (N/A.)unstable_featuresadvertise gate, and SDK migration path preserving the existingClient::server_vendor_infocontract.)use_underscores_like_this? (Existing endpoint; convention preserved.)net.zemos.msc4383.stablecompanion flag listed in §Unstable prefix).net.zemos.*).