MSC4140: Cancellable delayed events

[toger5]

Rendered

This could also supersede MSC2228 (by making it possible to send a redaction with the /send endpoint. This is the case as mentioned here)

Implementations:

• Synapse
  • Support MSC4140: Delayed events (Futures) element-hq/synapse#17326
• Element Call running in SPA mode
  • Support MSC4140: Delayed events (Futures) matrix-js-sdk#4294
  • Bump matrix-widget-api element-hq/element-call#2529
• Element Web running Element Call in embedded mode
  • Support MSC4140: Delayed events (Futures) matrix-js-sdk#4294
  • Support sending delayed events (Futures) / MSC4157 matrix-widget-api#90
  • Bump matrix-widget-api element-hq/element-call#2529
• Element X running Element Call in embedded mode
  • Future Events: Add future endpoints to ruma. ruma/ruma#1845
  • widget-driver: Support for sending future events through the widget api. matrix-rust-sdk#3600
  • Bump matrix-widget-api element-hq/element-call#2529

[ara4n]

Suggested change

	The client can then periodically restarts the timer whilst it is running. If the client is no longer running or able
	The client can then periodically restart the timer whilst it is running. If the client is no longer running or able

[ara4n]

references to futures & /update_future are presumably stale now?

[anoadragon453]

This feature could also be useful for temporary mutes/bans/kicks, temporary invites, etc.

[toger5]

This might not be the best way to treat this. Here are my reasons why:

• It is very easy to emulate this behavior by just cancelling the delayed event before sending a new state event.
• In the matrixRTC spec I would like to argue that the order should be: send the delayed leave event FIRST and afterwards the active membership event. This guarantees that only expiring call memberships will be sent.
• I would like to replace this section with:

Suggested change

	#### Delayed state events are cancelled by a more recent state event
	If a new state event is sent to the same room with the same (event type, state key) pair as a delayed event, the delayed
	event is cancelled.
	There is no race condition here since a possible race between timeout and the _new state event_ will always converge to
	the _new state event_:
	- timeout for _delayed event_ followed by _new state event_: the room state will be updated twice: once by the content of
	the delayed event but later with the content of _new state event_.
	- _new state event_ followed by timeout for _delayed event_: the _new state event_ will cancel the outstanding _delayed event_.
	Note that this behaviour does not apply to regular (non-state) events as there is no concept of a `(type, state_key)`
	pair that could be overwritten.
	#### State which is effected by delayed events will be marked in the unsigned field
	If a state event is sent for a state key where there is already a delayed event scheduled the homeserver will add a:
	`has_delayed_overwrite: true` property to the unsigned section of the state event.
	This is not required if the delayed event is received after a normal state event.
	This allows client to check if a state event is temporal: `has_delayed_overwrite: true`.
	`m.call.member` events for instance will only be valid if they are temporal (It allows the receiving clients to evaluate if the sending client did not forget to schedule the delayed leave event.)
	The `has_delayed_overwrite: true` unsigned property is also added to delayed state events that timeout or are send into the DAG while there is another delayed event scheduled for the same state key.

[AndrewFerr]

• It is very easy to emulate this behavior by just cancelling the delayed event before sending a new state event.

This isn't true for state that can be set by other users, who don't have the option to cancel (or even know about) delayed state from someone else.

• In the matrixRTC spec I would like to argue that the order should be: send the delayed leave event FIRST and afterwards the active membership event. This guarantees that only expiring call memberships will be sent.

This is a good idea, but I believe it will work regardless of what the behaviour is for overwritten delayed state.

[AndrewFerr]

This should also define how the response should order the returned delayed events, lest the paginated results are jumbled & difficult to navigate through.

I propose sorting in order of increasing send time, i.e. running_since + delay.

[AndrewFerr]

As suggested during a review of Complement tests, this MSC should specify what happens when a user leaves a room they have pending delayed messages for.

The most "unexpected" thing to do is to cancel all delayed events for a room when leaving it.

On the other hand, not cancelling them is an option as well:

• If the user rejoins a room they had left, any of their still-pending delayed messages for that room will end up getting sent
• If the user is not in a room by the time any of their delayed messages for that room are to be sent, the event sending will simply fail with a 400-class error

The latter is in the same vein as evaluating power levels at the point of sending.

Note that the Synapse implementation does not cancel delayed events for left rooms.

[AndrewFerr]

Should users be notified of delayed events that hit power level failures (or any 400-class error) upon being sent?

If so, perhaps delayed event send failures can be included in /sync responses, for clients to handle however they like.

If not, then this spec should make it explicit that delayed event send failures are effectively unhandled.