Spec for MSC3981 (#1746)

* Spec for MSC3981

This writes up https://github.com/matrix-org/matrix-spec-proposals/pull/3981

Hopefully this is relatively straightforward, apart from having to add
the parameters and response field in all three places. I tried to factor
these out but it seems references just aren't supported in the right
places currently (see https://github.com/matrix-org/matrix-spec/pull/1745
for my efforts). Path parameters can't be optional, so it can't be done
that way either.

* Missed schemas

* newsfile

* Actually it clearly isn't going to support markdown, is it?

* grammar

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

* grammar

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

* Clarity

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

* Clarity

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

* Typo

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

* More clarity.

Note this is counter what the MSC actually proposed to add, but
I think it's clear that this is what it meant.

---------

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
This commit is contained in:
David Baker 2024-03-19 18:12:32 +00:00 committed by GitHub
parent bb4003afa8
commit 848c1e0348
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
3 changed files with 45 additions and 1 deletions

View file

@ -2156,6 +2156,19 @@ following endpoint.
This endpoint is particularly useful if the client has lost context on the aggregation for
a parent event and needs to rebuild/verify it.
When using the `recurse` parameter, note that there no way for a client to
control how far the server recurses. If the client decides that the server's
recursion level is insufficient, it could, for example, perform the recursion
itself, or disable whatever feature requires more recursion.
Filters specified via `event_type` or `rel_type` will be applied to all events
returned, whether direct or indirect relations. Events that would match the filter,
but whose only relation to the original given event is through a non-matching
intermediate event, will not be included. This means that supplying a `rel_type`
parameter of `m.thread` is not appropriate for fetching all events in a thread since
relations to the threaded events would be filtered out. For this purpose, clients should
omit the `rel_type` parameter and perform any necessary filtering on the client side.
{{% boxes/note %}}
Because replies do not use `rel_type`, they will not be accessible via this API.
{{% /boxes/note %}}