Spec MSC2285: Private read receipts (#1216)

* Convert `m.receipt.yaml` to traditional YAML

* Spec MSC2285 (private read receipts)

* Add some obvious copyright headers

* Add changelog entries

* Appease the linter

Apparently it hates it when you do this.

* Allow m.fully_read on /receipts

* Apply suggestions from code review

Co-authored-by: Matthew Hodgson <matthew@matrix.org>

Co-authored-by: Matthew Hodgson <matthew@matrix.org>
This commit is contained in:
Travis Ralston 2022-09-12 16:34:51 -06:00 committed by GitHub
parent a6990ff27c
commit e406bd94f6
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
10 changed files with 146 additions and 66 deletions

View file

@ -107,7 +107,19 @@ determined by the push rules which apply to an event.
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.
be marked as read. Note that users can send both an `m.read` and
`m.read.private` receipt, both of which are capable of clearing notifications.
If the user has both `m.read` and `m.read.private` set in the room then
the receipt which is more recent/ahead must be used to determine where
the user has read up to. For example, given an oldest-first set of events A,
B, C, and D the `m.read` receipt could be at event C and `m.read.private`
at event A - the user is considered to have read up to event C. If the
`m.read.private` receipt is then updated to point to B or C, the user's
notification state doesn't change (the `m.read` receipt is still more
ahead), however if the `m.read.private` receipt were to be updated to
event D then the user has read up to D (the `m.read` receipt is now
behind the `m.read.private` receipt).
##### Push Rules