MSC4140: Cancellable delayed events - #4140
Conversation
0eb1abc to
8bf6db7
Compare
turt2live
changed the title
turt2live
added
proposal
c82adf7 to
54fff99
Compare
Co-authored-by: Hugh Nimmo-Smith <hughns@users.noreply.github.com>
Co-authored-by: Hugh Nimmo-Smith <hughns@users.noreply.github.com>
95c855f to
f3bf66d
Compare
96409b1 to
412464a
Compare
412464a to
1140ce9
Compare
…ions but not entirely disconnected
Use spec-provided example of an invalid `/send` request
Kept you waiting, huh?
Section used the opposite term that it should have used
Never say just "finalised events"
No need to be strict, but still be clear that there is not much use in including the `transaction_id` field
Highlight that using the M_FORBIDDEN response is optional (with MAY). Also restore version of the special case that considers both the max delay limit & max scheduled limit, now that the former went back to using an errcode distinct from M_FORBIDDEN.
richvdh
left a comment
richvdh
left a comment
There was a problem hiding this comment.
My current thoughts on this MSC (recorded as much as a memo to future-me as anyone else):
I think this is all basically fine, though there are still a few open threads from various reviewers. Thanks to those threads, there is still a fair amount of flux on the proposal. It therefore feels a little easy to add my approval for FCP.
Co-Authored-By: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
|
@mscbot resolve List endpoint is unbounded and needs pagination. |
Instead just say more clearly that the error returned is the same as what would have been returned for a non-delayed event request
Network errors on the endpoint would cause responses to be lost if they were to be discarded by the server
| [capability](https://spec.matrix.org/v1.19/client-server-api/#capabilities-negotiation) named `m.delayed_events`, via | ||
| the values of non-negative integer valued fields named `max_delay_ms` and `max_scheduled` respectively. | ||
| For any of these limits enforced by the server, its representative field MUST be present in the capability. | ||
| If the server doesn't enforce one of these limits, its representative field MUST be absent from the capability. |
There was a problem hiding this comment.
This framing does mean it's impossible for a server to say that delayed events are disabled. I'm not sure that is something we want to support, but equally feels odd. I'm not sure if it's worth doing anything about it though
There was a problem hiding this comment.
It can communicate disabled delayed events by responding with:
{
"capabilities": {
"m.delayed_events": {
"max_delay_ms": 0,
"max_scheduled": 0
}
}
}Even including only one of the max_ fields would be sufficient, as it's enough for either one of them to be 0 to mean that delayed events are disabled.
Does that cover your concern?
There was a problem hiding this comment.
Mmm, true I suppose. Though if we want clients to consider 0 to mean disabled then that's something we should be specific. While technically a limit of 0 is the same, it needs to be handled specially by clients (i.e. this operation will never work no longer how long we wait).
OTOH I'm not sure if we want to allow delayed events to be disabled by the server? I guess that is the fundamental question, and we should either explicitly allow or deny 0 as the limit.
(This is a very low severity thing)
There was a problem hiding this comment.
While technically a limit of 0 is the same, it needs to be handled specially by clients (i.e. this operation will never work no longer how long we wait).
Aha, this is what that "special case" I was banging on about was for. It landed as ec7cbfd.
OTOH I'm not sure if we want to allow delayed events to be disabled by the server?
IMO there's no harm to allow disabling it, especially if server configs already allow you to constrain it (why not allow constraining it all the way to 0?).
As another point, this section should also specify what clients should assume if the m.delayed_events capability is absent entirely (not just its fields).
af63014 does so, and also explicitly specifies what 0 limits mean.
There was a problem hiding this comment.
I suppose managing delayed events will cause some amount of load on the server. I suppose it's low but technically allowing an admin to disable it seems reasonable to me.
Even if we don't allow 0. A value of 1ms would still mean the feature is effectively disabled from a client's perspective.
Evaluate at both schedule & send time Co-authored-by: Erik Johnston <erik@matrix.org>
|
@mscbot resolve open comment threads |
for the sake of consistency
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
/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.delay_id.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:
MSC checklist
FCP tickyboxes
Designated reviewers: