MSC4140: Cancellable delayed events#4140
Conversation
Signed-off-by: Timo K <toger5@hotmail.de>
Signed-off-by: Timo K <toger5@hotmail.de>
toger5
force-pushed
the
toger5/expiring-events-keep-alive
branch
from
2bc07c4 to
0eb1abc
Compare
Signed-off-by: Timo K <toger5@hotmail.de>
toger5
force-pushed
the
toger5/expiring-events-keep-alive
branch
from
0eb1abc to
8bf6db7
Compare
Signed-off-by: Timo K <toger5@hotmail.de>
Signed-off-by: Timo K <toger5@hotmail.de>
turt2live
changed the title
turt2live
added
proposal
toger5
force-pushed
the
toger5/expiring-events-keep-alive
branch
from
3e54c2a to
c82adf7
Compare
Signed-off-by: Timo K <toger5@hotmail.de>
toger5
force-pushed
the
toger5/expiring-events-keep-alive
branch
from
c82adf7 to
54fff99
Compare
…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>
The bulk lookup no longer includes finalised delayed events, so note that the returned items won't have fields exclusive to finalised events.
The bulk lookup no longer includes finalised delayed events, so don't include it in the regex of endpoints that may discard a finalised event upon retrieving it. Now only the single-item lookup may do this.
|
|
||
| #### `delay_id` in `unsigned` event data | ||
| 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 is authenticated as the event's sender. |
There was a problem hiding this comment.
Could you help me understand this, please ? The unsigned data is part of the PDU sent to the room, correct ? Its content does not depend on the client receiving it.
There was a problem hiding this comment.
The unsigned data is part of the PDU sent to the room, correct ? Its content does not depend on the client receiving it.
Not quite; servers can restrict which fields of a persisted event that a client may receive. Prior art is how various CS-API endpoints withhold an event's transaction ID from all but the user who sent the event. This is codified in the spec as responses that include a transaction_id field "if the client being given the event is the same one which sent it."
There was a problem hiding this comment.
I see. It would be helpful if the spec (and also this MSC) were a bit more clear on how this is done. As it's currently specified, this result could be achieved by putting the field in the PDU and then having the homeserver filter it out if needed when sending it to the client; or by not putting it in the PDU, and having the homeserver add it if needed when sending it to the client.
If I understand you correctly, it should be the first one ?
There was a problem hiding this comment.
If I'm not mistaken, PDUs are solely for server-server communication, and thus they don't need to carry delay_ids at all due to delayed events not being federated.
As it's currently specified, this result could be achieved by putting the field in the PDU and then having the homeserver filter it out if needed when sending it to the client
This is pretty much how it's done in Synapse now, except the event is stored as ad-hoc internal representation instead of a "formal" PDU. When formatting the event in responses, the server decides which fields to include depending on the user requesting it.
to be consistent with how most other specced timestamp-valued fields have a name ending in `_ts`
|
|
||
| The body for requests to this endpoint is a JSON object containing the following fields: | ||
|
|
||
| - `delay` - Required. A positive non-zero number of milliseconds the homeserver should wait before sending the event. |
There was a problem hiding this comment.
Is there any interest in renaming this to delay_ms, to make it crystal clear that the value is in milliseconds?
If this were to be renamed, then so too should the delay field in responses to the GET endpoints.
Additionally, the max_delay in the new capability would then benefit from being renamed to max_delay_ms.
For comparison, the names of most other specced millisecond-valued fields/parameters end with _ms, with the following exceptions:
- the
unsigned.agefield in events (ref) - the
timeoutquery parameter for/sync(ref)- Amusingly, there is also a parameter named
timeout_msused by the Content Repository module (ref)
- Amusingly, there is also a parameter named
- the
info.durationfield inm.audio&m.videoevents (ref) - the
lifetimefield inm.call.inviteandm.call.negotiateevents (ref) - the
timeoutbody parameter in/typing/{userId}(ref) - The
last_active_agofield inm.presenceevents (ref)
|
|
||
| ### Alternative to `running_since` field | ||
|
|
||
| Some alternatives for the `running_since` field on the `GET` response are: |
There was a problem hiding this comment.
At the risk of bikeshedding, how does scheduled_at sound? Or at least something suffixed with _at, which the spec uses for a few other timestamp-valued fields.
I also feel that scheduled_at is less likely than scheduled_ts to be misinterpreted as the intended send time of the event, and thus is a good opportunity to put scheduled in the name, which is an existing keyword used elsewhere in this module, instead of having to introduce a new term (like "running" or "created").
20 participants
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
Known differences between current implementations and the proposal
M_MAX_DELAY_EXCEEDEDand a response propertymax_delaywhen the server refuses to schedule an event because the requested delay is too large. The proposal has since switched to the error codeM_INVALID_PARAMand publishes the maximum allowed delay in them.delayed_eventscapability (so that clients can discover it ahead of making the request)./sendand/statewith a new query parameterdelayfor scheduling delayed events. The proposal has since switched to a dedicated endpointPUT /_matrix/client/v3/rooms/{roomId}/delayed_event/{eventType}/{txnId}where the delay is included in the request body./versionskey would be required to manage the migration from the previous unstable implementation.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.
SCT stuff:
checklist
FCP not yet started
Blocked: #4140 (comment)