* 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>
* Fix rendering of response examples
Fixes the autogeneration of JSON examples for array objects. This fixes a
number of "Specification error: Example invalid or not present" errors in the
rendered spec.
* Unbreak examples for non-objects/arrays
The previous change had broken auto-generated examples for everything that
wasn't an object or array; fix it up again.
* Remove conditions on $example
Everything should now have a generated example, so the condition is
redundant. Furthermore it was suppressing examples for APIs where the example
was an empty dict.
* Copy spec PR near-verbatim from past PR
With light review being addressed.
https://github.com/matrix-org/matrix-doc/pull/3168
* Alter for modern day
* Add changelog
* specify that we're using the grammar
* 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>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
Co-authored-by: Travis Ralston <travisr@matrix.org>
Fixes#3465. The change adds a line explicitly warning developers that the base_url of client well_known may or may not include a trailing slash and to be prepared to handle both cases.
* Add a release branch to avoid orphaned commits.
* Specify a patch process.
* Match reality and reference the internal deployment process.
This is largely what we do in practice now, including a created `release/v1.1` branch.
Switch to upstream and use a more recent version.
Fixes failure to edit on empty descriptions.
Signed-off-by: Alexandre Franke <alexandre.franke@matrix.org>
* MSC3419 - Guest state events
Let guests send state events. Needed for guests to work with native
group voip in #3401
* typo
* Update 3419-guest-state-events.md
incorporate @clokep clarification
* also let guests send non-m.room.message events in general.
* Update proposals/3419-guest-state-events.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/3419-guest-state-events.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* wordwrap
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
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.
* Clarify that E0 and E1 are not returned
* Clarify that ASCII art diagram 2 refers to diagram 1
* Correct third ASCII art diagram
To match the spacing in. Borked in the move to new docs format.
55aed1d296/specification/client_server_api.rst (L1610-L1615)
* Make ASCII art 3 follow from ASCII art 2
* Explain how to fill the gap
* Create 3543.clarification
* Update content/client-server-api/_index.md
Co-authored-by: Travis Ralston <travisr@matrix.org>
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.
* initial version of event relationship MSC
* fix MSC numbers
* clarifications
* mention multiple relations per event might be useful, but postpone for a future MSC
* mention MSC 3051 for proposed multiple relations
* remove send_relation endpoint
* move e2ee section under sending relations
* mention limitation of leaving server-side aggregations out for now
* remove mentions of m.reference, we'll sort that out in another MSC
* whitespace
* argument why m.relates_to should be preserved by redactions more general
but still give example of redacted edits
* deal with this in the comments
* clarify the conditions to meet for a relation
* mention specifically that this does not replace replies (yet)
* clarify how general rel_types should be
* clarify that gaps may cause clients to be unaware of some relations
* Update proposals/2674-event-relationships.md
Co-authored-by: DeepBlueV7.X <nicolas.werner@hotmail.de>
* Update proposals/2674-event-relationships.md
Co-authored-by: DeepBlueV7.X <nicolas.werner@hotmail.de>
* make wording clearer and move to bottom of section
* remove this as references are not defined here anymore
* clearer wording
* move edge cases to other relevant mscs
* clarify that a goal of sticking to this format is backwards compat.
* mention MSC 3267, to which m.reference has been extracted
* Update proposals/2674-event-relationships.md
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Update proposals/2674-event-relationships.md
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Update proposals/2674-event-relationships.md
Co-authored-by: Matthew Hodgson <matthew@arasphere.net>
* Update proposals/2674-event-relationships.md
Co-authored-by: Matthew Hodgson <matthew@arasphere.net>
* Update proposals/2674-event-relationships.md
Co-authored-by: Travis Ralston <travpc@gmail.com>
* wrap lines
* better wording
* this is singular, really
* add example of event shape
* specify how invalid relations should be treated by the redaction algorithm
* fix typo
* split up redactions changes in separate MSC
* also add new msc to introduction
* reword why not adopt m.in_reply_to
* remove guidelines how to pick rel_type
* mention that the target event must exist in the same room
* spell out the conscious (subject, object, verb) triple idea.
* Spelling
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* remove paragraph saying what server should accept
* Revert "remove paragraph saying what server should accept"
This reverts commit e0271331b2e7dee236349aa63eec3cec7369e361.
* further specify that a server should reject invalid relations through the cs api
* linebreak
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Bruno Windels <bruno@windels.cloud>
Co-authored-by: DeepBlueV7.X <nicolas.werner@hotmail.de>
Co-authored-by: Matthew Hodgson <matthew@arasphere.net>
Co-authored-by: Travis Ralston <travpc@gmail.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Split the text about event IDs and event formats into separate sections. This
is largely to make it easier to link to, but I think the resulting text makes
more sense too.
Travis Ralston