Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-04-29 05:44:10 +02:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Make clear the thread root is not in the thread

Browse source 
Signed-off-by: Andy Balaam <andy.balaam@matrix.org>
This commit is contained in:
Andy Balaam 2023-11-22 10:35:53 +00:00
parent 25a9157f0a
commit 801dc8d4bf
3 changed files with 30 additions and 24 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
content/client-server-api/modules/push.md
View file

@ -1070,16 +1070,16 @@ ahead), however if the `m.read.private` receipt were to be updated to
event D then the user has read up to D (the `m.read` receipt is now
behind the `m.read.private` receipt).
{{< added-in v="1.4" >}} When handling threaded read receipts, the server
is to partition the notification count to each thread (with the main timeline
being its own thread). To determine if an event is part of a thread the
server follows the [event relationship](#forming-relationships-between-events)
until it finds a thread root (as specified by the [threading module](#threading)),
however it is not recommended that the server traverse infinitely. Instead,
implementations are encouraged to do a maximum of 3 hops to find a thread
before deciding that the event does not belong to a thread. This is primarily
to ensure that future events, like `m.reaction`, are correctly considered
"part of" a given thread.
{{< added-in v="1.4" >}} When handling threaded read receipts, the server is to
partition the notification count to each thread (with the main timeline being
its own thread). To determine if an event is part of a thread the server follows
the [event relationship](#forming-relationships-between-events) until it finds a
thread root via an `m.thread` relation (as specified by the [threading
module](#threading)), however it is not recommended that the server traverse
infinitely. Instead, implementations are encouraged to do a maximum of 3 hops to
find a thread before deciding that the event does not belong to a thread. This
is primarily to ensure that future events, like `m.reaction`, are correctly
considered "part of" a given thread.
#### Server behaviour

24
content/client-server-api/modules/receipts.md
View file

@ -137,16 +137,22 @@ either a thread root's event ID or `main` for the main timeline.
Threading introduces a concept of multiple conversations being held in the same
room and thus deserve their own read receipts and notification counts. An event is
considered to be "in a thread" if it meets any of the following criteria:
* It has a `rel_type` of `m.thread`.
* It has child events with a `rel_type` of `m.thread` (in which case it'd be the
thread root).
* Following the event relationships, it has a parent event which qualifies for
one of the above. Implementations should not recurse infinitely, though: a
maximum of 3 hops is recommended to cover indirect relationships.
considered to be "in a thread" if:
Events not in a thread but still in the room are considered to be part of the
"main timeline", or a special thread with an ID of `main`.
* It has a rel_type of m.thread, or
* It has a parent event with this rel_type, or a parent of a parent, or further
up the chain of relations. (Implementations should not recurse to arbitrary
depth: a maximum of 3 hops is recommended to cover indirect relationships.)
Events not in a thread but still in the room are considered to be in the "main
timeline". Threaded receipts for the main timeine use a special thread ID of
`main`.
Thread roots are considered to be in the main timeline, as are events that are
related to a thread root via non-thread relations. Note that clients providing a
single-thread view will probably want to include thread roots and some of their
child events (e.g. reactions) in that view, even though from a receipt point of
view they are not part of that thread.
The following is an example DAG for a room, with dotted lines showing event
relationships and solid lines showing topological ordering.

10
content/client-server-api/modules/threading.md
View file

@ -12,11 +12,11 @@ as by providing some context to what is going on in the thread but keeping the f
history behind a disclosure.
Threads are established using a `rel_type` of `m.thread` and reference the
*thread root* (the first event in a thread). It is not possible to create a
thread from an event which itself is the child of an event relationship (i.e.,
one with an `m.relates_to` property). It is therefore also not possible to nest
threads. All events in a thread reference the thread root instead of the
most recent message, unlike rich reply chains.
*thread root*. It is not possible to create a thread from an event which itself
is the child of an event relationship (i.e., one with an `m.relates_to`
property). It is therefore also not possible to nest threads. All events in a
thread reference the thread root instead of the most recent message, unlike rich
reply chains.
As a worked example, the following represents a thread and how it would be formed: