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:
parent
a6990ff27c
commit
e406bd94f6
10 changed files with 146 additions and 66 deletions
|
@ -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
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue