From bf5df9b002215cbcf8518a8c1f0afe0a66559066 Mon Sep 17 00:00:00 2001 From: Timo Date: Thu, 10 Jul 2025 16:06:07 +0200 Subject: [PATCH] fix synapse and MSC inconsistency --- proposals/4140-delayed-events-futures.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/proposals/4140-delayed-events-futures.md b/proposals/4140-delayed-events-futures.md index 30d5e7bb2..e4eb7284c 100644 --- a/proposals/4140-delayed-events-futures.md +++ b/proposals/4140-delayed-events-futures.md @@ -736,7 +736,15 @@ Some alternatives for the `running_since` field on the `GET` response are: All new endpoints are authenticated. -Servers **should** impose a maximum timeout value for delay timeouts of not more than a month. +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) + +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. + +Its the homeserver implementers responsibility to communicate this and educate the server hosters about the tradeoffs +and potentially give sane example values for those configurations. As described [above](#power-levels-are-evaluated-at-the-point-of-sending), the homeserver **must** evaluate and enforce the power levels at the time of the delayed event being sent (i.e. added to the DAG).