MSC4140: Cancellable delayed events #4140
Conversation
Signed-off-by: Timo K <[email protected]>
Signed-off-by: Timo K <[email protected]>
toger5
force-pushed
the
toger5/expiring-events-keep-alive
branch
from
2bc07c4 to
0eb1abc
Compare
Signed-off-by: Timo K <[email protected]>
toger5
force-pushed
the
toger5/expiring-events-keep-alive
branch
from
0eb1abc to
8bf6db7
Compare
Signed-off-by: Timo K <[email protected]>
Signed-off-by: Timo K <[email protected]>
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 <[email protected]>
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 <[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]>
Redundant because GitHub's Markdown viewer provides its own ToC. Stale because some of the headings refered to absent sections.
but state events are still used in the MatrixRTC section
It is either the send time, or the cancel/error time
… v11 using the /send endpoint (#18898) Implement [MSC4169](matrix-org/matrix-spec-proposals#4169) While there is a dedicated API endpoint for redactions, being able to send redactions using the normal send endpoint is useful when using [MSC4140](matrix-org/matrix-spec-proposals#4140) for sending delayed redactions to replicate expiring messages. Currently this would only work on rooms >= v11 but fail with an internal server error on older room versions when setting the `redacts` field in the content, since older rooms would require that field to be outside of `content`. We can address this by copying it over if necessary. Relevant spec at https://spec.matrix.org/v1.8/rooms/v11/#moving-the-redacts-property-of-mroomredaction-events-to-a-content-property --------- Co-authored-by: Tulir Asokan <[email protected]>
| Content-Type: application/json | ||
| { | ||
| "scheduled": [ |
There was a problem hiding this comment.
Looks like this is still called delayed_events in the Synapse implementation: https://github.com/element-hq/synapse/blob/v1.140.0rc1/synapse/rest/client/delayed_events.py#L103, should mention that in the unstable prefix section. It was renamed in 904e3d6
There was a problem hiding this comment.
That deviation (among others) is being addressed by element-hq/synapse#19038.
|
|
||
| ### Managing delayed events | ||
|
|
||
| A new authenticated client-server API endpoint at `POST /_matrix/client/v1/delayed_events/{delay_id}` allows scheduled events |
There was a problem hiding this comment.
To throw this on its head a bit, could we make this unauthenticated and instead make the delay_id a more secure random string. I have a fairly strong use case:
If I am building a RTC application and I want a backend service to be in control of whether one of my events expires, then I can pass my delayed event to the server and it can control the disconnect event on my behalf. Because the delay_id is scoped to one event that the user has already consented to sending, the auth doesn't really add much if the delay_id isn't trivally guessable.
The alternative to this is the backend service would need to get either my full token or a scoped access token (via as an as-of-yet unspec'd MSC) which adds some overhead.
| data. Since the additional capability to use a template `event_id` parameter is also needed, | ||
| this probably is not a good fit. | ||
|
|
||
| ### Not reusing the `send`/`state` endpoint |
There was a problem hiding this comment.
I would highly prefer that.
- An endpoint should not return two completely different response types depending on the query parameter.
- Sending a delayed event is a different action than sending an event and should be more explicit.
| Since the delayed event is sent first, a client can guarantee (at the time they are sending | ||
| the join event) that it will eventually leave. | ||
|
|
||
| ### Self-destructing messages |
There was a problem hiding this comment.
This is a really good use case, but I see a fundamental problem in this MSC: Delayed events are not passed down the sync. So even if one device sends a self destruction, other devices of the same account would not be notified about it in the sync. Therefore other devices would always need to poll delayed_events, which breaks the concept of having the Matrix sync and would unnecessary flood the homeserver with requests.
| The primary point of rate limiting is event sending when the delay times out or the event is sent using the `send` | ||
| action. However, servers can choose to rate limit the management endpoints themselves as well if necessary. | ||
|
|
||
| ### Getting delayed events |
There was a problem hiding this comment.
This is a poll mechanism. In my opinion, we would need a push (sync) mechanism to take really advantage of this MSC and be able to introduce a bunch of new Matrix features based on it.
15 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:
SCT stuff:
checklist
FCP not yet started
Blocked: #4140 (comment)