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