* Spec MSC3771: Threaded read receipts
Note: this builds on a (as of writing) non-existent "threading" section, which is part of a different commit.
* Spec MSC3773: Threaded notifications
* changelog
* Various clarifications per review
* Spec MSC3440: Threading (just the base)
Other threading MSCs to follow
* Spec MSC3856: Threads list API
* Spec MSC3715: Add`dir` to `/relations`
* changelog
* Apply suggestions from code review
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* Update changelogs/client_server/newsfragments/1254.feature
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* Convert `m.receipt.yaml` to traditional YAML
* Spec MSC2285 (private read receipts)
* Add some obvious copyright headers
* Add changelog entries
* Appease the linter
Apparently it hates it when you do this.
* Allow m.fully_read on /receipts
* Apply suggestions from code review
Co-authored-by: Matthew Hodgson <matthew@matrix.org>
Co-authored-by: Matthew Hodgson <matthew@matrix.org>
* Clarify that /invite will respond with 200 if the user is already in the room
* Create 1084.clarification
* Update changelogs/client_server/newsfragments/1084.clarification
Co-authored-by: Travis Ralston <travpc@gmail.com>
* Arrange a few titles
Before this change, PublicRoomsChunk in the spec text could be found in
two places (actually three but the third one is identical to the first
one), defining two (_mostly_ identical but) different schemas.
Ctrl-F'ing through the spec may confuse you with the "wrong" definition.
This commit gives distinct schemas distinct names; aside from
PublicRoomChunk, the same story happens with the derivative of
stripped_state.yaml used in space_hierarchy.yaml (it's not exactly
StrippedStateEvent either).
As for the removal of `PublicRoomsChunks` (plural) - this title is
unnecessary because the tooling would place rather self-explanatory
`[PublicRoomsChunk]` without it, whereas the plural title ends up with
no definition in the spec text.
* Add changelog
* keys.yml: fix one_time_keys object contents
The alternatives previously listed under two additionalProperties levels
are actually one _more_ level deeper; we still can't define them in
a formal way before moving to OpenAPI 3 but at least let's be honest
and say there's always a dict where there's always a dict. Also,
since the same data structure is used in three places now, at least
give it a name, and document the actual definition (once) separately
(not using it now because it's OpenAPI 3).
* Changelog
* Commit to show changes to rich replies section
* Move rich replies to a module
* Add remainder of MSC2674
* Pivot away from MSC3440: Threads
* Add changelog entries so far
* Make a note for why we have aggregations/relations if nothing uses it
* Outright remove threads references
Apparently this breaks the table of contents
* Define MSC2675
* Define MSC3666
* Add note for rich replies?
* Update content/client-server-api/_index.md
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* Clarify how ignoring works for aggregations.
* Try to clarify redactions a bit
* Clarify using parent/child language
* Add missing bits of MSC2675
* Add changelog for aggregations
* Appease the linters
* Update data/api/client-server/relations.yaml
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Try to clarify the return of /relations
* Fix required attribute
* Fix wording round 1
* Try to fix pagination
* Copy/paste the endpoint to make Open API happy
* Fix code block examples for rich replies
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Apply suggestions on all 3 endpoints
* Fix description of relationships API
* Fix warning about server-side aggregation/bundling
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* room_type is not a required parameter in practice
In practice servers seem to mirror what the room create event does and
leave out the room_type when unset.
Signed-off-by: Nicolas Werner <n.werner@famedly.com>
* Add changelog
Signed-off-by: Nicolas Werner <n.werner@famedly.com>
* Also make room_type and allowed_room_ids optional in the openapi
They are optional according to the text, but the openapi marks them as
required instead.
Signed-off-by: Nicolas Werner <n.werner@famedly.com>
* Fix copy and paste error of newsfragment
Signed-off-by: Nicolas Werner <n.werner@famedly.com>
* fix: spaces hierarchy paramater types
- changed `limit` parameter type to integer
- changed `query` parameter type to integer
A floating number does not make any sense here. Also, at least Synapse
does not allow floating point numbers in here.
Signed-off-by: TheOneWithTheBraid <the-one@with-the-braid.cf>
* Update changelogs/client_server/newsfragments/1097.clarification
Co-authored-by: Travis Ralston <travpc@gmail.com>
As per MSC3567, the `from` parameter is now optional for the `/messages` endpoint to allow fetching first or latest room content without having to rely on `/sync`
https://github.com/matrix-org/matrix-doc/pull/3567
