Events related to the root event of a thread cannot have read receipts sent on them

[clokep]

Originally reported at element-hq/element-web#23451, info from @gsouquet.

If you have a DAG that looks something like this:

flowchart RL
    E-->D
    D-->C
    C-->B
    B-->A
    B-.->|m.thread|A
    C-.->|m.thread|A
    D-.->|m.edit|C
    E-.->|m.reaction|A

Loading

The root event (and any other reactions, etc. to it) are shown both in the "main" timeline and as part of the thread. It is desirable for clients to be able to send a receipt in either of those. E.g. looking at a "thread" which shows A (as the root) and the reaction to it (E) and are trying to send a receipt for E.

[clokep]

I think we could probably (implementation-wise) allow a receipt for E to apply to either the main timeline or the A timeline iff there is at least one threaded reply to A. This makes the logic a little more complicated though (you're searching both up and down a tree instead of just up it). Will need to think about if that makes sense.

I think this would even be allowed by the spec (annotations added):

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. <-- Obviously false in this case.
• It has child events with a rel_type of m.thread (in which case it’d be the thread root). <-- False in all cases of something with a relationship.
• Following the event relationships, it has a parent event which qualifies for one of the above. <-- This is TRUE; it has a parent event which has child events of rel_type of m.thread!

[clokep]

There are two cases which would be unaligned by making this change though:

Case 1 (which we're talking of changing):

Clients want to be able to send a receipt for an event related to the root event (via a non-thread relation).

Case 2:

Clients expect notifications from events related to the root event (via a non-thread relation) to be in that thread.

---

Note that the spec for notifications says:

To determine if an event is part of a thread the server follows the event relationship until it finds a thread root (as specified by the threading module), 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.

The threading module only talks about:

Threads are established using a rel_type of m.thread and reference the thread root (the first event in a thread).

---

From the above (and the comment above it sounds like the way events are considered part of a thread does differ for notifications vs. receipts.