From f5f4b380495ff957b362469a187f15c88eed2638 Mon Sep 17 00:00:00 2001 From: Timo Date: Wed, 22 May 2024 18:13:58 +0200 Subject: [PATCH] add alternative section to not include the `m.send_now` field --- proposals/4140-delayed-events-futures.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/proposals/4140-delayed-events-futures.md b/proposals/4140-delayed-events-futures.md index c1401c251..83cef996a 100644 --- a/proposals/4140-delayed-events-futures.md +++ b/proposals/4140-delayed-events-futures.md @@ -262,6 +262,20 @@ The following names for the endpoint are considered - DelayedEvents - RetardedEvents +--- + +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. +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. + +Sequence wise it might make sense to not include the `m.send_now` in this +msc and solve the topic by a good and flexible batch sending solution +independent of this PR. (then the future and the event could be sent in one batch giving the same result as the `m.send_now` field) + ## Security considerations We are using an unauthenticated endpoint to refresh the expirations. Since we use @@ -281,4 +295,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. + ## Dependencies