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:
parent
bb4003afa8
commit
848c1e0348
3 changed files with 45 additions and 1 deletions
|
@ -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 %}}
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue