* 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>
* Initial cut of MSC to standardize from being optiona on /messages requests.
* Fix typo.
Co-authored-by: Travis Ralston <travisr@matrix.org>
* Clarifications of start/end.
* Add information about back-paginating excluded events.
Co-authored-by: Travis Ralston <travisr@matrix.org>
* initial version of serverside aggregations proposal
* fix MSC numbers
* clarification
* add e2ee section from 2674 here, as it is only needed for server-side aggregations
* move edge case wrt to calling /context on a relation here from 2674
* fix typo
* clarify which APIs should bundle relations
* move stale_events over to future extensions section
* summarize stale_events and make tone conditional to mark that is not part of the MSC
* casing and wording
* clarify in summary an API for requesting relations is also proposed
* remove proposal for batch get event api as is unused and unimplemented
* attempt to clarify relations vs aggregations
* clarify pagination and align it with synapse impl already in the wild
* conciseness
* better headers
* clarify that relations are always returned, contrary to aggregations
* document the limitation of the event type not being known in e2ee rooms
* specify that redacted relations are not aggregated
* remove type in (non-binding) example as synapse doesn't do this
* mention that these are just examples
* clarify that this is a non-normative example
* Update proposals/2675-aggregations-server.md
Co-authored-by: David Baker <dbkr@users.noreply.github.com>
* add http method for endpoint list
* line break
* remove "unbundled relations" term, it's just confusing
instead use relation events,
with the bundled form now called aggregation
also restructure the headings so we have on section about aggregations
and another one about querying relation events
* some more restructuring of text after changing doc structure
* mention original_event for m.replace relations
* remove dir param as it is unused and unimplemented
* clarify that relating pending events should happen by transaction_id
* remove unimplemented /aggregations/{eventID}//{eventType}/{key}
endpoint
* Update proposals/2675-aggregations-server.md
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* mention that the server might not be aware of all the relations
* clarify that redacted events should still return their relations and aggregations respectively
* remove /context edge case, it should not be special-cased
* Update proposals/2675-aggregations-server.md
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* bad example, replies doesn't use relations
* clarify that we dont bundle discrete events
* clarify that we dont bundle discrete events, again
* improve example
* clarify this MSC does not use a prefix
* better english
* clarify pagination in example
* better english
* remove contradication: m.reference doesn't support pagination but example mentions it
* double punctuation
* clarify that only the bundled aggregation limit for truncation can't be set by the client, /aggregations does have a limit param
* move e2ee limitation to limitations section
* clarify prefixes
* mention that state events never bundle aggregations
* Update proposals/2675-aggregations-server.md
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* add that the visibility of relations can derive from that of the target
* typsos
* be more explicit
* moar rewording
* keep related parts together
* don't make a relation invisible because the target event isn't
also clarify what to do with relations for which the target is invisible
* Update proposals/2675-aggregations-server.md
Co-authored-by: David Baker <dbkr@users.noreply.github.com>
* better words
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* be more precise when clients should ensure the key is shared
* mention that ignored users can cause different aggregations for users
* move visibility rule changes to MSC3570
* don't overspecify visibility limitation, allow for unspecified behaviour
as synapse includes the invisible events in the aggregation
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* move non-normative note to below example
* make rel_type mandatory as the response structure doesn't allow for mixing types
* fix typo/thinko
* make pagination forward only as there is no use case for backwards
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* add non-normative aggregation examples
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* use relation type rather than rel_type
the former is already define as the latter in MSC 2674
* change trailing slashes remark to event_type, rel_type is mandatory now
* reword and split out client-side aggregation section
* rename parent event to target event, the term used elsewhere
* apply suggestion
* apply suggestion
* remove pagination
* remove mentions of /aggregations endpoint after removing pagination
* add note about not bundling into state events
* restructure headers so more of the aggregations stuff is under section
* make rel_type mandatory for /relations and better wording
* remove confusion that aggregations contain more info than relations
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* mention that tokens from /sync, /messages can be used on /relations
* try not to be overly prescriptive
* remove edge case of ignoring events without target event, as ignoring is not always safe
* clarify limitation for encrypted rooms
* make rel_type optional again for /relations
* Update proposals/2675-aggregations-server.md
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Update proposals/2675-aggregations-server.md
Co-authored-by: Matthew Hodgson <matthew@arasphere.net>
* mention requires auth and rate-limited on /relations
* replace hypothetical examples for bundled aggregations with non-normative ones
* move to MSC 2676 as it's specific to edits
* dont repeat how local echo using transaction_id works
Co-authored-by: Bruno Windels <bruno@windels.cloud>
Co-authored-by: David Baker <dbkr@users.noreply.github.com>
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Matthew Hodgson <matthew@arasphere.net>
Now that we've dropped the old build pipeline (and an assets directory does not exist in the repo any longer, we can rename the hugo version of the assets (assets-hugo) created during the build tools migration back to simply assets.
* 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.
Travis Ralston