From da3d75e5fe339b8d9cdc1a2b973aa713afffacf3 Mon Sep 17 00:00:00 2001 From: Timo Date: Wed, 2 Oct 2024 13:21:08 +0200 Subject: [PATCH] remove batch sending endpoint since that does not make sense in the short term and longer term send_pdus is the better solution. --- proposals/4140-delayed-events-futures.md | 128 ----------------------- 1 file changed, 128 deletions(-) diff --git a/proposals/4140-delayed-events-futures.md b/proposals/4140-delayed-events-futures.md index f7447d8f3..585485116 100644 --- a/proposals/4140-delayed-events-futures.md +++ b/proposals/4140-delayed-events-futures.md @@ -516,134 +516,6 @@ Those endpoints could be called: This would allow the response for the `send` and `state` endpoints intact and we get a different return type for the new `send_delayed_event` and `state_delayed_event` endpoints. -### Batch sending delayed events with custom endpoint - -The proposed solution does not allow to send events together with delayed events that reference them with one -HTTPS request. This is desired for self-destructing events and for MatrixRTC room state events, where -we want the guarantee, that the event itself and the delayed event removing the event both reach the homeserver -with one request. Otherwise there is a risk for the client to lose connection or crash between sending the -event and the delayed event which results in never expiring call membership or never destructing self-destructing messages. -This would be solved once [MSC4080](https://github.com/matrix-org/matrix-spec-proposals/pull/4080) and the `/send_pdus` -endpoint is implemented. -(Then the `delay` could be added -to the `PDUInfo` instead of the query parameters and everything could be send at once.) - -This would be the preferred solution since we currently don't have any other batch sending mechanism. -It would however require lots of changes since a new widget action for delayed events would be needed. -With the current main proposal it is enough to add a `delay` to the send message -widget action. -The widget driver would then take care of calling `send` or `send_delayed_event` based on the presence of those fields. - -An alternative to the proposed solution that allows this kind of batch sending would be to -introduce this endpoint: -`PUT /_matrix/client/v1/rooms/{roomId}/send/delayed_event/{txnId}` - -It allows to send a list of event contents. The body looks as following: - -```jsonc -{ - "timeout": 10, - - "send_on_timeout": { - "type":type, - "content":timeout_delay_event_content - }, - - // optional - "send_on_action":{ - "${action1}": { - "type":type, - "content":action_delay_event_content - }, - "${action2}": { - "type":type, - "content":action_delay_event_content - }, - ... - }, - - // optional - "send_now": content, -} -``` - -We are sending the timeout and the group id inside the body and combine the timeout delayed event -and the action delayed event into one event. -Each of the `sendEventBody` objects are exactly the same as sending a normal -event. - -This is a batch endpoint that sends timeout and action delayed events at the same time. - -#### Batch Response - -The response will be a collection of all the delayed events with the same fields as in the initial proposal: - -```jsonc -{ - "send_on_timeout": { - "delay_id": "delay_id", - }, - // optional - "send_on_action": { - "${action1}": { "delay_id": "delay_id1" }, - "${action2}": { "delay_id": "delay_id2" } - }, - - // optional - "send_now": { "eventId": "id_hash" } -} -``` - -Working with delayed events is the same with this alternative. -This means, - -- `GET /_matrix/client/v1/delayed_events` getting running delayed events -- `POST /_matrix/client/v1/delayed_events` to canceling, restarting and sending delayed events - -uses the exact same endpoints. -Also the behaviour of the homeserver on when to invalidate the delayed events is identical except, that -we don't need the error code `409` anymore since the events are sent as a batch and there cannot be -an action delayed event without a timeout delayed event. - -#### EventId template variable - -It would be useful to be able to send redactions and edits as one HTTP request. -This would handle the cases where the delayed events need to reference the `send_now` event. -For instance, sending a self-destructing message where the redaction timeout delayed events needs -to reference the event to redact. - -For this reason, template variables are introduced that are only valid in `Future` events. -`$m.send_now.event_id` in the content of one of the `send_on_action` and -`send_on_timeout` this template variable can be used. - -The **Self-destructing messages** example be a single request: - -`PUT /_matrix/client/v1/rooms/{roomId}/send/delayed_event/{txnId}` - -```jsonc -{ - "m.send_now":{ - "type":"m.room.message", - "content":{ - "m.text": "my msg" - } - }, - "m.timeout": 10*60, - "m.send_on_timeout": { - "type":"m.room.redaction", - "content":{ - "redacts": "$m.send_now.event_id" - } - } -} -``` - -With cryptographic identities events would be presigned. -The server will first send the finalized event to the client. -At this point the client has the id but the event is not in the DAG. -So it would be trivial to sign both the event and the redaction/related event -and then send them via `/send_pdus` (see: [MSC4080: Cryptographic Identities](https://github.com/matrix-org/matrix-spec-proposals/pull/4080)). - ### Allocating the event ID at the point of scheduling the send This was considered, but when sending a delayed event the `event_id` is not yet available: