* First iteration of specifying Spaces
MSCs:
* https://github.com/matrix-org/matrix-doc/pull/3288
* https://github.com/matrix-org/matrix-doc/pull/2946
* https://github.com/matrix-org/matrix-doc/pull/1772
Note that this makes modifications to the underlying MSCs as well. These are intended to be minor edits to aid clarity/accuracy of the MSCs, as per the proposal process. Functionally, clients and servers might need to change their behaviour slightly as is expected of implementing this stuff early. Synapse has these changes (alongside backwards compatibility) here: https://github.com/matrix-org/synapse/pull/11667
* add changelogs
* Accuracy per review
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* fully prefix new endpoints
* Fully prefix endpoint in 3616 too
* Fix ordering example
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Add registration token UIA type
MSC: https://github.com/matrix-org/matrix-doc/pull/3231
**Note**: This introduces the endpoint as v1 rather than r0 given the global versioning changes landed between the acceptance of the MSC and now.
* Fix swagger
* Changelogs
* Update data/api/client-server/registration_tokens.yaml
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Add HTTP 403 to possible profile responses
Some servers may not allow profile lookup over federation, and thus
respond to GET /_matrix/client/v3/profile/{userId} with an HTTP 403.
For example, Synapse can be configured to behave in this way by setting:
allow_profile_lookup_over_federation=false
Thus, this behavior already exists in the wild, and may cause issues for
clients such as https://github.com/vector-im/element-web/issues/17269.
Synapse could alter its behavior and return an HTTP 404 in these cases,
but amending the Spec seems preferable to align with extant behavior.
Further, allowing HTTP 403 gives clients more specific information as to
why a request has failed, enabling more precise error handling.
Signed-off-by: Dan Callahan <danc@element.io>
* Update changelogs/client_server/newsfragments/3530.clarification
Co-authored-by: Travis Ralston <travpc@gmail.com>
* Annotate misc data about error
Co-authored-by: Travis Ralston <travpc@gmail.com>
Co-authored-by: Travis Ralston <travisr@matrix.org>
The documentation for the `/notifications` API had its own special definition
of what an Event was, which was used nowhere else.
The common definition isn't perfect, but it *is* common, so it gives us a
better starting place for improvement.
Remove a bunch of fields from the `unsigned` property of PDUs. These things
shouldn't be passed over the Federation API, and they *really* shouldn't be
trusted if they are sent by another server.
* `replaces_state` *is* returned by Synapse, but probably shouldn't
be.
* `redacted_because`, `prev_sender` and `prev_content` are not sent by Synapse.
* Introduce a new "added-in" template and use it on endpoints
* Use "added-in" on schema properties too
* Annotate sections of the spec with their added versions
* Demo of "added-in" on a room version (to be fleshed out)
* Use clearer versioning semantics
* Update and fix validator for Swagger custom properties
* Fix docs
* Cut/paste room version spec to its own page
* Move grammar to bottom + add feature matrix
The version grammar is not as interesting as the actual room versions, so this moves that whole section to the bottom.
* Fix all links to room versions
Apparently, in response to a /_matrix/federation/v1/user/devices/{userId} request, Synapse actually returns a key called "self_signing_key" instead of "self_signing_keys".
The regex of allowed characters for a `client_secret` parameter is `[0-9a-zA-Z.=_-]`.
This PR updates the `client_secret` spec examples, which currently include an invalid character (an apostrophe).
Travis Ralston