-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Investigate if there are unspecced endpoints that can be removed #8334
Comments
I collated a bunch of this on a spreadsheet, but a summary is below. FederationUnspecced
Errors
ClientPrefix
Unspecced
Obsolete MSCsEndpoints from MSCs which are obsolete (not accepted into the specification). Hopefully these can be removed.
Proposed MSCsEndpoints for MSCs which are proposals and not yet accepted into the specification. Generally these are fine as is.
Merged MSCsEndpoints for MSCs which were merged, but are not yet part of the specification. These should be unstable only.
Implementation specificSome endpoints aren't specced and are implementation specific (i.e. there are sent to the client as a redirect or sent to confirm email addresses, etc.). These could potentially be moved under the
Errors
UnimplementedSpecified endpoints that are not implemented in Synapse.
DeprecatedThe specification has some deprecated endpoints as well. These are generally implemented by Synapse, but unless support for older versions of the spec are dropped, these cannot be dropped (e.g. the |
I think the next step here would be to:
|
|
The MSC process actually says the opposite:
|
I must have missed that that MSC got replaced! Thanks for pointing this out!
Fair enough, just documenting it. I thought we had an issue about this, but we don't seem to. I'll file a separate one. |
Should everything used by |
As I said in the description, this is tracked in a separate issue:
|
I think this is matrix-org/matrix-doc#1757. |
[MSC2432](matrix-org/matrix-spec-proposals#2432) added this endpoint originally but it has since been included in the spec for nearly a year. We can't reasonably remove the unstable endpoint as client implementations still rely on it, and those clients cannot rely on `r0.6.x` appearing in the `/versions` to detect if this stable endpoint exists. It's proposed to introduce a transition period for implementations which may be stuck on the old endpoint of 2 months (minimum). After that point, Synapse can (and should) remove the unstable endpoint without warning. The exact timelines are to be determined by the synapse team, however. This is progress towards #8334
Related: #8334 Deprecated in: #9429 - Synapse 1.28.0 (2021-02-25) `GET /_synapse/admin/v1/users/<user_id>` has no - unit tests - documentation API in v2 is available (#5925 - 12/2019, v1.7.0). API is misleading. It expects `user_id` and returns a list of all users. Signed-off-by: Dirk Klimpel dirk@klimpel.org
this is specced as part of the AS API - https://spec.matrix.org/unstable/application-service-api/#put_matrixclientr0directorylistappservicenetworkidroomid - but only in its PUT guise. |
[MSC2432](matrix-org/matrix-spec-proposals#2432) added this endpoint originally but it has since been included in the spec for nearly a year. This is progress towards #8334
Note that #11584 removed the various groups/communities endpoints. |
This increases compatibility with homeservers and allows them to remove Element Android specific workaround. fixes element-hq#4830 see ruma/ruma#936 see matrix-org/synapse#8334 see matrix-org/synapse#9224 Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
As of element-hq/element-android#6288 Element Android now uses the stable version of |
I've attempted to update the spreadsheet, though I suspect there are more endpoints which are not listed. |
I wonder if at this point it would make sense to split this into separate issues for each endpoint? |
I looked briefly today and the only requests going to matrix.org on |
We should investigate whether there are any unspecced (and unused) endpoints in Synapse.
See #8177 about some of the admin APIs being exposed under
/_matrix/client
.I took a look at some of the federation APIs and client APIs also, will put some results in here tomorrow.
#8154 also has some related info.
The text was updated successfully, but these errors were encountered: