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) |
proposals/4383-client-server-info.md
Outdated
| 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.
3 participants
rendered