* 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>
* Clarification on historical power level handling
* Revert "Clarification on historical power level handling"
This reverts commit f443b3d5a9.
* Clean up
* Let us try this again not using VS Code
* Markdown is full of mysteries
* Move stringy power levels to room versions
* Describe range
* Fix minor issues with previous room version stuff
* Copy/paste v9 into v10
* Describe deprecated formatting
* Paste unmodified auth rules from v8 into v10
* Move 9.1 to 9.3, add 9.1 and 9.2 for integer enforcement
* Add knock_restricted to v10 auth
* Misc cleanup and clarification for fragments
* Describe `knock_restricted` client changes
* Changelogs
* spelling
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Apply code review suggestions manually
* Fix v9 redactions
* Fix auth rules clarity issues
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Remove false integer requirements
Co-authored-by: Neil Alexander <neilalexander@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>
The spec had an erroneous `room_id` field in a m.typing EDU entry of /sync, `m.read` receipts in `/sync`, and `m.fully_read` room account data objects in the spec. None of these are necessary nor used in practice.
Checking part of the ecosystem for whether clients look for, or homeservers include, these room_id fields, I found that:
Element does not require them, nor does Synapse include them.
Ruma does not include them.
Dendrite does not include them.
nheko/mtxclient does not look for them.
This change removes room_id from the example and OpenAPI schema in each case mentioned above. It only affects the Client-Server spec - the Server-Server spec text remains unchanged.
The field was initially introduced in 0f28f83.
Fixes#3641
The spec says the name field in m.room.name events must not exceed 255 bytes but no servers actually enforce this over the C-S API. Clients should probably already be truncating room names to an appropriate length for their user interface.
Signed-off-by: Aaron Raimist <aaron@raim.ist>
* Fix membership state table and diagram
There were 2 missing cases which are legal:
* `invite->knock` (a fairly silly thing to do, but legal under the auth rules)
* `external->leave (via /kick)` (another somewhat silly thing to do, but no different than `external->ban (via /ban)`)
The state table considered the first as illegal, which is untrue.
* Changelog
* Make the graph prettier
* Update changelogs/client_server/newsfragments/3730.clarification
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Andrew Morgan