---
# MSCxxxx: Ranged read receipts

## Problem

Matrix currently only has the concept of read receipts which describe the
most recent message in a room which has been read by the user (aggregated
across all clients).

In practice, this is insufficient for many use cases:

* It's impossible to express per-message or per-range-of-message read state
for messages bridged from other platforms which support those semantics (e.g.
WhatsApp, iMessage, SMS, Facebook Messenger, Hangouts, Threema, IMAP, NNTP, Reddit,
HackerNews...). Therefore Matrix doesn't fulfil its role as a highest-common
denominator bridging language between different platforms.
* Read Markers end up being a very best-effort guess as to "where a user read up
to" in a room. Currently this is modelled as a `m.fully_read` read receipt, but
in practice users read rooms in blocks, and the second you open a room it forgets
the previous unread blocks.
* Similarly, notification counts in unread blocks immediately get zeroed out when
you open a room, even if you haven't read them yet.
* Another related problem is that if unread messages arrive out of order (e.g.
due to netsplits or other federation delays), we currently have no alternative than
append them to the timeline on the room to make the user aware of their existence.
But with if we had read receipts as ranges, we could explicitly mark these blocks as
unread in history.
* As there is no way to indicate which messages have actually
been read when you send a normal `m.read` receipt into a room, the act of sending an `m.read` receipt on a unthread-enabled client will mark all threads in the room as read, and zero their badge counts, which is very undesirable if you are also using thread-enabled clients.
* Currently we can't do selective "mark as (un)read" behaviour (e.g. as could be used as a basic bookmarking mechanism).

## Solution

Modify receipts to have both a starting and ending event
(today they are just an endpoint) and allow multiple receipts of
the same type per room. These are referred to as "ranged
read receipts". <-- Does this *change* the current receipts or is it a new receipt type? (Likely changing the current ones is better?)
* TBD if using events as the markers (as current receipts do) makes sense or maybe sync/pagination tokens?

They can be sent referring to the merged (i.e. unthreaded) timeline (whereupon the server must expand them out to apply them to the messages in the component threads within that range), or for individual threads (including the main timeline).
* Servers likely should coalesce overlapping ranges as well.

Switch to topological ordering on clients, so that:
* Stale messages appear at the right topological place (is this the right behaviour though? should we present them to the client as threads? or should we order things based on origin timestamp, which is what the user would expect?)
* This means that clients will be able to interpret ranges in read receipts correctly when visualising them locally.

Bits to include:
* How does this affect notifications? Local echo for clients.
* Servers do *not* need to calculate notif badges on the hot path (although they may today). This can be done after the message has been sent, as long as the client effectively does local echo in order to preempt that the badge count has reduced based on the messages the client knows the user has seen.

* How does this affect sync?
* Clients need to know about the regions they've read (and not read), keep using ephemeral "events" key in sync or use something else?

* Federation?
* Send the "maximal" read point (of each thread) to preserve privacy (sending all ranges seems excessive). (and this can be a separate MSC)

* Changes to handling of "historical content" received from offline homeservers? (Does this include/affect MSC2716 at all?) --> ordering of timelines is now consistently topological, meaning that clients should be able to consider the same events as servers.
* Maybe powering mark as unread (but likely punt to future MSC to fully define).

### Stuff to solve

From talking it through with Andy Balaam, a few interesting things came up...
* What if the events in the range aren't actually connected in the DAG, or don't follow one another in the DAG?
* How do you define the "most recent" value in a range? (Either for sending over federation, or if you're a client and you don't want to handle ranges but you keep getting range receipts; which ones are the 'newest' ones?).
* Specifically, if you're a client, and you receive some random read-range from the server, is that a 'most recent event' or something historical? The server presumably should do this on behalf of the client and decorate the read-ranges appropriately, given the client doesn't have visibility of the DAG.