MSC2388: Toward the EDU-to-PDU transition: Read Receipts. #2388
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,23 @@ | ||
| # MSC2388 - Read-Receipt PDU type | ||
|
|
||
| ### Background | ||
|
|
||
| Receipts are a feature in Matrix intended for clients to acknowledge a message. The only type of | ||
| receipt at present is the m.read read-receipt for when the user has seen a message. This feature | ||
| is specified as an EDU such that the reliability of their transmission is not guaranteed and there | ||
| is no record of them. They were designed this way because an order of magnitude more receipts are | ||
| expected by this system than other PDU messages. | ||
|
|
||
| ### Problem | ||
|
|
||
| In practice, implementations treat read-receipt EDU's no different than other PDU messages. Upon | ||
| reception they must be persisted for effective client synchronization. Implementations also employ | ||
|
There was a problem hiding this comment. That's an inaccurate statement. Notably, Quotient doesn't persist read receipts - it keeps them in memory but as soon as it's restarted, it loads a new map of read receipts from the server, not caring at all (why would it?) about the track record of read receipts. There was a problem hiding this comment. It's probably referring to the server. As you just said, you rely on the server to persist the "ephemeral" events (since it's obviously unacceptable from an UX PoV for read receipts to disappear when the client is restarted). There was a problem hiding this comment. Well, that's still inaccurate even for server-side implementations, since persistence does not imply adding things to DAG. |
||
| additional complexity to transmit prior EDU's to other servers long after they were received. | ||
| These implementation choices were made to provide a consistent, expected user experience, where | ||
| the same receipts render the same for everyone. That consistency is beneficial to the social | ||
| atmosphere. | ||
|
|
||
| ### Solution | ||
|
|
||
| We specify the Event type m.receipt. Within the content of this event, an m.relates_to with a | ||
| rel_type of m.read provides and replaces the functionality of the existing receipt EDU. | ||
|
Comment on lines
+22
to
+23
There was a problem hiding this comment. Speaking of replacing stuff, I suppose this proposal could describe that previous There was a problem hiding this comment. What improved redactions? I'm not aware of any proposal to change redactions, other than adding a mass-redactions API, which AFAIK doesn't change how redactions work. There was a problem hiding this comment. #1763 only deals with time-limited messages, which would not work well for read receipts; read receipts "expire" when replaced by another one, rather than after a certain amount of time. This would be more applicable to typing notifications, though I suspect that the servers would still need to keep a bunch of information about the event, so that the DAG doesn't have random holes in it that would prevent the room from working correctly. There was a problem hiding this comment.
(replying in a thread for easier future replies)
There was a problem hiding this comment. Using PDUs doesn't imply in permanent storage, per se. See my review above. There was a problem hiding this comment. Destructing events for In sorus opinion sticking with EDUs seems like the best option here. There was a problem hiding this comment.
Assuming self destructing events, correct? What if instead of self destructing read indicators simply replace the previous, regardless of which one your server/client has currently resolved.
It seems to me that improved redactions made EDUs redundant, which is why there's some movement to push that away from the protocol. There was a problem hiding this comment.
Sounds like you are trying to re-create EDUs here, so why not take the existing model that works? There was a problem hiding this comment. It does but I don't think it stores those receipts in a DAG - too much of a hassle for a centralised service. I'm also really unsure how many people actually look at the list of message readers (I only did it out of curiosity and never needed it). And the current MSC doesn't describe such new semantics. In fact, in doesn't really describe any changes in the semantics at all so I struggle to understand how such new receipts would work end-to-end. There was a problem hiding this comment. If I mark a room as read, I usually make sure, that I have at least read all the mentions. So while read receipts aren't an exact way to see if someone read the message, you can at least use them to ping someone again, if they sent a read receipt but didn't act on the message in the way you expected. So I think read receipts are good enough for that, if they are actually persisted (and don't just get replaced on the next sync, since I may want to check, if the person actually marked the message as read a few hours ago and not just a few seconds ago). There was a problem hiding this comment. I can buy that in the context of a, say, a direct chat, or a very small (<10 members) room; but in that case (specifically for messages you want to track attention on) you might equally just ask the person whether they've seen the message and what they can say to it. My perception is that this is a fairly corner case (How often did you really miss such function?) and it doesn't justify a rather sweeping change; and the MSC doesn't really elaborate neither on use cases, nor on consequences of such change. To rephrase: there might be merit in such change but from the text of the MSC it's terribly hard to see any because it doesn't mention neither use cases, nor consequences of the change; neither for the spec texts (you cannot just name an event a PDU, you have to define a new schema), nor for clients and servers. There was a problem hiding this comment. I look at read receipts in WhatsApp all the time. Like I'm sending out a link to a jitsi call and I want to know whether people didn't read it or just don't want to join. There was a problem hiding this comment. Yeah, I'd probably agree that's a good case for more persistent read receipts but not for every message and, probably, not visible for everyone (not in "large public channels", one they become a thing in its own right in Matrix). Somewhat resembles an e-mail with a request for read confirmation. |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
read receipts are (currently) treated fundamentally differently; you only have to track the most recent place that a user has read up to (or possibly in future, the ranges of events that they've read over, but it's still aggregated data you end up persisting). you don't care about modelling the full history of precisely when they read up to which point.
My same concerns apply as for /~https://github.com/matrix-org/matrix-doc/pull/2389/files#r366632795 - we simply don't want to clog up the DAG with irrelevant data.
This could make sense if EDUs didn't exist... but they do, and for good reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think of #2388 (comment) ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It just came to me that you may, in fact, want to store read receipts for every message, forever, in order to achieve reliable and verifiable auditorium room (equivalent of telegram channels) view counters.