MSC4140: Cancellable delayed events #4140

toger5 · 2024-05-07T16:52:35Z

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
Element X running Element Call in embedded mode

SCT stuff:

checklist

FCP not yet started

~~Blocked: #4140 (comment)~~

Signed-off-by: Timo K <[email protected]>

proposals/4140-expiring-events-with-keep-alive-endpoint.md

Signed-off-by: Timo K <[email protected]>

…is used to trigger on of the actions Signed-off-by: Timo K <[email protected]>

Signed-off-by: Timo K <[email protected]>

Add event type to the body Add event id template variable

proposals/4140-delayed-events-futures.md

Co-authored-by: Andrew Ferrazzutti <[email protected]>

proposals/4140-delayed-events-futures.md

Redundant because GitHub's Markdown viewer provides its own ToC. Stale because some of the headings refered to absent sections.

but state events are still used in the MatrixRTC section

proposals/4140-delayed-events-futures.md

It is either the send time, or the cancel/error time

… v11 using the /send endpoint (#18898) Implement [MSC4169](matrix-org/matrix-spec-proposals#4169) While there is a dedicated API endpoint for redactions, being able to send redactions using the normal send endpoint is useful when using [MSC4140](matrix-org/matrix-spec-proposals#4140) for sending delayed redactions to replicate expiring messages. Currently this would only work on rooms >= v11 but fail with an internal server error on older room versions when setting the `redacts` field in the content, since older rooms would require that field to be outside of `content`. We can address this by copying it over if necessary. Relevant spec at https://spec.matrix.org/v1.8/rooms/v11/#moving-the-redacts-property-of-mroomredaction-events-to-a-content-property --------- Co-authored-by: Tulir Asokan <[email protected]>

tulir · 2025-10-13T09:51:54Z

proposals/4140-delayed-events-futures.md

+Content-Type: application/json
+
+{
+  "scheduled": [


Looks like this is still called delayed_events in the Synapse implementation: https://github.com/element-hq/synapse/blob/v1.140.0rc1/synapse/rest/client/delayed_events.py#L103, should mention that in the unstable prefix section. It was renamed in 904e3d6

e2af939

That deviation (among others) is being addressed by element-hq/synapse#19038.

Half-Shot · 2025-10-19T16:03:44Z

proposals/4140-delayed-events-futures.md

+
+### Managing delayed events
+
+A new authenticated client-server API endpoint at `POST /_matrix/client/v1/delayed_events/{delay_id}` allows scheduled events


To throw this on its head a bit, could we make this unauthenticated and instead make the delay_id a more secure random string. I have a fairly strong use case:

If I am building a RTC application and I want a backend service to be in control of whether one of my events expires, then I can pass my delayed event to the server and it can control the disconnect event on my behalf. Because the delay_id is scoped to one event that the user has already consented to sending, the auth doesn't really add much if the delay_id isn't trivally guessable.

The alternative to this is the backend service would need to get either my full token or a scoped access token (via as an as-of-yet unspec'd MSC) which adds some overhead.

We discussed this out of band and decided it was a good idea, right @fkwp ?

benkuly · 2025-10-21T12:00:56Z

proposals/4140-delayed-events-futures.md

+data. Since the additional capability to use a template `event_id` parameter is also needed,
+this probably is not a good fit.
+
+### Not reusing the `send`/`state` endpoint


I would highly prefer that.

An endpoint should not return two completely different response types depending on the query parameter.

Sending a delayed event is a different action than sending an event and should be more explicit.

Its about the send body bein equivalent in both requests.
Sticky events also take the exact same appraoch.

I think the opinion on this very much depends on your mental model of delayed events

they are normal event sending actions but with a configurable increase in latency (it will take the hs a little bit to send the event anyways, you can just further delay this manually)

This endpoint schedules sth that is not a matrix event yet. Its a new entity that eveutally becomes a matrix event.

I like the first view on it since it makes it easier to justify how this is compatible with matrix and why this probably wont change anything fundamental (matrix already needs to be capable dealing with differen network delays)

As an SDK developer, I prefer a type safe API. It would've been helpful to have this natively in Matrix instead making a workaround at the SDK level to get type-safety. At the end, I will provide a type safe API to the user anyway.

benkuly · 2025-10-21T12:06:54Z

proposals/4140-delayed-events-futures.md

+Since the delayed event is sent first, a client can guarantee (at the time they are sending
+the join event) that it will eventually leave.
+
+### Self-destructing messages


This is a really good use case, but I see a fundamental problem in this MSC: Delayed events are not passed down the sync. So even if one device sends a self destruction, other devices of the same account would not be notified about it in the sync. Therefore other devices would always need to poll delayed_events, which breaks the concept of having the Matrix sync and would unnecessary flood the homeserver with requests.

I don't think there's any need to know about delayed events in that context. The sender creates the delay, other devices don't care. Beeper already implements disappearing messages like that.

If this is just about the user experience and communicating your intent to only let this message life for X minutes, that seems like an easy addition in a new MSC. A content fieled: "scheduled_redaction_ms" could be used to share when you plan to let this message disappear and clients can render some UI around that.

This is off topic, but if a burn on read semantic (in a DM) is desired. one could even go as far as sharing a link with a scoped token that sends the delayed redaction. So once received the receiver can than delete the message by sending the redaction scheduled by the sender of the message.

What I am trying to say, this MSC supports all the fundamentals for a really good self-destruction implementation. I am not sure it needs fundamental changes, but maybe some metadata on top is reaquired to check of UX features.
But this MSC proposes the general delayed event logic and is not specific to self-destructing messages.

other devices don't care

If that is the case, do we need the polling api GET delayed_events? (we could close this thread, because the other is regarding the same topic)

Querying delayed events is necessary for other things like scheduled messages even though it's not needed for disappearing messages. Scheduled messages don't need a push mechanism, it's enough to be able to view and manage scheduled events when the user navigates to a specific view inside a room.

If this is just about the user experience and communicating your intent to only let this message life for X minutes, that seems like an easy addition in a new MSC. A content fieled: "scheduled_redaction_ms" could be used to share when you plan to let this message disappear and clients can render some UI around that.

This is indeed how Beeper works (using a com.beeper.disappearing_timer object) and that'll probably be MSC'd at some point

benkuly · 2025-10-21T12:09:23Z

proposals/4140-delayed-events-futures.md

+The primary point of rate limiting is event sending when the delay times out or the event is sent using the `send`
+action. However, servers can choose to rate limit the management endpoints themselves as well if necessary.
+
+### Getting delayed events


This is a poll mechanism. In my opinion, we would need a push (sync) mechanism to take really advantage of this MSC and be able to introduce a bunch of new Matrix features based on it.

Similar to the above.
There even is a follow up msc moving this into the sync block.
But your comments implicitly ask the question who should be able to access the list of scheduled delayed events: "The sender" vs "All room members". Right now the idea is that only the sender knows about their schedueld delayed events. (A dag like federated data exachange is required to sync inforamtion to all room members on other homeservers so sharing a schedueld delayed event is not as trivial, there is a reason matrix writes things into a room dag.)

The current MSC only ever exposes the scheduled delayed events to the sender.
This also has privacy/security advantages.
Whenever it is desired to share shedued data with the room metadata in the conetent of antoher room event should be used.

This might be worth explicitly mentioning in the MSC.

I hope this approach makes sense and coveres all of the usecases you have in mind?

I don't expect to share delayed_events between users, but between devices of the same user (like account data). If we don't want that, which is totally okay, do we want an endpoint to get all delayed_events on an account base.

The other problem I see is, that the MSC suggest a new endpoint for getting delayed_events. It is poll based. As far as I know in Matrix there is no other data structure, that needs polling. What is the use case to poll delayed_events instead of syncing them? Why this "downgrade" regarding the Matrix push-first principle.

There is a follow up MSC to include it in sync (sorry that i confused user vs room delayed events sharing)
The "all devices for one user" push/sync based system has been moved to that msc:
#4309

The reason was to make this msc simpler.

It does only include finalized delayed events. So your point of syncing schedules to all devices via a push semantic is very valid.

What do you think about moving/discussing this functionality to the other MSC?

(It sadly is still in draft)

Also: - split them into one endpoint per management action - propose alternative of OAuth 2.0 scoped access for the endpoints

and list it as what the Synapse implementation currently uses

Half-Shot · 2025-10-27T16:47:30Z

proposals/4140-delayed-events-futures.md

 ```

-Where the `action` is `send`, the homeserver **should** apply rate limiting to provide mitigation against the
+These endpoints are unauthenticated so that control over a particular delayed event may be


Rough implementation at https://github.com/element-hq/synapse/compare/hs/delayed-event-anonymous?expand=1

toger5 added 2 commits May 7, 2024 18:52

draft for expiring event PR

480b00a

Signed-off-by: Timo K <[email protected]>

Add msc number

8839b8d

Signed-off-by: Timo K <[email protected]>

toger5 force-pushed the toger5/expiring-events-keep-alive branch from 2bc07c4 to 0eb1abc Compare May 7, 2024 17:03

add security consideration and alternatives

8bf6db7

Signed-off-by: Timo K <[email protected]>

toger5 force-pushed the toger5/expiring-events-keep-alive branch from 0eb1abc to 8bf6db7 Compare May 8, 2024 15:49

alternative name and alternative content

8ec6374

Signed-off-by: Timo K <[email protected]>

AndrewFerr reviewed May 8, 2024

View reviewed changes

review andrewF

9f45cfa

Signed-off-by: Timo K <[email protected]>

turt2live changed the title ~~Draft for expiring event PR~~ MSC4140: Expiring events with keep alive endpoint May 9, 2024

turt2live added proposal A matrix spec change proposal client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels May 9, 2024

toger5 force-pushed the toger5/expiring-events-keep-alive branch from 3e54c2a to c82adf7 Compare May 10, 2024 17:54

draft of iteration two (after meeting with the backend team)

54fff99

Signed-off-by: Timo K <[email protected]>

toger5 force-pushed the toger5/expiring-events-keep-alive branch from c82adf7 to 54fff99 Compare May 10, 2024 18:08

toger5 added 3 commits May 13, 2024 16:56

timeout_refresh_token is not a well description since the same token …

abdfe1c

…is used to trigger on of the actions Signed-off-by: Timo K <[email protected]>

rename msc, rephrase introduction

53f6186

Signed-off-by: Timo K <[email protected]>

Add usecase specific section.

087c74e

Add event type to the body Add event id template variable

MatMaul reviewed May 20, 2024

View reviewed changes

proposals/4140-delayed-events-futures.md Outdated Show resolved Hide resolved

add GET futures endpoint

538b853

toger5 commented May 20, 2024

View reviewed changes

proposals/4140-delayed-events-futures.md Outdated Show resolved Hide resolved

toger5 added 2 commits May 21, 2024 15:13

shorten introduction

f7a1aad

add alternative section to not include the m.send_now field

f5f4b38

AndrewFerr mentioned this pull request May 22, 2024

MSC3757: Restricting who can overwrite a state event #3757

Closed

AndrewFerr reviewed May 22, 2024

View reviewed changes

proposals/4140-delayed-events-futures.md Outdated Show resolved Hide resolved

proposals/4140-delayed-events-futures.md Outdated Show resolved Hide resolved

AndrewFerr reviewed May 23, 2024

View reviewed changes

AndrewFerr reviewed May 30, 2024

View reviewed changes

proposals/4140-delayed-events-futures.md Outdated Show resolved Hide resolved

toger5 and others added 2 commits May 31, 2024 09:20

Update proposals/4140-delayed-events-futures.md

c16afbc

Co-authored-by: Andrew Ferrazzutti <[email protected]>

batch sending considerations

c52c80d

richvdh reviewed Oct 1, 2025

View reviewed changes

proposals/4140-delayed-events-futures.md Outdated Show resolved Hide resolved

richvdh reviewed Oct 1, 2025

View reviewed changes

proposals/4140-delayed-events-futures.md Outdated Show resolved Hide resolved

AndrewFerr added 13 commits October 1, 2025 08:16

Use opaque identifier grammar for delay_id

6afd0f3

Merge /scheduled and /finalised as query params

1359f2b

Allow GET endpoint to filter on ID

59392f2

Tweak wording/spelling/format

f167eb4

Move delayed state event cancelling to alternative

3efecea

Move M_CANCELLED_BY_STATE_UPDATE out of main spec

4bb8929

Tweak spelling/format

24d1c7d

Remove rendundant & stale table of contents

2f4a73a

Redundant because GitHub's Markdown viewer provides its own ToC. Stale because some of the headings refered to absent sections.

Tweak formatting & wording of status section

33af637

Don't return 400 for multiple status parameters

76d015a

Reduce emphasis on state events

cdcddd2

but state events are still used in the MatrixRTC section

Fix swapped links to /send and /state

d6c065e

Update all spec links to v1.16

0a18141

AndrewFerr reviewed Oct 9, 2025

View reviewed changes

proposals/4140-delayed-events-futures.md Outdated Show resolved Hide resolved

AndrewFerr reviewed Oct 9, 2025

View reviewed changes

proposals/4140-delayed-events-futures.md Outdated Show resolved Hide resolved

AndrewFerr added 4 commits October 10, 2025 01:52

Fix typo

a53f83f

Always require origin_server_ts on finalised evts

eb0a504

It is either the send time, or the cancel/error time

Limit cached finalised events per user, not global

9db8058

Apply batch size to not just finalised events

c19a394

tulir reviewed Oct 13, 2025

View reviewed changes

Half-Shot reviewed Oct 19, 2025

View reviewed changes

Note deviations in Synapse implementation

e2af939

benkuly reviewed Oct 21, 2025

View reviewed changes

MadLittleMods mentioned this pull request Oct 24, 2025

MSC4140: finalised delayed events, and more element-hq/synapse#19038

Open

3 tasks

AndrewFerr added 2 commits October 27, 2025 12:20

Reintroduce unauthed management for delegation

061dd56

Also: - split them into one endpoint per management action - propose alternative of OAuth 2.0 scoped access for the endpoints

Mention single-URL management as an alternative

79aeaf5

and list it as what the Synapse implementation currently uses

Half-Shot reviewed Oct 27, 2025

View reviewed changes


		### Managing delayed events

		A new authenticated client-server API endpoint at `POST /_matrix/client/v1/delayed_events/{delay_id}` allows scheduled events

Uh oh!

MSC4140: Cancellable delayed events #4140

Are you sure you want to change the base?

MSC4140: Cancellable delayed events #4140

Uh oh!

Conversation

toger5 commented May 7, 2024 • edited by richvdh Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tulir Oct 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tulir Oct 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

benkuly Oct 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

toger5 commented May 7, 2024 •

edited by richvdh

Loading

tulir Oct 21, 2025 •

edited

Loading

tulir Oct 21, 2025 •

edited

Loading

benkuly Oct 21, 2025 •

edited

Loading