WIP: MSC3277: Scheduled messages

[ara4n]

Rendered

[turt2live]

✅ to denote read-up-to

[ShadowJonathan]

Some notes, but this is already fairly solid 👍

Imo it also would need a JSON example of a schedule message, but that's minor.

[ara4n]

@ShadowJonathan thanks for excellent review - have incorporated all feedback (i think).

[ShadowJonathan]

LGTM as-is

[ShadowJonathan]

Would it make sense to add "scheduled": true to unsigned here? Just to simplify client logic.

[kevincox]

This should only be done if the at timestamp is "reasonable". For example if the timestamp is in the past the server should probably still set origin_server_ts as it would if the event was not scheduled. For example this could occur if a scheduled message was sent while offline and the device did not come online until after the send time.

[ShadowJonathan]

The "server should clamp past time stamps" can get finicky if the clocks of the server and the client aren't synchronized.

[kevincox]

I agree but I don't think the server always trusts the client enough to pick arbitrary timestamps. This could lead to confusing behaviour. I get that this is possible over federation with a malicious server anyways but it seems like this confusing behaviour should be avoided when it is simple to do a pretty good job. We are already trusting the server clock for when to publish the message so it seems that the server slot is expected to be vaguely in sync anyways.

TL;DR if the field is called origin_server_ts the server should have the final say. I don't think it is actually too important that we require precise semantics but I think we should allow the server a clean way to avoid sending known-invalid timestamps. If you don't like clamping we can consider rejecting the message upon being queued. However this is really pushing the timestamp-guessing onto the client which is more flexible but probably suboptimal for most use-cases.

[kevincox]

Once the client queues the E2EE event they have no way of stopping the server from sending it. Of course there is always a race condition here but the server could publish at any time even if the user changes their mind. This could be somewhat mitigated by clients throwing away that key ASAP which could prevent anyone from decrypting the message.

For example consider that Alice wants to share information to Mallory, but only in 2 weeks time. If Mallory could break into Alice's server Mallory can force-send that message beforehand (or just exfiltrate that message).

However I think that in general this is the required tradeoff to allow sending the message while the client is not online.

[JMoVS]

I was almost going to write up my own proposal but then discovered this. thumbs up - this would be a really really great feature to have in business contexts!

[turt2live]

This MSC allows the server to set origin_server_ts to a future date, but if it doesn't then there's a bit of a privacy leak: https://twitter.com/soren_iverson/status/1785308725362016505 (not a real feature)

[mpeter50]

I was almost going to write up my own proposal but then discovered this. thumbs up - this would be a really really great feature to have in business contexts!

Not only in a business context, I think. I often use such messages to set up reminders using an other messaging platform.

I know this is not the proper way to do reminders, but the todo software "collection" I use across my devices often only syncs at half an hour intervals or such (and since the operation is heavy enough, I dont want it to be any more requent), so for short term reminders this is more reliable.
But then this also solves reminders for an arbitrary group of friends who are available over Matrix (and any bridged platforms), which is an additional feature even if that todo stack was quick to sync.