Clarifying implicit read receipts / read receipts for sent messages

[tulir]

I've been thinking about implicit read receipts lately. By "implicit read receipt" I mean the fact that messages sent by the user should obviously be marked as read by that user, even though clients don't send explicit read receipts for those messages.

Relevant spec sections:

The client behavior section of https://spec.matrix.org/v1.5/client-server-api/#receipts says

Clients SHOULD NOT send read receipts for events sent by their own user.

https://spec.matrix.org/v1.5/client-server-api/#receiving-notifications says (emphasis mine)

When the user updates their read receipt (either by using the API or by sending an event), notifications prior to and including that event MUST be marked as read.

From this information, one could extrapolate that explicit read receipts won't usually appear for messages that a user sent themselves, but everyone should act as if there was a read receipt.

However, implicit read receipts right now don't work consistently. I've seen some issues in Elements where bridges sending messages as the user with double puppeting didn't mark the room as read in the user's other clients. It also seems very easy to create new bugs like that in other clients since the read receipt spec doesn't say that implicit read receipts exist.

Due to such bugs, some of my bridges now break the first quoted spec and just send an explicit read receipt to get rid of the problem (I didn't know about that sentence in the spec when I made the bridges do that). When writing Beeper's bridge homeserver, we decided to always create an explicit read receipt when sending an event to get rid of those bugs completely in bridged rooms. We're considering making our Synapse do the same thing now to make Matrix rooms work properly too.

Is my assumption correct about how implicit read receipts work? If yes, should that be documented more explicitly in the spec? (or perhaps it already is and I missed it? I couldn't find anything else talking about the topic in the spec). If not, how is it actually supposed to work?

Would it make more sense to make a MSC that says servers must create an explicit read receipt along with events sent by the user? That way client developers wouldn't have to worry about the details as much and could just fully trust read receipts in /sync contains.

[clokep]

See also matrix-org/synapse#14837 -- maybe this is just a Synapse bug that we aren't properly clearing notification counts?

[bradtgmurray]

Would it make more sense to make a MSC that says servers must create an explicit read receipt along with events sent by the user? That way client developers wouldn't have to worry about the details as much and could just fully trust read receipts in /sync contains.

I'm personally a fan of this. Presumably every user in the room already has an explicit read receipt somewhere in the room, so we're not generating new data, just updating existing data more often, and practically speaking the updated read receipt should be delivered in the same sync as the event itself to all clients when events are created, so it's not a new sync call to close. In return, we get simpler unread/"should I send a read receipt" calculations in clients and homeservers, and a generally easier to understand behaviour.

[twouters]

This would remove the ability to send an event to a room without marking the room as read.
For example, someone mentions a user and the mentioned user gets a push notification to which they can quick-reply directly from the notification without actually opening their client and having read the rest of the conversation. If that user opens their client afterwards, they won't be able to see that there were other unread messages in the room they've sent the quick reply message to.

I don't know if any client implements this as described, but wouldn't this proposal prevent it from ever being done?

[clokep]

MSC4005 is related to this.