MSC2388: Toward the EDU-to-PDU transition: Read Receipts. #2388

tulir · 2019-12-18T18:47:21Z

Signed-off-by: Jason Volk <[email protected]>

Sorunome · 2020-01-11T15:59:33Z

It seems like a rather bad idea to have read receipts in the timeline.

yangm97 · 2020-01-14T02:01:22Z

proposals/2388-edu-as-pdu--receipt.md

+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.


Speaking of replacing stuff, I suppose this proposal could describe that previous m.read events should be replaced by the latest versions, using the improved redactions, which I believe would allow servers/clients to skip/not store forever previous versions.

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.

#447 and #1763 come to my mind.

#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.

yangm97 · 2020-01-14T02:02:03Z

It seems like a rather bad idea to have read receipts in the timeline.

Care to elaborate? We have avatar changes registered on every room a user participates, this seems much more pertinent to the room than that.

turt2live · 2020-01-14T02:29:26Z

Please use threads on the diff so people can reply, thank you.

Sorunome · 2020-01-14T14:48:05Z

proposals/2388-edu-as-pdu--receipt.md

+### 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.


Care to elaborate? We have avatar changes registered on every room a user participates, this seems much more pertinent to the room than that.

(replying in a thread for easier future replies)

m.read doesn't seem like something you'd want in your timeline for permanent storage. It is irrelevant in the future when which user read what. So storing this information permanently is an unnecessary overhead, which could cause problems down the line, especially with clients in e.g. embedded enviroments which can't handle that many events.

Using PDUs doesn't imply in permanent storage, per se. See my review above.

Destructing events for m.read also seems like a bad idea as, if you e.g. don't log in for a week, suddenly all your read indicators are off.

In sorus opinion sticking with EDUs seems like the best option here.

Destructing events for m.read also seems like a bad idea as, if you e.g. don't log in for a week, suddenly all your read indicators are off.

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.

In sorus opinion sticking with EDUs seems like the best option here.

It seems to me that improved redactions made EDUs redundant, which is why there's some movement to push that away from the protocol.

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.

Sounds like you are trying to re-create EDUs here, so why not take the existing model that works?

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.

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).

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.

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.
It might be useful to have a distinction between small groupchats and large public channels, because the semantics are very different for a lot of things.

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.

ara4n · 2020-01-15T00:01:48Z

proposals/2388-edu-as-pdu--receipt.md

+
+### Problem
+
+In practice, implementations treat read-receipt EDU's no different than other PDU messages. Upon


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.

we simply don't want to clog up the DAG with irrelevant data

What do you think of #2388 (comment) ?

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.

KitsuneRal · 2020-01-11T19:03:05Z

proposals/2388-edu-as-pdu--receipt.md

+### 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


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.

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).

Well, that's still inaccurate even for server-side implementations, since persistence does not imply adding things to DAG.

KitsuneRal · 2020-01-20T00:38:41Z

proposals/2388-edu-as-pdu--receipt.md

+### 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.


The way read receipts are implemented now, be they PDUs or EDUs, you cannot reliably tell if a user has read all messages between two states of a given user's read receipt; there's a good chance that they've read some messages before the read receipt but that's really it. A very prominent example: if a person marks all messages as read that doesn't mean they actually have read them, despite the fact that the very next message they actually seen and possibly read will carry a read receipt. If you need a reliable confirmation of reading (e.g., to have a user formally confirm that they have read the message, it should be a separate event type (obviously a PDU, very likely in m.relation to the message event that's been read).

ara4n · 2020-04-20T22:09:03Z

As the author says in the MSC, read receipts are currently special cased because we expect an order of magnitude more of them than messages themselves on average. Winding back that optimisation without good reason seems undesirable.

From the comments, there look to be two genuine use cases here though:

The ability to send arbitrary EDUs
The ability to track read state on a per message basis.

I suggest someone opens a new MSC for sending arbitrary EDUs. Meanwhile, I suggest we leave this one open to cover "track read state on a per message basis", although of all the features missing from Matrix today, I'm not convinced that's one that's holding back uptake of the protocol.

turt2live · 2020-04-20T22:14:02Z

@ara4n Custom ephemeral events has an MSC already: #2477

MSC2388: Toward the EDU-to-PDU transition: Read Receipts.

e89fb74

Signed-off-by: Jason Volk <[email protected]>

turt2live added proposal A matrix spec change proposal proposal-in-review labels Dec 18, 2019

tulir mentioned this pull request Dec 18, 2019

MSC2390: On the EDU-to-PDU transition. #2390

Closed

yangm97 reviewed Jan 14, 2020

View reviewed changes

Sorunome reviewed Jan 14, 2020

View reviewed changes

ara4n reviewed Jan 15, 2020

View reviewed changes

KitsuneRal reviewed Jan 20, 2020

View reviewed changes

turt2live added the kind:feature MSC for not-core and not-maintenance stuff label Apr 20, 2020

turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021

turt2live force-pushed the old_master branch from e895827 to dca99ee Compare August 30, 2021 22:34

KitsuneRal mentioned this pull request Dec 22, 2021

MSC3582: Remove m.room.message.feedback #3582

Merged

turt2live removed the proposal-in-review label May 5, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MSC2388: Toward the EDU-to-PDU transition: Read Receipts. #2388

MSC2388: Toward the EDU-to-PDU transition: Read Receipts. #2388

tulir commented Dec 18, 2019 •

edited

Loading

Sorunome commented Jan 11, 2020

yangm97 Jan 14, 2020

uhoreg Jan 15, 2020 •

edited

Loading

yangm97 Jan 18, 2020

uhoreg Jan 19, 2020

yangm97 commented Jan 14, 2020

turt2live commented Jan 14, 2020

Sorunome Jan 14, 2020

yangm97 Jan 14, 2020

Sorunome Jan 14, 2020

yangm97 Jan 14, 2020

Sorunome Jan 14, 2020

KitsuneRal Jan 20, 2020

deepbluev7 Jan 21, 2020

KitsuneRal Jan 21, 2020

ludwigbald May 13, 2020

KitsuneRal May 15, 2020

ara4n Jan 15, 2020

yangm97 Jan 15, 2020

yangm97 Jan 18, 2020

KitsuneRal Jan 11, 2020

tulir Jan 20, 2020

KitsuneRal Jan 20, 2020

KitsuneRal Jan 20, 2020

ara4n commented Apr 20, 2020

turt2live commented Apr 20, 2020

		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.


		### Problem

		In practice, implementations treat read-receipt EDU's no different than other PDU messages. Upon

MSC2388: Toward the EDU-to-PDU transition: Read Receipts. #2388

Are you sure you want to change the base?

MSC2388: Toward the EDU-to-PDU transition: Read Receipts. #2388

Conversation

tulir commented Dec 18, 2019 • edited Loading

Sorunome commented Jan 11, 2020

Choose a reason for hiding this comment

uhoreg Jan 15, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yangm97 commented Jan 14, 2020

turt2live commented Jan 14, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ara4n commented Apr 20, 2020

turt2live commented Apr 20, 2020

tulir commented Dec 18, 2019 •

edited

Loading

uhoreg Jan 15, 2020 •

edited

Loading