[Prep] Threads: Avoid stuck notifications

[manuroe]

Description

This is a placeholder issue because we may not meet this issue on EX depending on the strategy we are going to adopt. So, no work may be required for this. If not, we look at solution like matrix-org/matrix-spec-proposals#4033. Check https://artificialworlds.net/blog/2024/12/04/message-order-in-matrix/ to understand why it is not easy.

Acceptance criteria

• TBD

Size estimate

S/M/L

Dependencies

• None

Out of scope

Subtasks

Android

iOS

Rust

Other

[bnjbvr]

One change we've discussed: a server may send two read-receipts for a thread, for the logged-in user:

• one for the last message in the topological ordering (used by /relations)
• one for the last message in the stream ordering (used by /sync)

(Some work would be needed client-side to handle multiple read receipts for a single event, too.)

This would avoid server-caused stuck unreads, for instance in the following case:

• thread's events are A, B, C, D in sync ordering
• but A, B, D, C in topo ordering
• client 1 receives sync events in real time, sends threaded read receipt for D
• client 2 receives events in topo ordering via /relations, sends threaded read receipt for C, but the server ignores because there's already a receipt for D, and receipts are handled in sync ordering

So client 2 ends up with an unread thread.

Note this can also happen on the main timeline, or with unthreaded read receipts, but is less likely to happen since these timelines tend to be busier.

[manuroe]

After another discussion, it appears to be not a problem for EX: as long as "unread in a thread" doesn't change the global "unread room status", we shouldn't have these stuck unread rooms