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.

[ghost]

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.).

[ghost]

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.

[tmonz]

I'd be highly in favour of having such a feature added.

[3nprob]

It seems that in this thread there is discussion both about absolute message lifetimes (as per this issue) and self-destructing messages (#82). Just want to note that as described these are not the same feature.

#82 describes supporting MSC2228.

Lifetimes sets an expiration/destruction time at creation. After that time, the message should no longer be available. A given use-case was a "happy birthday" message which should not be sent after the birthday has passed.

@Biep would you say that this feature (lifetimes) is still relevant if #82 (ephemeral messages) is implemented?

[Biep]

Yes, very much so. But I am afraid that implementing a half-solution (only ephemeral messages) will push a thorough solution off the table. (Not unlike the way partial solutions for spaces and threads, and maybe eventually captions, will no doubt push a generic solution for grouping - that would have enabled implementing all those specific cases - off the table.)

Destruction is merely one specific aspect of message lifetimes. The whole notion of "keeping on trying to send" (part of the client-side aspect of the lifetimes proposal) is not even addressed with ephemeral messages - but I can tell you that it is vital in countries where connections are erratic. My experiences is in West-Africa, where connections come and go, and people may write tens of messages while without a connection - and then, currently, need to keep revisit all those rooms to tell Element to try again sending, until the action succeeds. Others only have connections through public WiFi, such as in supermarkets (no money for mobile Internet), and want their messages to be sent automatically when going there - but not after they have stopped being relevant.
Having a unified model for lifetimes is so much better than a set of patches for some of the more common use cases - again comparable to generic grouping vs. special-cased spaces, threads, captions, and so on.

[Hexalyse]

Have we really been discussing this for two years ? I feel like, even just ephemeral messages took ages to be implemented on some clients, even after it was implemented on Synapse. I can't even imagine how something like what you propose @Biep will take to be discussed, and eventually implemented.

But your proposal indeed sounds like a more generic and powerful solution that would allow many different use cases client-side (but this should be discussed on the Synapse repo or even on the repo for the specs of matrix since it's there that everything begins, not on Element repo which is a client).

In the meantime, I've personally stopped using matrix because of the lack of adoption by my contacts, and the pace at which it evolved compared to less privacy-friendly but way more full-featured IMs like Telegram and the like. I may come back to matrix if all those things end up implemented. I unfortunately don't feel like I have the skill level to dive into matrix server development.

[3nprob]

not on Element repo which is a client

Indeed.

I guess the next step would be to draft an MSC and file it in https://github.com/matrix-org/matrix-spec-proposals/pulls, as it would require extending the protocol.

[Biep]

That would go beyond my capabilities, I am afraid.