MSC4089: Delivery Receipts #4089
Conversation
turt2live
added
proposal
| }, | ||
| "m.delivery": { | ||
| "@user:example.org": { | ||
| "ts": 1661384801651, // same as m.read[.private] |
There was a problem hiding this comment.
Since each client sends a delivery receipt, shouldn't we have one more level in here, giving device IDs?
| data limits just receiving these receipts. Servers should bundle delivery receipts to deliver them to | ||
| the client rather than sending each one individually. | ||
|
|
||
| **TODO**: Maybe we also limit size or require a client to opt-in with a filter param of some sort? |
There was a problem hiding this comment.
Random ideas:
- state event indicating whether to send delivery receipts
- only send delivery receipts in rooms up to a certain size
- sender includes a property in the event indicating whether they want to receive delivery receipts
There was a problem hiding this comment.
Feels like there could be a thing where the sending client whether they want to receive delivery receipts by sticking a property in the event, and that would be determined by settings or room size?
It feels a bit bbq v.s. banquet, and maybe things like join rules influence the likelihood that you care about receipts?
| which is currently in use only by read (or "seen") receipts. We extend this module with a new `m.delivery` | ||
| receipt to track individual events being received by the client. | ||
|
|
||
| Delivery receipts are sent by all of a user's clients to report back to the event's sender that an |
There was a problem hiding this comment.
Do delivery receipts get sent to all of the sender's devices, or just the device that sent the event?
There was a problem hiding this comment.
I think I intended this to be all of the sender's devices, but very open to opinions either way.
| data limits just receiving these receipts. Servers should bundle delivery receipts to deliver them to | ||
| the client rather than sending each one individually. | ||
|
|
||
| **TODO**: Maybe we also limit size or require a client to opt-in with a filter param of some sort? |
There was a problem hiding this comment.
Alternatively: Perhaps we could require servers to suppress delivery receipts for public and/or large rooms? This would serve as a fallback for clients that may errorneously send these events, and would also allow servers to specify an upper bound (also see: presence).
There was a problem hiding this comment.
I think we probably want to investigate this from a privacy angle rather than technical angle for now, as I'd like privacy to drive technology rather than technology drive privacy.
Co-authored-by: Denis Kasak <dkasak@termina.org.uk>
| Delivery receipts are sent by all of a user's clients to report back to the event's sender that an | ||
| event was decrypted successfully. They are not "up to" markers - they are for singular events. Other | ||
| users in the room do *not* see delivery receipts for events they didn't send. |
There was a problem hiding this comment.
This is a lot of data: (messages in a room) * (devices in a room) might be difficult to implement efficiently.
If it is doable though, might make more sense for m.read also. 🤷
There was a problem hiding this comment.
Yea, there's vague ideas about only using delivery receipts in "trusted" rooms, where the number of devices and such is likely to be fewer.
There was a problem hiding this comment.
Having causal delivery would help us to know what others know, as their event would implicitly ack everything below it (prev_events). This does come with cost of having no gaps - when you join a room you need to download everything. That's not Client's concern however, but Home Servers'. They are "public inboxes" and they could indeed require causal delivery. Could "delivery receipts" be solved this way?
| If a server receives a duplicate request to send a delivery receipt, it should 200 OK it. This is to | ||
| ensure that if a client fails to receive a response it doesn't retry forever. | ||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
Is there any interaction with message edits? Do you still consider it delivered if the initial message was?
Rendered
In line with matrix-org/matrix-spec#1700, the following disclosure applies:
Author is a Matrix Spec Core Team (SCT) member, employed by Element, and operates the t2bot.io service. However, this proposal is written and published as a SCT member working in the area of the Digital Markets Act (DMA) and similar initiatives.
Implementation requirements: