MSC4102: Clarifying precedence in threaded and unthreaded read receipts in EDUs #4102
Conversation
| When a server is combining receipts into an EDU, if there are multiple receipts for the same (user, event, receipt type), always | ||
| choose the receipt which is unthreaded (has no `thread_id`) when aggregating into an EDU. |
There was a problem hiding this comment.
Combining leads to data loss, which is possibly why we still have stuck notifications/badge counts. If a threaded and unthreaded receipt are queued for sending, those should be independent EDUs because maps can't support both.
There was a problem hiding this comment.
Losing the threaded receipt isn't really data loss though, which is what the "Potential Issues" section talks about.
There was a problem hiding this comment.
hmm, fair point. I'm not sure this needs to be an MSC then - it feels like a clarification that can be made directly to the spec, given it's effectively talking about a data optimization and not functional specified behaviour.
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Demonstration of a bug fixed (likely a client implementation)
There was a problem hiding this comment.
Looks good to me. I'd prefer to change the format but that would be a lot of pain and this proposal will fix the issue.
Related: matrix-org/matrix-spec#1684
| This proposal clarifies previously undefined behaviour around how read receipts are expressed over | ||
| the CSAPI and SSAPI. This clarification reliably provides clients with sufficient information to | ||
| determine read receipts, without placing additional burdens on client implementations. |
There was a problem hiding this comment.
element-hq/synapse#16927 doesn't seem to make any changes to the server-server API and Synapse currently will send multiple EDUs over federation if there's both an unthreaded and threaded receipt (or just multiple threads).
This is since the EDU format is a bit different there. It maps room ID -> receipt type -> user ID -> {event IDs, data: {ts, thread ID (if applicable)}. (The client-server API maps event ID -> receipt type -> user ID -> {ts, thread ID (if applicable)}.)
There was a problem hiding this comment.
Indeed, which is fine. Federation can send multiple EDUs if it wants to, so long as at the end of the day the receiving server has the right receipts to combine them in /sync. The Complement test does check that this MSC works over federation.
There was a problem hiding this comment.
I guess my point is that there isn't undefined behavior of the SSAPI.
# Synapse 1.102.0 (2024-03-05) ### Bugfixes - Revert element-hq/synapse#16756, which caused incorrect notification counts on mobile clients since v1.100.0. ([\#16979](element-hq/synapse#16979)) # Synapse 1.102.0rc1 (2024-02-20) ### Features - A metric was added for emails sent by Synapse, broken down by type: `synapse_emails_sent_total`. Contributed by Remi Rampin. ([\#16881](element-hq/synapse#16881)) ### Bugfixes - Do not send multiple concurrent requests for keys for the same server. ([\#16894](element-hq/synapse#16894)) - Fix performance issue when joining very large rooms that can cause the server to lock up. Introduced in v1.100.0. ([\#16903](element-hq/synapse#16903)) - Always prefer unthreaded receipt when >1 exist ([MSC4102](matrix-org/matrix-spec-proposals#4102)). ([\#16927](element-hq/synapse#16927)) ### Improved Documentation - Fix a small typo in the Rooms section of the Admin API documentation. Contributed by @RainerZufall187. ([\#16857](element-hq/synapse#16857)) ### Internal Changes - Don't invalidate the entire event cache when we purge history. ([\#16905](element-hq/synapse#16905)) - Add experimental config option to not send device list updates for specific users. ([\#16909](element-hq/synapse#16909)) - Fix incorrect docker hub link in release script. ([\#16910](element-hq/synapse#16910)) ### Updates to locked dependencies * Bump attrs from 23.1.0 to 23.2.0. ([\#16899](element-hq/synapse#16899)) * Bump bcrypt from 4.0.1 to 4.1.2. ([\#16900](element-hq/synapse#16900)) * Bump pygithub from 2.1.1 to 2.2.0. ([\#16902](element-hq/synapse#16902)) * Bump sentry-sdk from 1.40.0 to 1.40.3. ([\#16898](element-hq/synapse#16898))
Rendered
No client implementation required.
Server implementation: matrix-org/sliding-sync#401 & element-hq/synapse#16927
Fixes the issue element-hq/element-x-ios#1479