MSC4140: Cancellable delayed events by toger5 · Pull Request #4140 · matrix-org/matrix-spec-proposals

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

Known differences between current implementations and the proposal

The implementations use the error code M_MAX_DELAY_EXCEEDED, HTTP 400, and a response property max_delay when the server refuses to schedule an event because the requested delay is too large. The proposal has since switched to the error code M_FORBIDDEN, HTTP 403, and publishes the maximum allowed delay in the m.delayed_events capability (so that clients can discover it ahead of making the request).
The implementations use the existing endpoints /send and /state with a new query parameter delay for scheduling delayed events. The proposal has since switched to a dedicated endpoint PUT /_matrix/client/v3/rooms/{roomId}/delayed_event/{eventType}/{txnId} where the delay is included in the request body.
- The work to update the implementations was started in MSC4140: add dedicated endpoint for delayed events element-hq/synapse#19354 and MSC4140: add dedicated endpoint for delayed events matrix-js-sdk#5133. To finish it, another /versions key would be required to manage the migration from the previous unstable implementation.
The implementations use delay and max_delay rather than delay_ms and max_delay_ms.
The implementations use running_since rather than scheduled_at.
The implementations support the delegation feature by using delay_id-based authentication on the management endpoints, rather than expecting standard authentication with a user access token.

Implementations in Element Call via the Widget API

These are only informational and shouldn't be relevant for the proposal process. The MSC doesn't depend on widgets and widgets are themselves not part of the spec.

Element Call running in SPA mode
- 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:

MSC checklist

FCP tickyboxes

Designated reviewers:

Security team (requested out of band)
@anoadragon453 with Backend experience - skipped per MSC4140: Cancellable delayed events #4140 (comment)

Signed-off-by: Timo K <toger5@hotmail.de>

…is used to trigger on of the actions Signed-off-by: Timo K <toger5@hotmail.de>

Signed-off-by: Timo K <toger5@hotmail.de>

Add event type to the body Add event id template variable

Co-authored-by: Andrew Ferrazzutti <af_0_af@hotmail.com>

AndrewFerr · 2026-06-30T15:47:17Z

