Feature: Add Support For Scheduled Messages via MSC4140

[jasonlaguidice]

Describe the problem

This feature allows users to schedule server-side messages to be sent in all rooms, provided their server supports MSC4140.

matrix-js-sdk supports MSC4140 for delayed events directly making implementation with the existing SDK pretty straightforward.

A PR was generated at #2671 with a working implementation of this feature.

Describe the solution you'd like

This adds a chevron next to the send button which opens a simple date/time picker. When selected to schedule, the send icon changes to a clock and is given a color to indicate this will schedule the message instead of send per normal. The message is sent as a delayed event using MSC4140.

Alternatives considered

N/A

Additional context

There are some limitations to this feature:

• The API doesn't provide any method to decrypt scheduled events so events in encrypted rooms can't be retrieved... only deleted
• The server has to support MSC4140 (and have a suitably large max allowable delay).

In regards to the first point - this feels like a minor UX issue but the benefits the feature adds outweigh the cons of this scenario

In regards to the second point: this one is more substantial. If a server does not support MSC4140 this feature should not appear. I've pondered on this a little bit since initial implementation and have figured I should account for situations where the server has a normal, sane max allowable delay limit and someone requests a send delay longer than the max allowable

It doesn't look like there is any way to find the server's current maximum allowable delay so at least a graceful handling of exceeding the server's limit should be added... so I did that. This is probably a lot less clean because it's been a few weeks since I implemented this change initially.

For what it's worth, I've been running a branch built off the first round of changes and everything works as I'd expect.

[kfiven]

Looking at the MSC, it looks like the spec has mainly been designed for VoIP using MatrixRTC, so I am little confused if we should even use this for scheduled messages.

[jasonlaguidice]

Looking at the MSC, it looks like the spec has mainly been designed for VoIP using MatrixRTC, so I am little confused if we should even use this for scheduled messages.

Yeah true - but after using it for a while on my own builds it works fine - messages are events like any other. If anything this results on it being a little under-baked on the spec side (like, lots of edge cases where abuse is possible... but adding this as a function within a client doesn't open up any new channels for abuse)

The MSC is intended to be used to automatically kick disconnected participants from calls. Element Call places a scheduled event in the room when it joins. The event it places is a self-part the room/call.

While the participant is connected and their client is operating correctly, the scheduled event it makes is updated every few seconds to defer the self-leave a little further. If the client disconnects, crashes, or otherwise, the scheduled event will timeout and take effect and the participant will leave the call.

So if there are concerns for harming a server using it in this way: unlikely. The intent was for each participant to update their event every couple of seconds. Adding one event as a scheduled message is a drop in the compute bucket.

Could one harm the room state? Maybe. That probably depends on the specific server implementation. But again, that's outside the scope of using the API endpoint to schedule a message event vs some other type of event.

That should hopefully provide the context of the MSC as I understand it.

In a practical sense most servers will have a pretty short max allowable event delay. I don't know what Synapse's is by default. I have my own home server's delay set very long and everything works as expected.