MSC4300: Processing status requests & responses

[Johennes]

Rendered

[turt2live]

Implementation requirements:

• Sending client
• Receiving client (with support)
• Receiving client (without support)

[benkuly]

Shouldn't it be m.status.request and m.status.response like the m.key.verification.* events?

[Johennes]

Hm, good question. My assumption was that there might be further specialized request types in future – as in requests that ask for something else than the processing status. Therefore, I made request the namespace. I have no concrete examples in mind, however, and don't feel strongly about the naming either.

[Johennes]

I think that could be helpful but it seems to solve a slightly different problem.

My assumption was that the sender would only add status requests on events that, for one reason or another, are important. Things such as prescriptions or sick notices where the content is not just plain text and where as the sender I need to make sure that you have actually understood and processed the event correctly. That means the majority of events would not include status requests which made adding it on the sender side appear acceptable.

Only sending the status response when an event was not understood would mean that the only signal of successful processing is the absence of a response. But then you won't know if the recipient didn't respond because it understood the event or if it simply hasn't received and processed the event yet.

[denis-loh]

To understand the flow correctly:

1. client A wants to know, if the room members understand my message "m.pizza" by sending the pizza.
2. client B may or may not respond with a room event stating if the message was supported

My concern with this approach is, that it potentially causes unnecessary responses and or transfers data, which may not be needed if the counterpart does not understand it.

So to keep the metaphor: if I am sending the pizza without knowing if it will be eaten, I am likely wasting lots of food over the time. However, if I use m.request.status as its own room event like a knock-on event to ask if someone wants pizza, I first of all can reduce the initial overhead and can then also cover those clients, who did not respond that they implicitly don't want pizza.

I understand that the tradeoff of that is that the sending client must wait for the clients to confirm they understand that message first, but keeping the lifetime of the request much lower (e.g. 5 - 10 seconds) you can confirm two things: 1. the client supports the message and 2. if there's no response from a client, he either doesn't support it or isn't interested (e.g. polling or questionnaire messages). The latter is especially interesting, when no-one in the room actually understands the message: if no client supports it, there is no need to send the data at all, which is likely more data privacy compliant. More specifically, if a client responds to a request immediately, it may conflict with the users privacy settings, if he doesn't want to send read receipts (https://spec.matrix.org/v1.16/client-server-api/#receipts).

Also if client A already send a request and got a specific response from the other clients, he may cache the response if to is solely being used for identification of message type support.

[Johennes]

This proposal is meant to enable clients to understand if something they have sent was understood by the recipients. You are correct in that, on its own, this doesn't provide clients a way to determine if something will be understood by others before actually sending it. This part is covered in MSC4301. That proposal defines an ahead-of-time capability query which itself uses the request status mechanism from this proposal here.

[denis-loh]

But in that case, MSC4301 and MSC4300 are directly depending on each-other, which is not immediately clear to the readers. Without the MSC4301, I still have privacy concerns as data might get transferred without acknowledgement and it's to some extend unclear how it mitigates the issue "did you understood my message?" if the other client does not implement this feature. The response event will only be sent, if the client is online, which comes with two downsides:

1. if the client is offline, the sender will not get notified, which could mean, that either the client does not support the MSC or that the recipient hasn't read the message yet.
2. if the client is online, the recipient may still not support the message or doesn't want to propagate any "online" state.

So, in neither of these cases, the sending client will ever receive the requested response, which in turn might lead to the question again "have you understood my message?"

[Johennes]

But in that case, MSC4301 and MSC4300 are directly depending on each-other, which is not immediately clear to the readers.

I have tried to make the relationship between these proposals clearer with cda5d2c.

Without the MSC4301, I still have privacy concerns as data might get transferred without acknowledgement [...]

Sending the m.response.status event is a MAY under this proposal. So clients and users with privacy concerns are free to not send it, only send it after explicit user confirmation or send it automatically but with some random jitter time¹.

[...] it's to some extend unclear how it mitigates the issue "did you understood my message?" if the other client does not implement this feature. The response event will only be sent, if the client is online, which comes with two downsides:

1. if the client is offline, the sender will not get notified, which could mean, that either the client does not support the MSC or that the recipient hasn't read the message yet.

2. if the client is online, the recipient may still not support the message or doesn't want to propagate any "online" state.

So, in neither of these cases, the sending client will ever receive the requested response, which in turn might lead to the question again "have you understood my message?"

Yes, the mechanism in this proposal is best-effort only and won't work perfectly in all situations. A specific case where we expect it to work well is when two automated systems exchange data via Matrix. The online state should not be a concern in this situation.

I'm happy to hear about alternatives though if you can think of any.

Footnotes

1. In the gematik fork of the Matrix spec, we're planning to make responses mandatory. You're right in that this leaks metadata. I think that's a comment for https://github.com/gemSpecComment/Draft_gemF_TI-M_Strukturierte_Daten/issues rather than here though because that requirement doesn't exist in this proposal. ↩