Element-web: Message lifetimes

[Biep]

Self-destructing messages have been asked several times, but I think a more general framework is useful. Every message has:

• a moment W it is written;
• a moment F from which it is to be sent - equals W by default,
• a moment T after which it is no longer to be sent - equals D by default, and
• a moment D after which it is to be destroyed - equals infinity by default.

That way I can write messages in advance (e.g. birthday greetings), and be sure they will be sent during the birthday (if there is connection).
In places where connections are unreliable, one currently needs to keep trying to send, which is tiring. Especially when one has written some dozens of messages in different rooms, it is cumbersome to go to all those rooms and click "retry sending" whenever the connection seems restored.
I see many people return to WhatsApp for that reason (especially in West-Africa - the other huge reason there is push-to-talk, which is invaluable for analphabetes). If one can tell Riot to keep trying to send the message (from F till T), life would become much easier.

It should be possible to set defaults at the various hierarchical levels, including per thread, per room, per community, and global.

[iav]

Seems logic should be client-server distributed.
Scheduled and limited-lifetime messages should be handled mainly by server, and tiny part (only on first client-server) of delivery workflow.
Client-side part of logic shrinks to UI and "retry sending until success or end of lifetime".

[Biep]

There are various ways to implement "burn after read". Given that there might be many potential readers, it cannot burn at the server until it has burned at all room members. This would not be a mere natural extension of lifetimes, but require a separate logic.
At the lifetime side, it would mean having a token other than a moment or infinity for D.

[Hexalyse]

Ephemeral messages feature have already been merged into Synapse : https://github.com/matrix-org/synapse/pull/6409

So I guess it shouldn't be too hard to implement it in the clients, now.