remove batch sending endpoint since that does not make sense in the short term and longer term send_pdus is the better solution.

toger5/expiring-events-keep-alive
Timo 1 year ago
parent 9d5c93a051
commit da3d75e5fe

@ -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:

Loading…
Cancel
Save