First draft

proposals/4037-thread-root-is-not-in-thread.md

@@ -4,15 +4,75 @@ The current spec implies that a thread root is considered within the thread, but
 we argue that this does not make sense, and a thread root is not "in" it the
 thread branching from it.
 
+This is important for creating and interpreting read receipts.
+
+## Motivation
+
+The current spec, in
+[11.6.2.2 Threaded read receipts](https://spec.matrix.org/unstable/client-server-api/#threaded-read-receipts)
+says:
+
+> 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.
+>
+> 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`.
+
+This explicitly includes thread roots in the thread which branches off them, and
+implicitly _excludes_ those messages from being in the `main` thread.
+
+This is problematic because:
+
+* It seems natural for messages that are displayed in the main timeline (as
+  thread roots are in most clients) to be considered read/unread when the user
+  reads them in the main timeline.
+
+* It normally does not make sense for a threaded read receipt to point at the
+  thread root, since the user has not really read anything in that thread if
+  they have only read the thread root.
+
+In practice, Synapse ignores any request to mark the thread root as read within
+the thread, and accepts requests to mark it as read in the main timeline.
+
+In consequence, Element Web displayed bugs relating to unread rooms while its
+underlying library used spec-compliant behaviour, many of which were fixed by
+[reverting to the behaviour recommended by this proposal](https://github.com/matrix-org/matrix-js-sdk/pull/3600).
+
+It really does not make sense to treat thread roots as outside the main
+timeline: any message can become a thread root at any time, when a user creates
+a new threaded message pointing at it.
+
 ## Proposal
 
+We propose this definition:
 
+> An event is considered to be "in a thread" if:
+>
+> * It has a `rel_type` of `m.thread`, or it has an ancestor event with this
+>   `rel_type`.
+>
+> Implementations should limit recursion to find ancestors: a maximum of 3 hops
+> is recommended.
+>
+> Events not in a thread but still in the room are considered to be part of the
+> "main timeline": a special thread with an ID of `main`.
 
 ## Potential issues
 
 
 ## Alternatives
 
+We could treat thread roots as being in *both* their thread and the `main`
+timeline, but it does not offer much benefit because a thread where only the
+root message has been read is almost identical to one where the no messages have
+been read. A thread cannot exist without at least one additional message.
 
 ## Security considerations