+If a requested delay exceeds this maximum, the homeserver will respond with HTTP 400
+and a [standard error response](https://spec.matrix.org/v1.18/client-server-api/#standard-error-response)
+with an `errcode` of `M_INVALID_PARAM`.


To go even further with #4140 (comment), how about returning M_FORBIDDEN & HTTP 403 even for this case of requesting a delay longer than allowed?

This would prevent needing a special case error response for delayed events being entirely disallowed, as both that case & this one would then both give the same response.

It also looks like the spec uses M_INVALID_PARAM only for parameter values that are always invalid (like a malformed room alias or MXID), as opposed to values that are disallowed by server config that may change later.

Erm, actually, the special case would still be needed for when the maximum per-user amount of delayed events is 0, lest the response would be M_LIMIT_EXCEEDED & HTTP 429 for a limit that can never be satisfied.

But the point stands about M_FORBIDDEN & HTTP 403 potentially being more appropriate than M_INVALID_PARAM / HTTP 400.

In the interest of progressing with the Synapse implementation of MSC4140 error codes (PR), I've committed this change as 9447ee0.

I've also updated the PR description accordingly.

But the point stands about M_FORBIDDEN & HTTP 403 potentially being more appropriate than M_INVALID_PARAM / HTTP 400.

This sounds sensible to me.

M_FORBIDDEN for a parameter exceeding a limit sounds weird, maybe it should just be a new dedicated error code instead?

A dedicated error code was the original plan, but was decided against after opting to express the max-allowed delay in a capability: #4140 (comment), #4140 (comment).

There is also precedent of the spec using M_FORBIDDEN for disallowed parameter values, like an invalid password or login token for the user-interactive login API, and an unsupported media type for the media upload endpoint.

Personally I'd err towards adding new error codes even if they're not technically necessary, rather than reusing existing codes in a potentially confusing way. I don't feel too strongly about that though, so either way is fine

an unsupported media type for the media upload endpoint

not related to this MSC, but ???? HTTP 415 exists

Also reword the special case error response now that only the 0-limit case is special

Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>

Move delegation to an alternative. It is planned to be given its own MSC.

turt2live · 2026-07-22T20:09:44Z

This looks ready for broader SCT review, even with designated review not being fully complete. SCT members are encouraged to review this MSC.

tulir · 2026-07-24T10:24:43Z

+There is no guarantee for a client that events will be available
+if they exceed the limits of their homeserver.
+Additionally, a homeserver MAY discard finalised delayed events that have been returned by a
+`GET /_matrix/client/v1/delayed_events/{delay_id}` response.


This sounds kind of dangerous from a request retrying perspective since network errors can cause responses to be lost. I guess storing finalized events is best-effort anyway and clients shouldn't rely on any of them being stored?

I guess storing finalized events is best-effort anyway and clients shouldn't rely on any of them being stored?

Correct.

Eventually, finalized delayed events should appear in /sync responses (and appservice transactions), which will reliably communicate them.

tulir · 2026-07-24T10:38:38Z

+If a requested delay exceeds this maximum, the homeserver will respond with HTTP 400
+and a [standard error response](https://spec.matrix.org/v1.18/client-server-api/#standard-error-response)
+with an `errcode` of `M_INVALID_PARAM`.


M_FORBIDDEN for a parameter exceeding a limit sounds weird, maybe it should just be a new dedicated error code instead?

tulir · 2026-07-24T10:41:57Z

+## Alternatives
+


The opening paragraph has multiple use cases, but there are also various limits that could interfere with clients actually using this for all those use cases. For example, if a server sets a low pending delayed event limit, then a client uses delayed events for self-destructing messages, would calls just fail because the user's limit is used up?

The 429 behavior is also mildly scary if clients aren't smart enough to ignore too long Retry-After fields (like if all the delayed events are for scheduled or self-destructing messages in 3 months, starting a call might just get stuck in a sleep()). That's mostly a client implementation concern though, the MSC is probably fine as is.

I'm not sure if it should be fixed in this MSC or just documented as a possible alternative/future MSC. The fix would probably be having the server tell the client what use case it's targeting so the server can have per-use-case limits

For example, if a server sets a low pending delayed event limit, then a client uses delayed events for self-destructing messages, would calls just fail because the user's limit is used up?

The 429 behavior is also mildly scary if clients aren't smart enough to ignore too long Retry-After fields (like if all the delayed events are for scheduled or self-destructing messages in 3 months, starting a call might just get stuck in a sleep()).

I suppose in cases like that, it's the client's responsibility to be proactive in checking server capabilities to verify that a desired usecase is feasible. Then all that'd be required from this MSC is to ensure that enough capabilities are exposed for such checking, which IMO they already are.

dbkr · 2026-07-27T14:43:17Z

+
+The homeserver MUST NOT send the event before the scheduled time.
+To support batch sending, homeservers MAY add up to 30 seconds to the scheduled send time.
+Note: clients might find that their events are delayed further due to server load and similar conditions.


Here might be a good place to also mention that the same rate limits will apply as if the client sent the events in the standard way at the time.

dbkr · 2026-07-27T14:47:57Z

+If a delayed event fails to be sent at its scheduled send time due to a rate limit failure,
+the homeserver SHOULD NOT retry sending the event. Instead, the event will be stored as a finalised delayed event
+with its `error` field set, available to be retrieved by a client for the user who requested the event.
+It then becomes the user's responsibility to fetch this error and retry sending the event as appropriate.


This seems odd? Why? I think I would expect it to be retried, otherwise this makes the mechanism a chunk less reliable if it might also fail permanently due to transient rate limiting.

dbkr · 2026-07-27T14:50:36Z

+### Inability to filter and paginate delayed events
+
+`GET /_matrix/client/v1/delayed_events` lacks request parameters for filtering and pagination. It also
+doesn't allow querying finalised delayed events. This could be limiting in some cases. A future proposal


It also doesn't allow querying finalised delayed events

Could you clarify this sentence - I'm not sure exactly what it's saying (unless it's fetching only finalised events, but isn't that the same as filtering?)

dbkr · 2026-07-27T14:55:42Z

+All delayed event related endpoints are available to guest accounts.
+This allows guest accounts to participate in MatrixRTC sessions.
+
+## Potential issues


A fairly significant potential issue in using this for VoIP hangups is that a client now needs to be able to make regular, timely HTTP requests to not get a call hung up. I frequently make calls in network conditions that are fine for getting UDP voice packets through but don't work for making a small HTTP request.

that's the reason why there is delegation of delayed events. In the VoIP example the media server is taking over control.

Oh right, of course - I think I was generally failing to understand that this also acts as a way for a client to effectively hand the SFU a signed and sealed envelope with a hangup event that it can send (or trigger to be sent) later. Could add a thing to clarify this maybe.

However, as it was decided to move the LiveKit Auth service into the homeserver, the initial idea of "delegation of delayed events" was cut down to be homeserver internal (e.g., app services). It's subject to a new MSC once there is demand to delegate to an external service.

Due to batch sending, scheduled send times are allowed to be delayed somewhat, making delayed events unreliable for timer usecases.

i.e. the MUST is not just one way around

clokep · 2026-08-04T00:42:32Z

+The body for requests to this endpoint is a JSON object containing the following fields:
+
+- `delay_ms` - Required. A positive non-zero number of milliseconds the homeserver should wait before sending the event.
+- `state_key` - The state key for the event to be sent, if it is to be a state event; absent otherwise.
+- `content` - Required. The content of the event to be sent.


Having a very different body than /send but the same path is very confusing.

It seems like it would be better to mirror the existing /send and /state endpoints (or not even bother with /state if it isn't needed yet).

The MSC isn't using the same path? That was an older revision, but it was replaced with a dedicated /delayed_events path

The MSC isn't using the same path?

Yes, but it purposefully mirrors the path, I think it'll be quite confusing to have completely different API shapes.

It's fine IMHO.

I guess if you wanted to mirror the existing endpoints, you'd have PUT /_matrix/client/v3/rooms/{roomId}/delayed_send/{eventType}/{txnId} and PUT /_matrix/client/v3/rooms/{roomId}/delayed_state/{eventType}/{stateKey}. I woudn't be dead against that, but I'm unconvinced it's worth changing.

Another point against having split delayed send/state endpoints is that the semantics of sending a delayed event are the same for both message & state events, unlike for non-delayed events where /send uses a transaction ID to distinguish requests while /state uses the state key.

clokep · 2026-08-04T00:43:38Z

+generated by the homeserver.
+
+The homeserver MUST NOT send the event before the scheduled time.
+To support batch sending, homeservers MAY add up to 30 seconds to the scheduled send time.


Why does this need to batch sending? It seems very at odds with the feature.

If the user (or different users) schedule multiple events at timestamps close to each other, the homeserver may want to batch the sends together for efficiency reasons

OK, that seems like an implementation detail though. I think what this is trying to say is "don't expect your event to get send at exactly the millisecond it is scheduled to, but I think that's kind of obvious?

The homeserver MUST NOT send the event before the scheduled time, but
MAY send it shortly after the scheduled send time.

clokep · 2026-08-04T00:49:19Z

+If a user's request to schedule a delayed event would exceed this limit, the homeserver will respond with HTTP 429,
+a [standard error response](https://spec.matrix.org/v1.18/client-server-api/#standard-error-response)
+with an `errcode` of `M_LIMIT_EXCEEDED`, and a `Retry-After` header whose value is set to the time of/until
+the scheduled send time of the next of the user's delayed events to be sent,
+rounded up to the nearest second.


M_USER_LIMIT_EXCEEDED seems to the the standard error code?

This should be a 400.

I think M_USER_LIMIT_EXCEEDED was introduced to deal with premium accounts; the general implication is that it's a quota you can pay to increase. Accordingly, M_LIMIT_EXCEEDED is probably appropriate here. And normally we would use a 429.

M_USER_LIMIT_EXCEEDED was considered for this, but that is meant for quota limits that can be bypassed (such as with a "premium" subscription / payment-gated feature), whereas this is a server-imposed limit for the sake of appropriate resource allocation (akin to something like a maximum file upload size limit).

See: #4140 (comment)

clokep · 2026-08-04T01:16:28Z

+The `delay_id` of a sent delayed event MUST be included in the resulting room event's `unsigned` data
+if, and only if, the client being given the event (e.g. over `/sync` or `/messages`) is authenticated as the event's sender.
+
+#### Power levels are evaluated at the point of sending


What about all the other ways events can fail validation?

Yes, this part should call out how malformed events are handled.

Synapse validates the event at the time of scheduling, as opposed to at the scheduled send time, because unlike power levels, event validation rules are unlikely to change over time. So IMO this section should at enforce at least a schedule-time validation check.

clokep · 2026-08-04T01:19:21Z

+need to account for eventual consistency anyway, which may appear as a delayed event or
+attached to a disjointed part of the DAG.
+
+### Conflicting delayed state events


Do we even need this feature for state events today? This seems like a big foot gun without a use case.

There is indeed no longer a planned usecase for delayed state events, or at least one that relies on any particular behaviour of them. f0ad189 removes this section.

clokep · 2026-08-04T01:20:37Z

+events due to federation delay. Potentially addressing this situation is, therefore, left to a future
+proposal.
+
+### Inability to filter and paginate delayed events


Leaving pagination to a future proposal is not acceptable IMO.

@mscbot concern List endpoint is unbounded and needs pagination.

The easiest solution to this may be to get rid of the list endpoint, if we don't have a usecase for it?

In any case, I'm not sure I agree. This MSC is big enough as it is, and pagination was broken out to MSC4486 deliberately. Let's just land this MSC without adding more clutter.

Agreed this is lengthy.

Moving the entire list endpoint to a separate MSC that provides all the needed filtering/pagination probably makes the most sense.

But also if there's no use-case, why include it?

The use-case is to give clients the ability to check if any delayed events failed to be sent.

Though admittedly, if a client really cares about the status of any particular delayed event, it would very likely have its delay_id on hand & use the single-item lookup to find it.

Still, it feels incomplete to not be able to simply list all available delayed events, especially now that it's contained in its own MSC.

clokep · 2026-08-04T01:24:31Z

+[^eventId]: An event's ID is computed from its [reference hash](https://spec.matrix.org/v1.18/rooms/v11/#event-ids)
+which is obtained by combining several event properties including `origin_server_ts`. The latter is
+only available once the event has actually been sent, however. Since scheduled delayed events may be
+cancelled or re-scheduled, the `origin_server_ts` and, thus, the event ID cannot be determined ahead
+of time.


Is this the only field stopping event ID calculation?

prev_events and auth_events are also not known ahead of time and we don't want to mess up the DAG

Right, those are much stronger rationale IMO. I could see it being reasonable to use the original schedule time as origin_server_ts or something like that if it was the only issue.

dbkr · 2026-08-04T12:58:32Z

@mscbot concern open comment threads

Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>

richvdh

Looks great to me.

richvdh · 2026-08-04T13:35:32Z

+The body for requests to this endpoint is a JSON object containing the following fields:
+
+- `delay_ms` - Required. A positive non-zero number of milliseconds the homeserver should wait before sending the event.
+- `state_key` - The state key for the event to be sent, if it is to be a state event; absent otherwise.
+- `content` - Required. The content of the event to be sent.


It's fine IMHO.

I guess if you wanted to mirror the existing endpoints, you'd have PUT /_matrix/client/v3/rooms/{roomId}/delayed_send/{eventType}/{txnId} and PUT /_matrix/client/v3/rooms/{roomId}/delayed_state/{eventType}/{stateKey}. I woudn't be dead against that, but I'm unconvinced it's worth changing.

richvdh · 2026-08-04T14:04:37Z

+If a user's request to schedule a delayed event would exceed this limit, the homeserver will respond with HTTP 429,
+a [standard error response](https://spec.matrix.org/v1.18/client-server-api/#standard-error-response)
+with an `errcode` of `M_LIMIT_EXCEEDED`, and a `Retry-After` header whose value is set to the time of/until
+the scheduled send time of the next of the user's delayed events to be sent,
+rounded up to the nearest second.


I think M_USER_LIMIT_EXCEEDED was introduced to deal with premium accounts; the general implication is that it's a quota you can pay to increase. Accordingly, M_LIMIT_EXCEEDED is probably appropriate here. And normally we would use a 429.

richvdh · 2026-08-04T14:19:22Z

+or if the `action` is `cancel` and the delayed event has already been sent,
+the homeserver will respond with HTTP 409
+and a [standard error response](https://spec.matrix.org/v1.18/client-server-api/#standard-error-response)
+with an `errcode` of `M_UNKNOWN`.


I'm not a big fan of us deliberately specifying M_UNNOWN here. Maybe we can define an M_CONFLICT or something.

richvdh · 2026-08-04T14:19:50Z

+If the action is `send` and the delayed event is unable to be sent due to an error,
+the homeserver will respond with that error (e.g. HTTP 403
+and a [standard error response](https://spec.matrix.org/v1.18/client-server-api/#standard-error-response)
+with an `errcode` of `M_FORBIDDEN` if the user doesn't have permission to send the event at the time of sending,


Doesn't it?

richvdh · 2026-08-04T14:56:29Z

+events due to federation delay. Potentially addressing this situation is, therefore, left to a future
+proposal.
+
+### Inability to filter and paginate delayed events


The easiest solution to this may be to get rid of the list endpoint, if we don't have a usecase for it?

richvdh · 2026-08-04T14:58:50Z

+events due to federation delay. Potentially addressing this situation is, therefore, left to a future
+proposal.
+
+### Inability to filter and paginate delayed events


In any case, I'm not sure I agree. This MSC is big enough as it is, and pagination was broken out to MSC4486 deliberately. Let's just land this MSC without adding more clutter.

as it no longer has a planned use case and is thus not worth mentioning, even as an alternative

uhoreg · 2026-08-04T16:53:59Z

+the homeserver. This includes APIs for scheduling delayed events and managing scheduled delayed
+events.
+
+[Selective Forwarding Units (SFUs)]: https://trueconf.com/blog/wiki/sfu


nit: this link reference definition seems to be orphaned

uhoreg · 2026-08-04T18:33:19Z

+`GET /_matrix/client/v1/delayed_events` responds with
+a list of details about scheduled delayed events owned by the requesting user.
+
+Delayed events are returned in chronological order of their intended send time, which is `scheduled_at` + `delay_ms`.


I assume ascending order?

Yes; I thought "chronological" also implied ascending time. If not, that can be clarified here.

uhoreg · 2026-08-04T20:53:57Z

+
+### Additional homeserver behaviour
+
+#### `delay_id` in `unsigned` event data


Does the server also include the transaction_id property in unsigned, like it does with events sent from the other event-sending endpoints?

No, because the transaction_id only distinguishes requests, not the delayed events themselves.

toger5 added 2 commits May 7, 2024 18:52

draft for expiring event PR

480b00a

Signed-off-by: Timo K <toger5@hotmail.de>

Add msc number

8839b8d

Signed-off-by: Timo K <toger5@hotmail.de>

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 <toger5@hotmail.de>

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 <toger5@hotmail.de>

AndrewFerr reviewed May 8, 2024

View reviewed changes

review andrewF

9f45cfa

Signed-off-by: Timo K <toger5@hotmail.de>

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. Process state. A-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 <toger5@hotmail.de>

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 <toger5@hotmail.de>

rename msc, rephrase introduction

53f6186

Signed-off-by: Timo K <toger5@hotmail.de>

Add usecase specific section.

087c74e

Add event type to the body Add event id template variable

MatMaul reviewed May 20, 2024

View reviewed changes

Comment thread proposals/4140-delayed-events-futures.md Outdated

add GET futures endpoint

538b853

toger5 commented May 20, 2024

View reviewed changes

Comment thread proposals/4140-delayed-events-futures.md Outdated

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

Comment thread proposals/4140-delayed-events-futures.md

Comment thread proposals/4140-delayed-events-futures.md Outdated

AndrewFerr reviewed May 23, 2024

View reviewed changes

AndrewFerr reviewed May 30, 2024

View reviewed changes

Comment thread proposals/4140-delayed-events-futures.md Outdated

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

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

c16afbc

Co-authored-by: Andrew Ferrazzutti <af_0_af@hotmail.com>

batch sending considerations

c52c80d

AndrewFerr added 2 commits June 30, 2026 11:36

Elaborate & link to criticism of shared endpoint

955ecf5

Use M_FORBIDDEN/403 for disallowed delayed events

d91a932

AndrewFerr reviewed Jun 30, 2026

View reviewed changes

Use M_FORBIDDEN/403 for exceeding the max delay

9447ee0

Also reword the special case error response now that only the 0-limit case is special

gewitternacht reviewed Jul 6, 2026

View reviewed changes

Johennes and others added 7 commits July 7, 2026 07:58

Add example for other required details for delegation

21c8961

Fix leftover conversion from /refresh to /restart

170e329

Clarify uniqueness of delay IDs

4724aa4

Clarify security aspects of delayed event delegation

5dac49c

Reword rules on access of GET /{delay_id}

b75b9fc

Clarify when to include delay_id in unsigned

2f3b817

Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>

Drop delegation; require auth on management

cd878d2

Move delegation to an alternative. It is planned to be given its own MSC.

chrislearn mentioned this pull request Jul 15, 2026

Implement MSC4140 delayed events with current API semantics palpo-im/palpo#319

Open

skycatminepokie mentioned this pull request Jul 17, 2026

Send Later/Schedule Send krille-chan/fluffychat#2686

Open

chrislearn mentioned this pull request Jul 23, 2026

Implement MSC4140 delayed events palpo-im/palpo#349

Open

tulir approved these changes Jul 24, 2026

View reviewed changes

dbkr reviewed Jul 27, 2026

View reviewed changes

AndrewFerr added 2 commits July 27, 2026 12:03

Remove tea timer usecase

e5f656b

Due to batch sending, scheduled send times are allowed to be delayed somewhat, making delayed events unreliable for timer usecases.

Clarify that enforced limits must be in capability

15770e6

i.e. the MUST is not just one way around

clokep reviewed Aug 4, 2026

View reviewed changes

Rephrase sentence

bcd8dbb

Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>

richvdh approved these changes Aug 4, 2026

View reviewed changes

Remove section on conflicting delayed state events

f0ad189

as it no longer has a planned use case and is thus not worth mentioning, even as an alternative

uhoreg reviewed Aug 4, 2026

View reviewed changes

robintown added 4 commits August 6, 2026 15:55

Remove special case for delayed event limit of 0

6c3911d

Avoid describe homeserver implementation details

fc9077a

Use a new M_DELAY_TOO_LARGE error code and HTTP 400

0c7193a

Clarify that the endpoints are scoped to users

2d42daf


		### Additional homeserver behaviour

		#### `delay_id` in `unsigned` event data

Uh oh!

Conversation

toger5 commented May 7, 2024 • edited by turt2live 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!

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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

turt2live commented Jul 22, 2026

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!

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!

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

toger5 commented May 7, 2024 •

edited by turt2live

Loading