MSC4140: Delayed events #4140
MSC4140: Delayed events #4140
Conversation
Signed-off-by: Timo K <[email protected]>
Signed-off-by: Timo K <[email protected]>
2bc07c4 to
0eb1abc
Compare
Signed-off-by: Timo K <[email protected]>
0eb1abc to
8bf6db7
Compare
Signed-off-by: Timo K <[email protected]>
Signed-off-by: Timo K <[email protected]>
3e54c2a to
c82adf7
Compare
Signed-off-by: Timo K <[email protected]>
c82adf7 to
54fff99
Compare
…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
Co-authored-by: Andrew Ferrazzutti <[email protected]>
|
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 "unsurprising" 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:
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. |
| Power levels are evaluated for each event only once the delay has occurred and it will be distributed/inserted into the | ||
| DAG. This implies a delayed event can fail if it violates power levels at the time the delay passes. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
That is a really good comment.
Adding it to the sync response Sounds as if we would need to introduce a place for error messages there. Which be a very new concept I think.
What about adding it to the get delayed events endpoint.
We don't known if the client will be online if the failiour occurs so it is a very async check for errors anyways so making it part of a request does not sound too bad.
I don't know how to remove errors from the get delayed events list. Maybe as soon as they are fetched once they get removed?
Is that an issue if there are more clients getting futures?
Maybe each client should get the errors once?
There was a problem hiding this comment.
I added this into the GET endpoint.
There was a problem hiding this comment.
Would an event failure be something that a client needs to act upon? If so, the client would need to continuously poll this endpoint, which is starting to feel a lot like /sync...
| - `delay` - Optional number of milliseconds the homeserver should wait before sending the event. If no `delay` is provided, | ||
| the event is sent immediately as normal. |
There was a problem hiding this comment.
Would it be possible to support setting the absolute target time rather than relative?
I was thinking of possibly using this as a "hack" to make sure a bunch of state event changes are batched in a single federation transaction by scheduling them at a single point in time ~5-10 seconds in the future. (eg. a moderation bot doing wildcard kicks/bans, or redacting tens if not hundreds of spam messages, this would allow for far higher event throughput and reduce federation overhead, where the bot may already be exempted from rate limits)
Just a thought, no intent to block this MSC.
There was a problem hiding this comment.
The federation overhead should be the same, because the same amount of content (in your case, the moderation actions) will be sent in the request whether they're delayed or immediate events.
Unless you meant something else?
…hort term and longer term send_pdus is the better solution.
- we have two GET endpoints `/shedueled` `/terminated` now. - The rule for when a state delayed event is cancelled changed to include a sender user condition.
No significant changes since 1.117.0rc1. - Add config option `redis.password_path`. ([\#17717](element-hq/synapse#17717)) - Fix a rare bug introduced in v1.29.0 where invalidating a user's access token from a worker could raise an error. ([\#17779](element-hq/synapse#17779)) - In the response to `GET /_matrix/client/versions`, set the `unstable_features` flag for [MSC4140](matrix-org/matrix-spec-proposals#4140) to `false` when server configuration disables support for delayed events. ([\#17780](element-hq/synapse#17780)) - Improve input validation and room membership checks in admin redaction API. ([\#17792](element-hq/synapse#17792)) - Clarify the docstring of `test_forget_when_not_left`. ([\#17628](element-hq/synapse#17628)) - Add documentation note about PYTHONMALLOC for accurate jemalloc memory tracking. Contributed by @hensg. ([\#17709](element-hq/synapse#17709)) - Remove spurious "TODO UPDATE ALL THIS" note in the Debian installation docs. ([\#17749](element-hq/synapse#17749)) - Explain how load balancing works for `federation_sender_instances`. ([\#17776](element-hq/synapse#17776)) - Minor performance increase for large accounts using sliding sync. ([\#17751](element-hq/synapse#17751)) - Increase performance of the notifier when there are many syncing users. ([\#17765](element-hq/synapse#17765), [\#17766](element-hq/synapse#17766)) - Fix performance of streams that don't change often. ([\#17767](element-hq/synapse#17767)) - Improve performance of sliding sync connections that do not ask for any rooms. ([\#17768](element-hq/synapse#17768)) - Reduce overhead of sliding sync E2EE loops. ([\#17771](element-hq/synapse#17771)) - Sliding sync minor performance speed up using new table. ([\#17787](element-hq/synapse#17787)) - Sliding sync minor performance improvement by omitting unchanged data from incremental responses. ([\#17788](element-hq/synapse#17788)) - Speed up sliding sync when there are many active subscriptions. ([\#17789](element-hq/synapse#17789)) - Add missing license headers on new source files. ([\#17799](element-hq/synapse#17799)) * Bump phonenumbers from 8.13.45 to 8.13.46. ([\#17773](element-hq/synapse#17773)) * Bump python-multipart from 0.0.10 to 0.0.12. ([\#17772](element-hq/synapse#17772)) * Bump regex from 1.10.6 to 1.11.0. ([\#17770](element-hq/synapse#17770)) * Bump ruff from 0.6.7 to 0.6.8. ([\#17774](element-hq/synapse#17774))
Also define a sync filter
|
Given element-call is the default VOIP solution in EX clients, and I CONSTANTLY have to help people to get calls unstuck (so often that I had to write up instructions on how toresolve them at https://sspaeth.de/2025/02/how-to-resolve-stuck-matrixrtc-calls/ :-). |
Fixes high severity vulnerability *exploited in the wild*! # Synapse 1.127.1 (2025-03-26) ## Security - Fix [CVE-2025-30355](https://www.cve.org/CVERecord?id=CVE-2025-30355) / [GHSA-v56r-hwv5-mxg6](GHSA-v56r-hwv5-mxg6). **High severity vulnerability affecting federation. The vulnerability has been exploited in the wild.** # Synapse 1.127.0 (2025-03-25) No significant changes since 1.127.0rc1. # Synapse 1.127.0rc1 (2025-03-18) ### Features - Update [MSC4140](matrix-org/matrix-spec-proposals#4140) implementation to no longer cancel a user's own delayed state events with an event type & state key that match a more recent state event sent by that user. ([\#17810](element-hq/synapse#17810)) ### Improved Documentation - Fixed a minor typo in the Synapse documentation. Contributed by @karuto12. ([\#18224](element-hq/synapse#18224)) ### Internal Changes - Remove undocumented `SYNAPSE_USE_FROZEN_DICTS` environment variable. ([\#18123](element-hq/synapse#18123)) - Fix detection of workflow failures in the release script. ([\#18211](element-hq/synapse#18211)) - Add caching support to media endpoints. ([\#18235](element-hq/synapse#18235)) ### Updates to locked dependencies * Bump anyhow from 1.0.96 to 1.0.97. ([\#18201](element-hq/synapse#18201)) * Bump bcrypt from 4.2.1 to 4.3.0. ([\#18207](element-hq/synapse#18207)) * Bump bytes from 1.10.0 to 1.10.1. ([\#18227](element-hq/synapse#18227)) * Bump http from 1.2.0 to 1.3.1. ([\#18245](element-hq/synapse#18245)) * Bump sentry-sdk from 2.19.2 to 2.22.0. ([\#18205](element-hq/synapse#18205)) * Bump serde from 1.0.218 to 1.0.219. ([\#18228](element-hq/synapse#18228)) * Bump serde_json from 1.0.139 to 1.0.140. ([\#18202](element-hq/synapse#18202)) * Bump ulid from 1.2.0 to 1.2.1. ([\#18246](element-hq/synapse#18246))
No significant changes since 1.127.0rc1. - Update [MSC4140](matrix-org/matrix-spec-proposals#4140) implementation to no longer cancel a user's own delayed state events with an event type & state key that match a more recent state event sent by that user. ([\#17810](element-hq/synapse#17810)) - Fixed a minor typo in the Synapse documentation. Contributed by @karuto12. ([\#18224](element-hq/synapse#18224)) - Remove undocumented `SYNAPSE_USE_FROZEN_DICTS` environment variable. ([\#18123](element-hq/synapse#18123)) - Fix detection of workflow failures in the release script. ([\#18211](element-hq/synapse#18211)) - Add caching support to media endpoints. ([\#18235](element-hq/synapse#18235)) * Bump anyhow from 1.0.96 to 1.0.97. ([\#18201](element-hq/synapse#18201)) * Bump bcrypt from 4.2.1 to 4.3.0. ([\#18207](element-hq/synapse#18207)) * Bump bytes from 1.10.0 to 1.10.1. ([\#18227](element-hq/synapse#18227)) * Bump http from 1.2.0 to 1.3.1. ([\#18245](element-hq/synapse#18245)) * Bump sentry-sdk from 2.19.2 to 2.22.0. ([\#18205](element-hq/synapse#18205)) * Bump serde from 1.0.218 to 1.0.219. ([\#18228](element-hq/synapse#18228)) * Bump serde_json from 1.0.139 to 1.0.140. ([\#18202](element-hq/synapse#18202)) * Bump ulid from 1.2.0 to 1.2.1. ([\#18246](element-hq/synapse#18246))
|
MSCs proposed for Final Comment Period (FCP) should meet the requirements outlined in the checklist prior to being accepted into the spec. This checklist is a bit long, but aims to reduce the number of follow-on MSCs after a feature lands. SCT members: please check off things you check for, and raise a concern against FCP if the checklist is incomplete. If an item doesn't apply, prefer to check it rather than remove it. Unchecking items is encouraged where applicable. Checklist:
|
Rendered
This could also supersede MSC2228 (by making it possible to send a redaction with the
/sendendpoint. This is the case as mentioned here)Implementations:
SCT stuff:
checklist
FCP not yet started