From fd94c18f85987977aa2313bec8ce5b6fc7590fcd Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Fri, 26 Sep 2025 13:59:37 +0300 Subject: [PATCH] Editorial fixes * remove link to MSC4143 text that will probably break when the MSC is merged * add missing words to M_NOT_FOUND case * allow ratelimiting on management endpoints * mandate limits without mandating using a config file * add stable feature flag * allow rounding delays Signed-off-by: Tulir Asokan --- proposals/4140-delayed-events-futures.md | 31 ++++++++++++------------ 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/proposals/4140-delayed-events-futures.md b/proposals/4140-delayed-events-futures.md index cdcb6f9a0..3f091ff02 100644 --- a/proposals/4140-delayed-events-futures.md +++ b/proposals/4140-delayed-events-futures.md @@ -70,9 +70,8 @@ that the participant has left. The motivation for this MSC is to allow updating call member state events after the user disconnected by allowing to schedule/delay/timeout/expire events in a generic way. -The ["reliability requirements for the room state"](https://github.com/matrix-org/matrix-spec-proposals/blob/toger5/matrixRTC/proposals/4143-matrix-rtc.md#reliability-requirements-for-the-room-state) -section of [MSC4143: MatrixRTC](https://github.com/matrix-org/matrix-spec-proposals/pull/4143) has more details on the -use case. +The "reliability requirements for the room state" section of +[MSC4143: MatrixRTC](https://github.com/matrix-org/matrix-spec-proposals/pull/4143) has more details on the use case. There are numerous possible solution to solve the call member event expiration. They are covered in detail in the [Use case specific considerations/MatrixRTC](#use-case-specific-considerations) section, because they are not part @@ -109,8 +108,8 @@ endpoints. The new query parameter is used to configure the event scheduling: -- `delay` - Optional number of positive non-zero milliseconds the homeserver should wait before sending the event. If no `delay` is provided, -the event is sent immediately as normal. +- `delay` - Optional number of positive non-zero milliseconds the homeserver should wait before sending the event. If + no `delay` is provided, the event is sent immediately as normal. The body of the request is the same as it is currently. @@ -126,6 +125,8 @@ Content-Type: application/json } ``` +The server MAY round the delay up to a maximum of 30 seconds away from the request. + The homeserver can optionally enforce a maximum delay duration. If the requested delay exceeds the maximum, the homeserver can respond with a [`400`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400) status code and a body with a new Matrix error code `M_MAX_DELAY_EXCEEDED` and the maximum allowed delay (`max_delay` in milliseconds). @@ -190,15 +191,10 @@ Where the `action` is `send`, the homeserver **should** apply rate limiting to p Once a delayed event has been sent or canceled, it is finalized and cannot be accessed via this endpoint. -The server will return a `M_NOT_FOUND` error. - -Managing the delayed events does not require rate limits. -The rate limits will be applied when evets are send after the delay times out (or when the event is send by calling `send`). +The server will return a `M_NOT_FOUND` error if the `delay_id` is not recognized. -If the user has scheduled a large amount of delayed events they can cancel all of them without rate limiting, -because scheduling of the events itself is rate limited this is not causing issues. -Implementers should make cancelling delayed events similarly -expensive as sending a rate limit error response. +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 the management endpoints themselves as well if necessary. ### Getting delayed events @@ -736,9 +732,8 @@ Some alternatives for the `running_since` field on the `GET` response are: All new endpoints are authenticated. -To mitigate the risk of users flooding the delayed events database, servers **must** make it possible to configure -the values for the maximum amount and the maximum timeout value for scheduled delayed events. -(When the server returns the `M_MAX_DELAYED_EVENTS_EXCEEDED` and the `M_MAX_DELAY_EXCEEDED` error) +To mitigate the risk of users flooding the delayed events database, servers MUST impose limits on the number and +timeout duration of scheduled delayed events. The exact limits are left as an implementation detail. It is the server maintainers responsibility to evaluate the best tradoff between what usecases their users have for delayed events for and the resources they are able to provide. @@ -836,6 +831,10 @@ the key `org.matrix.msc4140` set to `true`. So, the response could then look as } ``` +Once the MSC is accepted, but before the server advertises the spec version that includes the MSC, the server should +advertise `org.matrix.msc4140.stable` as an unstable feature flag to let clients know that they can use the stable +endpoints for sending and managing delayed events. + ## Dependencies None.