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 event D then the user has read up to D (the `m.read` receipt is now
behind the `m.read.private` receipt). behind the `m.read.private` receipt).
{{< added-in v="1.4" >}} When handling threaded read receipts, the server {{< added-in v="1.4" >}} When handling threaded read receipts, the server is to
is to partition the notification count to each thread (with the main timeline partition the notification count to each thread (with the main timeline being
being its own thread). To determine if an event is part of a thread the its own thread). To determine if an event is part of a thread the server follows
server follows the [event relationship](#forming-relationships-between-events) the [event relationship](#forming-relationships-between-events) until it finds a
until it finds a thread root (as specified by the [threading module](#threading)), thread root via an `m.thread` relation (as specified by the [threading
however it is not recommended that the server traverse infinitely. Instead, module](#threading)), however it is not recommended that the server traverse
implementations are encouraged to do a maximum of 3 hops to find a thread infinitely. Instead, implementations are encouraged to do a maximum of 3 hops to
before deciding that the event does not belong to a thread. This is primarily find a thread before deciding that the event does not belong to a thread. This
to ensure that future events, like `m.reaction`, are correctly considered is primarily to ensure that future events, like `m.reaction`, are correctly
"part of" a given thread. considered "part of" a given thread.
#### Server behaviour #### 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 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 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: considered to be "in a thread" if:
* 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.
Events not in a thread but still in the room are considered to be part of the * It has a rel_type of m.thread, or
"main timeline", or a special thread with an ID of `main`. * 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 The following is an example DAG for a room, with dotted lines showing event
relationships and solid lines showing topological ordering. 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. history behind a disclosure.
Threads are established using a `rel_type` of `m.thread` and reference the 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 root*. It is not possible to create a thread from an event which itself
thread from an event which itself is the child of an event relationship (i.e., is the child of an event relationship (i.e., one with an `m.relates_to`
one with an `m.relates_to` property). It is therefore also not possible to nest property). It is therefore also not possible to nest threads. All events in a
threads. All events in a thread reference the thread root instead of the thread reference the thread root instead of the most recent message, unlike rich
most recent message, unlike rich reply chains. reply chains.
As a worked example, the following represents a thread and how it would be formed: As a worked example, the following represents a thread and how it would be formed: