Self-destructing/disappearing messages

[ajvsol]

This is obviously not a foolproof security measure because clients can be modified to not redact previously sent messages for example, but a recent thread has given some examples on why this is a useful feature nonetheless.

[Disappearing messages] are a collaborative feature for conversations where all participants want to automate minimalist data hygiene, not for situations where your contact is your adversary — after all, if someone who receives a disappearing message really wants a record of it, they can always use another camera to take a photo of the screen before the message disappears.

https://whispersystems.org/blog/disappearing-messages/

I just had an interesting conversation with a friend who was recommending that I use Telegram/Wickr, and I told him that Signal was where it's at. Then he asked me if it had self-destructing messages, and I said "Why bother? That can be easily circumvented". His reply was that in some countries phones had been confiscated, and even though one person had enabled local encryption, the user with the confiscated phone had not enabled it; thereby implicating everyone who had communicated with that person (even though the messages were delivered secure over the network). So while self-destructing messages are in many ways a flawed guarantee of privacy, they can perform a very useful function in cases where the users are not malicious, but rather are security ignorant (i.e. most people with a phone).

https://whispersystems.discoursehosting.net/t/automatically-disappearing-messages/473/18

I've always been thinking that the critique of such a feature is based on a false underlying premise.

Yes, it's true that the recipient can make a screenshot of the message. But the recipient in the absolute majority of cases is not a "threat" in a classical sense, not someone with bad intentions or someone who is not supposed to know the contents of that message. After all, the sender trusts the recipient, as he is the one sending the message to the recipient in the first place.

The usual scenario is a recipient who is not that security-aware and doesn't think about those things that much if at all. Personally, I'd say most of my contact are that way.

The sender might send this recipient a message containing something especially critical, say, a user name and a corresponding password, and doesn't want to see that information in the wrong hands if e. g. later on, the recipient loses their phone, the phone gets stolen, etc. Also note that this kind of recipient is unlikely to use a general passphrase for Signal as this lessens convenience.

https://whispersystems.discoursehosting.net/t/automatically-disappearing-messages/473/10

I think OWS are hard at work trying to convey this as a convenience rather than as a security measure. Their explanation of why you should use it seems a bit weird, but it is at least better than claiming that you have any control over a message you send to another person.

I really think that they should frame it as a data retention measure between mutually trusting parties. In most countries deleting messages once a criminal investigation has started is a criminal offence. If you operate either in an environment where high data security is a priority or when you are at the outskirts of the law (or in a country where the law "applies arbitrarily" disfavouring opponents of the government) a clear and openly communicated data retention policy is a must.

The pirate bay guys probably wouldn't have been convicted if they had one in place.

https://www.reddit.com/r/crypto/comments/5706th/disappearing_messages_for_signal/d8ojhg2/

[kythyria]

These features should be as obnoxious to use as possible, because over-use will be amazingly annoying and encourage the development of homeservers and clients that completely ignore them.

[ajvsol]

Annoying for who? I can't think of a possible reason to make the feature hard to use.

Some people want full conversation history, some want only the last X minutes/hours/days/weeks/months. Or they just want certain conversations (rooms) to have this option. Some do it for privacy, others to keep their homeserver tidy with no maintenance.

As for implementation, I'd follow Signal and have a configurable self-destruct timer in room settings with a timer icon under each message.

[kyrias]

Thing is that you cannot ever rely on a feature like that to do anything since it would be incredibly easy to change your server to not care about the setting, and the more they're used the more likely it's going to be for there to be a popular client/server fork that doesn't follow it, because most other people doesn't want random messages just disappearing out of the blue.

So if you rely on something like this for privacy, you're bound to get bitten in the ass from the false sense of security. If anything what would be more useful is to use encrypted rooms and for clients to have a button for destroying the keys it has for a room, and then both parties could destroy the keys to read old messages that way.

[ghost]

An idea: allow Synapse home servers to set an option whether to delete redacted/self-destructed messages or not and visibly show information about this in every user's info.

[MurzNN]

Implement self-destructing message at first we can via bot with admin rights, that will delete (redact) all messages older than specific time. And if this will be popular - implement in Matrix client interface.

And additional server option for homeserver owners in Synapse 'Remove deleted (redacted) message from homeserver database' with warning 'Acts only on current homeserver database, deleted messages may kept on other homeservers with disabled this option'.

[t3chguy]

It can't be done in a matrix client, because what if your client is offline then your messages wouldn't be removed. Bot would be fine as that'd be online all the time

[MurzNN]

Here is issue about Matrix room history purge bot turt2live/matrix-wishlist#81

[Nostradamos]

It can't be done in a matrix client, because what if your client is offline then your messages wouldn't be removed. Bot would be fine as that'd be online all the time

Depends on when you want to destroy the messages. For example telegram deletes them after a user had read the message. So this would be more of an "destroy x time after read". This behaviour could also not be implemented in a bot, because the bot would need to redact device/user specific messages.

[mtausig]

I'm afraid, disappearing messages in Matrix would be quite a bit more complicated or less user friendly then in Signal. Signal deletes messages only locally on the phones while Matrix redaction works on the server.

Thus the Signal behaviour of Delete message on A's phone x minutes after A has read it won't work. We could only do Delete message in the root x minutes after everyone has read it. And even that breaks completely, if there is an inactive user in the room or any user has disabled Read notifications.

So we would probably need not one, but two timers to be set. One for every user has read the message and one (longer) fallback, where the message gets deleted no matter who has read it.

[ara4n]

there's a proposal for this now at matrix-org/matrix-spec-proposals#1763

[aaronraimist]

New proposal is matrix-org/matrix-spec-proposals#2228

[Thatoo]

and an other one here, merged into develop : matrix-org/synapse#6409

[ara4n]

that's not a proposal, that's the implementation ;P

[Thatoo]

even better then 😃

[MurzNN]

So it released in Synapse 1.7.0rc1, now waiting implementation in Riot UI?

[Cartasiane]

Any news / Things that can be done to push the making of this feature???

[droptile]

I fully understand that self destructing messages are not a silver bullet, but I am totally in support of their addition. There are many cases where the attacker isn't a l33t hacker but just someone who picks up your phone that was left unlocked playing a youtube video and scrolls through your messages. Being able to ensure that only 1 week, or 1 day, or 1 hour of recent messages exist on the participants devices (or at least on your own device) is a valuable privacy feature.

[rriemann]

This is an important feature for companies to improve their GDPR compliance. In GDPR, storing personal data without time limit is against the data minimisation and storage limitation principle.

https://gdpr.algolia.com/gdpr-article-5

When companies offer chat via matrix amongst employees – possibly on company-provided managed phones –, the problem of non-trusted servers does not apply. It is a closed environment. Imagine:

1. a video call with job applicants. For ease of use, you may want to reuse a room with a fixed address without keeping applicant data forever.
2. a room to decide on the next common coffee break. I do not want that people can scroll back months to study my coffee breaks.
3. a room to send holiday greetings. I do not want those greetings (possibly with picture) retained forever. 1 week would be good.

[Biep]

For several of those things you'd rather want message lifetimes, so that you can also do things such as only showing the invitation to the common break shortly before it begins (even though you are not on Matrix then), and not show it after it has started to those who didn't read it before.

[toger5]

There is also the futures msc that superseeds lifetimes in a more generic way: matrix-org/matrix-spec-proposals#4140

It allows sending scheduled messages so you can schdule a redact and get the disappearing message with the current matrix redaction semantics.

[Biep]

Does that allow setting a starting point? I haven't read all, but could only see stuff concerning an end point in time for the messages. Or is that what the reference to Futures is about?
If so, it seems indeed to implement lifetimes to a large degree.

[toger5]

It basically only allows setting a starting point. But the start of the redact is equivalent to the end of a normal room message.

if you want to make it complicated you could also send a future for sending a message in 1h and another future to send a redact in 2h. It provides that flexibility. So its scheduled and disappearing messages in one.

[Biep]

Good! That sounds like an implementation for much of #712.
What about dropping the message if it has not been delivered before a certain time (instead of sending and redacting it)? The moment T in #712?

[Biep]

And of course it does not address the (purely client) "keep trying" part, which is so important in rural West-Africa, where Internet access is sporadic. (Many of my contacts there tend to walk around searching for connection, and then have to go to all their rooms to trigger the sending of the pre-written messages, which is a bother.)

[Mikaela]

Yet another reason why there should be possibility for self-destructing messages is combating climate change as many of us have old messages that we won't miss and that are using up storage somewhere as they keep cumulating and that storage uses electricity which may be unclean or taking electricity that could be used by something else.

• https://www.theguardian.com/media/article/2024/aug/09/excess-memes-photos-and-reply-all-emails-are-bad-for-climate-finds-study

[toger5]

This is an interesting thesis.
I would like to comment on this since there clearly is a misunderstanding in how matrix works.
Matrix stores messages in a Direction acyclic graph (DAG) to synchronize data in a distributed system. A DAG (as the name implies) is a Directional data structure where you cannot "go backwards". So also a delete and a edit does not alter the historic data/events. Instead each redact/deletion is a new event that gets appended to the graph.
The home servers can remove the content of the messages. In most cases they are less data however than the new redaction event.
But it would be an interesting experiment so see if one can find other areas that make sense to optimize.
The matrix rust SDK already has a lot of optimizations (hence saves electricity) compared to the legacy apps kotlin/java and swift/obj-c SDK.
In general matrix messaging apps have a small leverage in a climate impacting energy consumption compared to other industries/projects. I think there are much better fields where the return of investment and hence the impact of resources have a much much larger outcome and positive impact on making the best out of the situation of the global climate.

[throwException]

I also think this is a really important feature.

Even if there are some clients and servers who don't follow these rules, in activist/political organizations it's common that everyone uses Element, the server is hosted by the organization and everyone is well-behaved until the day of a police raid where they confiscate devices. At that point, it's great if most old messages are deleted from devices and servers.

[coomcode]

still no client offering this to match the low retention on synapse server...sigh

[edaragor]

Its 2025 now and still no option for messages to auto delete :/ should be standard in any private messaging app in my opinion.

[Biep]

Yes, please have this added - as part of the more comprehensive proposal #712.
Please do not hack it in a non-extensible way.

[Mikaela]

As previously stated, this feature is becoming more and more important as time passes. Under the current administration on USA it's possible that having critiqued them means you will not be able to cross their borders.

• https://www.theguardian.com/us-news/2025/mar/19/trump-musk-french-scientist-detained

There is also growing hostility towards LGBT* community everywhere with "gay propaganda" laws, so in addition to the USA, people in some EU countries such as Bulgaria and Hungary might also benefit from the feature.

I am reminded of the game Secret Hitler and its message of facists having to win only once, while for privacy activists it's a constant struggle with same bad ideas constantly being brought up anew (such as chat control and it's client side message scanning or passport fingerprint registry for crime investigations).

[edaragor]

This!

I have been running a agency with musicians playing in the US, and each time they travelled there it was the same procedure with uninstalling all messaging and SoMe apps and clearing messages, both in open and locked apps, as I have had several artists in for 2-3 hour questioning over SoMe posts, mails they found and so on when selecting them out for "random" searches.

[xb191799981]

强烈建议实现自定义消息自毁的功能， 这个太重要了。 如果手机丢失，或者被他人拿走， 重要的信息就会被偷窃了。
It is highly recommended to implement the function of automatically destroying custom messages. This is extremely important. If the phone is lost or taken away by someone else, important information could be stolen.
カスタムメッセージの機能を実現することを強くお勧めします。これはとても重要です。携帯電話をなくしたり、誰かに持ち去られたりすると、重要な情報が盗まれてしまいます。
Il est fortement recommandé d’implémenter la fonctionnalité d’autodestruction des messages personnalisés. Ceci est trop important. Si le téléphone est perdu ou pris par quelqu’un d’autre, des informations importantes peuvent être volées.
사용자 정의 메시지 자동 파괴 기능을 사용할 것을 강력히 권장합니다. 이것은 매우 중요합니다.휴대폰을 잃어버리거나 다른 사람이 가져가면 중요한 정보가 도둑 맞는 것이다.
Настоятельно рекомендуется реализовать функции самоопределения сообщений, которые саморазрушаются, что слишком важно. Если телефон пропадет или кто-то другой заберет его, важная информация будет украдена.
Es ist zu wichtig, um die funktion einer selbdefinierten nachricht zu realisieren. Wenn ein handy verschwindet Oder ein anderer es nimmt, werden wichtige informationen gestohlen.

[JackDinn]

hello, is there anyone out there? Did i see a some proposals and requests back in 2018 ?? Whats the problem here. This was advertised as a security high E2EE messenger but after spending the day getting it all running on my server i noticed that i could not for the life of me find how to set auto expire on messages. Wow, is all i can say.

[xb191799981]

没听明白你在说什么。

…

---Original--- From: ***@***.***> Date: Sun, Aug 3, 2025 08:34 AM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [element-hq/element-meta] Self-destructing/disappearing messages(Discussion #682) hello, is there anyone out there? Did i see a some proposals and requests back in 2018 ?? Whats the problem here. This was advertised as a security high E2EE messenger but after spending the day getting it all running on my server i noticed that i could not for the life of me find how to set auto expire on messages. Wow, is all i can say. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[JackDinn]

what do you mean " 没听明白你在说什么。 "I didn't understand what you were saying.""

I'm saying why is it taking more than 10 years to implement something that should be baked in right at the concept stage before even starting to build.

Please implement this !

[Biep]

Yes, this is sad. The more comprehensive proposal is #712, so that is where one might expect progress reports - but not much happening there either, so far.