andybalaam
commented
1 year ago Speaking of which, a change which merged yesterday morning from @t3chguy has made my experience much better today. If you try the latest nightly build or develop.element.io* you may see a decent improvement **.
*: nightly builds and develop are both bleeding-edge and not guaranteed to work at all! If you'd prefer to wait, this change will appear in the release on 1st August.
**: but I still see some more minor problems, so we are definitely not at the end of the road yet.
This change also sparked another spec change proposal: https://github.com/matrix-org/matrix-spec-proposals/pull/4037
samim23
mutantcornholio
jtrees
leonardehrenfried
aurorasmiles
Johennes
jplatte
jtherrmann
t3chguy
mrclauss
jeffrson
omame
marco-c
bhearsum
colans
We are experiencing multiple issues in the area of "stuck" notifications and unread markers. Many are related to the way receipts interact with threaded messages.
Symptoms
We are seeing different symptoms of the problem:
Spec-level causes
Message ordering
Fundamentally, in order to interpret the meaning of a receipt that says "I have read everything up to here", we need to know what order messages are in. This is not clear in the spec, and we propose to make it clear and explicit in MSC4033.
In the meantime, Element Web uses a combination of "sync" order (the implicit order of events arriving via a /sync request) and "timestamp" order (using the
tsproperty within events).Some of the existing bugs are probably caused by this inconsistency, but it is not clear yet how many: we believe there are also bugs in the implementation that cause additional problems, and this theoretical inconsistency is only the cause of a few problems.
Which thread the root belongs to
The spec has what we consider a bug when it talks about which thread the root message belongs to, which has been reflected in client code, making it inconsistent with the server implementation (at least on the Synapse server). We have a proposal to fix this bug in MSC4037.
Identifying which thread any message is in
It is sometimes difficult for clients to identify which thread an event belongs to, meaning that a receipt pointing to it is sometimes ignored. We have begun drafting MSC4023 to address this.
Other
Previously, we believed that MSC3981 (recursive relations) would solve some of the problems, but since that MSC does not solve the event-ordering problem (because the events from the /relations API are returned in "topological" order) we no longer believe it is important, except as a performance optimisation. Code-level causes
Code-level causes
We have found and fixed several bugs in the Element Web code that were caused by an incomplete understanding of the meaning of threaded and unthreaded read receipts. We anticipate that some more exist.
(We believe that the primary reason why we're not seeing the same problems on mobile is that the apps persist events they've received whereas Element Web has to re-fetch from scratch after every launch. As a result, any issue in the unread state logic, strikes again and again. The apps also use a single timeline whereas Element Web maintains one timeline per thread in addition to the main timeline in every room.)
High-level plan of actions
We believe a lot of progress can still be made without spec changes. So we're slightly deprioritising work on the MSCs.
New issue inbox
The following is a holding area for newly reported issues that require review. Once reviewed, issues should either be moved to one of the other task lists below or, if not applicable, removed from this epic.
Tasks not blocked by spec work
Tasks that are related to or dependent on spec work
We've written the following MSCs to try and address the root causes in a reliable and performant way:
/eventto fetch the parent has been implemented. This is functionally correct but has a noticeable performance impact.Issues that are related but out of scope
Time sheeting
WEB: Stuck notifications