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?

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

[borzov]

I want to emphasize that having native message auto-deletion (self-destructing messages) based on a timer is an essential feature for modern messaging platforms. Many alternative messengers (such as Telegram, WhatsApp, and Signal) already support this, and users have grown to expect it as a standard privacy and chat hygiene function.
Automatic message removal provides several important benefits:
• It visibly improves privacy for all participants, especially in private and sensitive conversations.
• It reduces clutter and allows chatrooms to stay relevant and manageable over time.
• It aligns Element/Matrix with market expectations and feature parity.
Currently, only third-party bots or manual redaction offer partial solutions, which are not user-friendly for mainstream adoption and often require additional permissions. I strongly encourage the development team to prioritize this functionality or provide a clear timeline as it would significantly improve user satisfaction and competitiveness of Element as a secure communication tool.
Thank you for considering this feedback.

[throwException]

The point is that bringing this as a safety measure is never going to work - because it isn't safe. Servers and clients can both refuse to delete the message. That is why the message lifetime approach has more chance of being accepted. The protocol, and the major implementations, of the server software, do have the relevant features for messages self-destructing - only they need to be presented in a context that does not falsely suggest any safety or security. Matrix is very severe on security, and having such a hidden leak would not be acceptable. Do support the message lifetime proposal, and you'll get message disappearance as part of it.

That depends on what your security goal is. For me, this feature is about a conversation between two (actually one, since I use matrix as an inter-device communications channel) or more honest parties one or more of which at are compromised at some point which everyone knowing when that is. This is often the case if one device is ceased by police or border patrol at which point it is very beneficial to the honest participants of the past conversation if most of it is deleted (and erased/overwritten). It's equally clear, that in other situations, such as dishonest participants, no additional security can be gained from such a scheme.

This also the reason why lifecycle management alone will not do. It would be way better, if messages were stored on the device in encrypted from with rotating keys and these keys could be securely forgotten, such that an expired message would immediately become unrecoverable even if the storage was not yet overwritten.

[Biep]

Of course - if both the servers and all clients are in safe hands, you can have a safe situation. My point is that Matrix cannot add features relying on such felicitous situations. So, the feature should not be presented as a security issue, because as such it will not be implemented. The message lifetime proposal will provide what you want, but in a context that Matrix can defend: not security, but ease of use.
It is about framing the request, not about whether it should be implemented - we all agree on that here, I believe.

[Biep]

What you request, if I understand you well, is a new criterion for deletion - one that is very close to the message deletion that is already possible. It sounds very reasonable to include that in the proposal (besides e.g. burn on read or disappear at a set time).
Element has the option to delete messages in mass, e.g. to remove everything posted by some spammer, or to delete one's own messages. If the room members have the power, they can mass-delete everything; all that might be needed would be a "panic button" that would do that in a single go. Moving the right to delete other peoples' messages down to some modest power level would then all that was needed for the panic button to work.
Am I understanding your request correctly?

[throwException]

There are two parts to it:

• The ability to set a message deletion timeout per channel. Ideally this deletion timeout should be a state event for consistency, although it's processed by the clients through the normal deletion mechanism. A panic button could be a nice addition.
• To make any manually or automatically deleted message permanently inaccessible on the client (and server) side. I understand this might be hard due to the properties of databases, the file system and flash storage. It might be doable by using local encryption of messages with transient keys managed (and destroyed) by the operating system.

[borzov]

@Biep You make a very valid point regarding the distinction between "security guarantees" and "ease of use" in a federated environment.

I completely agree that we shouldn't block the feature by demanding impossible security guarantees on remote servers (which are out of our control). If framing this as "Message Lifetime" or a "Retention Policy" (focused on hygiene/UX rather than strict security) is the pragmatic path to get this implemented, then I am 100% on board.

Ultimately, our goal is the same: to have messages disappear automatically after a set time to keep chats clean and private on our end. If your proposed approach is "safer" to defend from a protocol standpoint and has a higher chance of being accepted by the Matrix core team, I fully support it.

[Logicwax]

why can't "deletion" mean "clients throw away keys" for said messages? That way it won't matter if servers are trusted or not. If clients at both ends throw away the keys for those messages, then they are essentially deleted in a cryptographic sense.

[t3chguy]

Keys aren't per message, they are rotated periodically, normally every time the device list of the room changes

[SamiLehtinen]

why can't "deletion" mean "clients throw away keys" for said messages? That way it won't matter if servers are trusted or not. If clients at both ends throw away the keys for those messages, then they are essentially deleted in a cryptographic sense.

I strongly agree. I have previously noted that the current E2EE implementation in Matrix/Element exhibits a notable gap in data hygiene regarding this exact concept, known as crypto-shredding.

To ensure effective message deletion, the protocol should ideally enforce the following:

• When all messages associated with a specific decryption key (or ratchet index) are deleted, the client must permanently discard the corresponding keys from local storage and key backups.
• Currently, because these keys are retained indefinitely, a local compromise defeats the deletion. If an adversary retains copies of the encrypted payloads (e.g., from a federated server database) and later gains access to the client's keystore, those supposedly "deleted" messages can be trivially decrypted.

Implementing strict cryptographic deletion at the client level would elegantly resolve the issue of having to trust server-side deletion mechanisms.

[Biep]

And aren't they sent via the server? The server could intercept them, and someone gaining access to the receiver's session could massage the client into decrypting and use those. Or am I missing something?

[flatsponge]

10 years and such a basic feature is still missing ... 💔

[borzov]

Unfortunately, this is an extremely sad anniversary. I don't know if we'll ever see this functionality.

[JackDinn]

Indeed, very disappointing 😞

[Biep]

I still very much prefer the message lifetime approach, or at least a destruction feature that can easily be extended into full lifetime management.

[JackDinn]

I don't understand all the details, but I just don't see why we can't have the remove/delete function that is already built into the app include a timed execution. I'm not asking for a complete rebuild or anything extensive. As it is ATM i have to go back through certain conversations after we are finished and manually delete all comments that i don’t want left on the clients or server.

[Biep]

As I understand it, the main issue is the fear to suggest a non-existing safety. People trust Matrix for its rigorous safety features, albeit at the cost of a less smoothe usage (e.g. having a pass phrase or code on top of the password).
If people believe the deletion feature to be safe whereas it isn't, and then discover that, that is a major trust breaker - apart from the damage that may have been done.
That is one reason for my lifetime proposal, which shifts the narrative to usefulness in communication, not safety.

[JackDinn]

That's not an argument; nothing is 100% guaranteed secure. The developer could implement some backend setting that most people may never be aware of, which simply gives the admin user who wants to set it up the option. The devs can stick as many warnings as possible all over the place. I supposed i could write some cron python (whatever), but its just a real PITA since I'm not exactly accustomed to the code of this project.

P.S. are you saying that the "remove" feature is recoverable? (assuming that all clients have been connected to receive instructions to remove).