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 : matrix-org/synapse#6409

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

[Biep]

I certainly hope they will go the whole way, and not "satisfice" by merely adding the ephemeral character.

[xanoni]

A few inputs, so we can skip one or two iterations (from here):

1. Let's allow users to define their own intervals (X hours, X days, X weeks) instead of giving just 3-5 options. It doesn't cost much to allow this flexibility. People have different preferences and needs. (Signal has added this after people kept asking for it.)
2. Let's allow users to make this the default for all conversations. (Signal has added this after people kept asking for it.)
3. Let's explain to users in the settings what this is NOT (i.e., most home servers don't actually delete the messages, thus it is critical that E2E encryption is also used).

[Biep]

Having finite lifetimes for most messages also keeps the server loads lower, and will lead to messages that are worth it remaining longer. Right now at intervals all old messages are removed to reclaim space, but if most people have finite lifetimes as a default, the need for such drastic measures is much lower.

It would be extremely helpful if deleted messages would be overwritten, so that recovery is impossible. I'm not sure if this is already planned or if I'm missing something, but just saying. I think it's crucial to the use case of message lifetimes, as this feature will attract a lot of activists who may not be aware of this risk.

[KopfKrieg]

It would be extremely helpful if deleted messages would be overwritten, so that recovery is impossible.

I just want to point out that overwriting data is on nearly all currently used flash-media useless (due to life-prolonging measures of the media like wear-leveling, and also due to the nature of the used filesystem, which may also implement features like wear-leveling, or copy-on-write, etc.).

Oh, thanks for the info! It would be great then if there would be some technique that would make recovery more difficult.

[Biep]

And also - one only has command over one's own computer. Others may ignore any request to delete. And back-ups and archives will typically not be adapted, so the deletion is inherently unsafe.

[crti]

I would love to invite contacts to the Matrix/Element world (from Signal or WA) but features like disappearing messages after a custom timeframe are essential IMHO. Haven't understood much about the difference server and group member apps and a false "sense of security", I think even if working only on the member apps this would be important. Hope in the next months an introduction will be possible, so that Element has a chance to catch up to Signal at least.