From f3bf66d7f7f7d96dcf738cc67adfe2cff93399fa Mon Sep 17 00:00:00 2001 From: Timo Date: Mon, 3 Jun 2024 20:25:23 +0200 Subject: [PATCH] review --- proposals/4140-delayed-events-futures.md | 48 ++++++++++++------------ 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/proposals/4140-delayed-events-futures.md b/proposals/4140-delayed-events-futures.md index 5448fcdaa..3ff19aec3 100644 --- a/proposals/4140-delayed-events-futures.md +++ b/proposals/4140-delayed-events-futures.md @@ -4,25 +4,25 @@ Allowing to schdeule/delay events would solve numerous issues in Matrix. - Updating call member events after the user disconnected. -- Sending scheduled messages (send at a specific time) -- Creating self destructing events (By sending a delayed redact) +- Sending scheduled messages (send at a specific time). +- Creating self-destructing events (by sending a delayed redact). -Currently there is no mechanism for a client to reliably that an event is still valid. +Currently there is no mechanism for a client to reliably determine that an event is still valid. The only way to update an event is to post a new one. -In some situations the client just loses connection or fails to sent the expired -version of the event. This proposal also includes a expiration/timeout +In some situations the client just loses connection or fails to send the expired +version of the event. This proposal also includes an expiration/timeout system so that those scenarios are also covered. -We want to send an event in advance -to the homeserver but let the homeserver decide the time when its actually added to the +We want to send an event to the homeserver in advance, +but let the homeserver decide the time when its actually added to the DAG. -The condition for actually sending the delayed event would could be a timeout or a external trigger via a synapse endpoint. +The condition for actually sending the delayed event could be a timeout or a external trigger via an unauthenticated Synapse endpoint. ## Proposal To make this as generic as possible, the proposed solution is to allow sending multiple presigned events and delegate the control of when to actually send these -events to an external services. This allows to a very flexible way to mark events as expired, +events to an external service. This allows a very flexible way to mark events as expired, since the sender can choose what event will be sent once expired. We call those delayed events `Futures`. @@ -51,15 +51,15 @@ to send a list of event contents. The body looks as following: Each of the `sendEventBody` objects are exactly the same as sending a normal event. -Power levels are evaluated once one of the events will be distributed/inserted into the DAG. +Power levels are evaluated for each event only once the trigger has occurred and it will be distributed/inserted into the DAG. This implies a future can fail if it violates power levels at the time it resolves. -(Its also possible to successfylly send a future the user has no permission to at the time of sending +(Its also possible to successfully send a future the user has no permission to at the time of sending if the power level situation has changed at the time the future resolves.) -There can be an arbitrary amount of `actionName`s. +There can be an arbitrary number of `actionName`s. All of the fields are optional except the `timeout` and the `send_on_timeout`. -This guarantees that all tokens will expire eventually. +This guarantees that all tokens will eventually expire. The homeserver can set a limit to the timeout and return an error if the limit is exceeded. @@ -108,7 +108,7 @@ The homeserver does the following when receiving a Future. - If a `PUT /_matrix/client/v3/futures/refresh` is received, it **restarts the timer** with the stored timeout duration. - If a `PUT /_matrix/client/v3/futures/action/${actionName}` is received, it **sends the associated action event** - `m.action:${actionName}`. + `m.send_on_action:${actionName}`. - If the timer times out, **it sends the timeout event** `m.send_timeout`. - If the future is a state event and includes a `m.send_now` event the future is only valid while the `m.send_now` @@ -122,7 +122,7 @@ The homeserver does the following when receiving a Future. new event will always converge to the new event: - Timeout -> new event: the room state will be updated twice. once by the content of the `m.send_on_timeout` event but later with the new event. - - new event -> timeout: the new event will invalidate the future. No + - new event -> timeout: the new event will invalidate the future. - After the homeservers sends a timeout or action future event, the associated timer and `future_token` is canceled/invalidated. @@ -168,7 +168,7 @@ of the final events how they will end up in the DAG with the associated `future_ This can be used so clients can optionally display events that will be send in the future. -For self destructing messages it is recommanded to include +For self-destructing messages it is recommended to include this information in the event itself so that the usage of this endpoint can be minimized. @@ -187,9 +187,9 @@ We want can use the actions and the timeout for matrix rtc for the following sit This significantly reduces the amount of calls for the `/future` endpoint since the sfu only needs to ping once per session (per user) and every 2-5hours (instead of every `X` seconds.) -### Self destructing messages +### Self-destructing messages -This MSC also allows to implement self destructing messages: +This MSC also allows to implement self-destructing messages: `PUT /_matrix/client/v3/rooms/{roomId}/send/{eventType}/{txnId}` @@ -219,14 +219,14 @@ This MSC also allows to implement self destructing messages: > This proposes a stop gap solution. It is highly preferred to have a general batch sending solution. > Also see the **Alternatives** section -It would be useful to be able to send redactions and edits as one http request. -This would make sure that the client cannot loose connection after sending the first event. -For instance sending a self destructing message without the redaction. +It would be useful to be able to send redactions and edits as one HTTP request. +This would handle the situation where otherwise the client might lose it's connectionafter sending the first event. +For instance, sending a self-destructing message without the redaction. The optional proposal is to introduce template variables that are only valid in `Future` events. `$m.send_now.event_id` in the content of one of the `m.send_on_action:${actionName}` and `m.send_on_timeout` contents this template variable can be used. -The **Self destructing messages** example would simplify to: +The **Self-destructing messages** example would simplify to: `PUT /_matrix/client/v3/rooms/{roomId}/send/future/{txnId}` @@ -277,7 +277,7 @@ The following names for the endpoint are considered The `m.send_now` field could not be part of the future. This would also mitigate the need for the `$m.send_now.event_id` template variable. -It would come with the cost that there is no way to guarantee, taht the current state and the future are recieved by the homeserver. +It would come with the cost that there is no way to guarantee, that the current state and the future are received by the homeserver. The client would need to send the events in sequence, so the connection could be lost between the now event and the future. It is expected that this is a very rare case. @@ -307,6 +307,6 @@ even tell with which room or user it is interacting. ## Unstable prefix -use `io.element.` instead of `m.` as long as the msc is not stable. +Use `io.element.` instead of `m.` as long as the MSC is not stable. ## Dependencies