From 4a77139249c2e830aec3c7d6bd5501a514d1cc27 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C5=A0imon=20Brandner?= Date: Thu, 3 Mar 2022 22:54:35 +0100 Subject: [PATCH] Use a separate `receiptType` for hidden read receipts (#3750) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Update the way MSC2285 works Signed-off-by: Šimon Brandner * Update proposals/2285-hidden-read-receipts.md Co-authored-by: Travis Ralston --- proposals/2285-hidden-read-receipts.md | 90 +++++++++++++++----------- 1 file changed, 54 insertions(+), 36 deletions(-) diff --git a/proposals/2285-hidden-read-receipts.md b/proposals/2285-hidden-read-receipts.md index 133d396b9c4..9657efb2e87 100644 --- a/proposals/2285-hidden-read-receipts.md +++ b/proposals/2285-hidden-read-receipts.md @@ -1,62 +1,80 @@ # MSC2285: Hidden read receipts -Currently users must send read receipts in order to affect their notification counts, which -alerts to other people that the user has read their message. For primarily privacy reasons, -it may be desirable to users to not advertise to others that they've read a message. +Currently users must send read receipts in order to affect their notification +counts, which alerts other people that the user has read their message. For +primarily privacy reasons, it may be desirable to users to not advertise to +others that they've read a message. ## Proposal -When sending a `m.read` receipt, a `m.hidden: true` flag can be included (optional) to tell -the server to not send it to anyone else. This allows the user to affect their notification -counts without advertising that they've read the message. `m.hidden` defaults to `false`. +This MSC proposes adding a new `receiptType` of `m.read.private`. This +`receiptType` is used when the user wants to affect their notification count but +doesn't want other users to see their read receipt. -For example: -``` -POST /_matrix/client/r0/rooms/!a:example.org/receipt/m.read/$123 -{ - "m.hidden": true -} -``` +To move the user's private read receipt to `$123` the client can make a POST +request such as this. -The same applies to read markers (which allow you to update your read receipt): +```HTTP +POST /_matrix/client/r0/rooms/!a:example.org/receipt/m.read.private/$123 +{} ``` + +To also move the user's `m.fully_read` marker and `m.read` receipt the client +can make a POST request such as this. + +```HTTP POST /_matrix/client/r0/rooms/!a:example.org/read_markers { "m.fully_read": "$123", "m.read": "$123", - "m.hidden": true + "m.read.private": "$123", } ``` -Note that fully read markers are not sent to other users and are local to the user sending them. -Therefore, no changes are required or implied by `m.hidden` for `m.fully_read` - just `m.read`. +It is assumed that if only an `m.read` receipt is received, the `m.read.private` +should also be moved. -Servers processing read receipts MUST NOT send hidden receipts to any other user than the sender. -Servers MUST NOT send hidden receipts over federation to any server. +The `m.read` is now optional as sometimes we only want to send `m.read.private`. -## Tradeoffs - -Clients which support read receipts would end up rendering the user's receipt as jumping down -when they send a message. This is no different from how IRC and similarly bridged users are -perceived today. +Servers MUST NOT send receipts of `receiptType` `m.read.private` to any other +user than the sender. Servers also MUST NOT send receipts of `receiptType` +`m.read.private` to any server over federation. ## Security considerations -Servers could ignore the flag without telling the user. The user must already trust the homeserver -to a degree however, and the methods of notifying the user to the problem are difficult to -implement. Users can always run their own homeservers to ensure it behaves correctly. +Servers could act as if `m.read.private` is the same as `m.read` so the user +must already trust the homeserver to a degree however, and the methods of +notifying the user to the problem are difficult to implement. Users can always +run their own homeservers to ensure it behaves correctly. + +## Potential issues + +Clients which support read receipts would end up rendering the user's receipt as +jumping down when they send a message. This is no different from how IRC and +similarly bridged users are perceived today. -## Why not X kind of EDUs? +## Alternatives -In short: don't send those EDUs. Typing notifications, device messages, etc can all be mitigated -by simply not calling the endpoints. Read receipts have a side effect of causing stuck -notifications for users however, which is why they are solved here. +It has been suggested to use account data to control this on a per-account +basis. While this might have some benefits, it is much less flexible and would +lead to us inventing a way to store per-account settings in account data which +should be handled in a separate MSC. + +Previous iterations of this MSC additionally suggested that having an `m.hidden` +flag on existing read receipts could work, however this feels like assigning too +much responsibility to an existing structure. ## Unstable prefix -While this MSC is not considered stable, implementations should use `org.matrix.msc2285` as a namespace -for identifiers. `m.hidden` becomes `org.matrix.msc2285.hidden` for example. +While this MSC is not considered stable, implementations should use +`org.matrix.msc2285` as a namespace. + +|Release |Development | +|----------------|---------------------------------| +|`m.read.private`|`org.matrix.msc2285.read.private`| -To detect server support, clients can either rely on the spec version (when stable) or the presence of -a `org.matrix.msc2285` flag in `unstable_features` on `/versions`. Clients are recommended to check for -server support to ensure they are not misleading the user about "hidden read receipts". +To detect server support, clients can either rely on the spec version (when +stable) or the presence of a `org.matrix.msc2285` flag in `unstable_features` +on `/versions`. Clients are recommended to check for server support to ensure +they are not misleading the user about their read receipts not being visible to +other users.