Retract/edit sent messages

I’m bringing up the feature request mentioned before:

4 years later, still not implemented.

To summarize: Retract/edit sent messages like Telegram does.

Yes I know it’s not a guarantee, I know one could just take a screenshot of the messages, and neither does Telegram avoid that. However they are very handy features to correct typos, avoid embarrassment, cleanup conversations and so on.

Even Signal already had the ability to delete sent messages for everyone.

Just make it work like self disappearing messages, but existing messages are deleted/modified on receiving remote requests.

There should be a GUI toggle to disable remote deletion/modification functionality per chat basis, and upon disabling, No one should be able to retract/edit sent message.

The toggle needs a cooldown mechanism to avoid toggling on for a brief moment to edit then toggle off. Make it require a Accepted response from recipe in order to switch the toggle. This is not a guarantee again, but it’s to make sure at least official Delta Chat client doesn’t have major design flaws in regards to the functionality.


Also there is the question how to show that in email with people that use normal email clients.

I agree editing to correct typos is useful (I do it all the time in telegram, discord and even on this forum) but I imagine recieving the same message edited five times in email looks weird to users which don’t use DeltaChat

Some thoughts on this


@Simon what do you think?

OK because you asked for it, though I’m not the only one with an opinion on this :wink::

Edit messages

    • as a User: Good idea, but how does this look in text only mode?
    • as a Dev: hard implementation effort generating those html emails, also html emails could clash with the planned markdown support (or make it more tricky at-least)
  1. that’s more realistic and less implementation effort

Retract messages

both solutions sound possible, though the latter is again easier to represent in text mode (I think that at least, maybe you have an brilliant idea how to display 1) in text mode).

Some competing chat-over-email apps (“Spike”, though I’ve never used it myself, this comes from reading about it) have a ten second delay before the email gets actually sent. So you can unsend it if you spot the error within ten seconds.

One idea that comes to me right now is to have a variable delay; up to thirty seconds if the conversation is “cold” as in you’re replying to an hours-old message, and way less in a currently bubbling convo.


1 Like

@thjderjktyrjkt I guess deleting sent messages could be done in a best-effort kind of way and similar to how WA and others do it. Last time i checked one could delete WA messages if they are just a few minutes ago, and i think it also takes into account if the other side has already seen the message (if not, then it’s arguably less of an issue to delete). For now, i wouldn’t suggest to go for per-chat (or any other options) to further influence deletion behaviour. Maybe someone here could try to analyse or research WA’s delete-message behaviour more in depth and describe it here?

@sandra Your suggestions wrt delayed-sending make sense but it’s quite some effort. I think it’s easier and more versatile to go for delete-messages-after-sending. If this is between people using Delta chat the message would dissappear (see above), also from the server of the receivers. For regular e-mail users they would see an additional message with a standard header but there is not much support for this from regular mail apps.

delete-messages is more implementation effort than it might seem because it requires UI changes/feedback on all platforms, as well as “core” changes where all interactions with e-mail servers take place. Respective code needs to be reviewed and tested very carefully because deleting the wrong message is potentially hazardous.

Note also that @Simon created and maintains this list of potential features for documentation and further decision purposes.

1 Like

As of 1) in edit messages: I also agree this is hard to implement (You need something Git or WinMerge does which compares differences) so you could always go for the latter method instead (just replying to the original message).

I came up with that idea only because if you reply to original message with minor changes (like only change a single letter) then it’s hard for the recipient to tell the difference.

As of 1) in retract messages:
Display the fancy stuff in text, then add something in the header to indicate this is an deletion request that should be handled by Delta Chat.

But again there is nothing wrong if you go for 2) since it’s easier to implement I guess.

@Sandra This is a good idea but I think retracting any message by deletion request should still be implemented as well since Telegram allows you to retract anything.

@hpk I don’t use WhatsApp. Although I’m familiar with Telegram behavior.

In Telegram:

  • if the recipient is offline and you deleted the sent message, Telegram server will simply delete it from the server, and the next time recipient client goes online it won’t receive the deleted message at all (Telegram server will hide the fact there was a deleted message at all)
  • If the recipient is online, Telegram will send the delete request to the recipient client. Official Telegram client will then remove the message and its corresponding notification if possible. But this is entirely up to the client recipient is using (eg… using a modified client that ignores the deletion request)
  • There is no time limit regarding retracting the message. You can retract any message you want, even the recipient message and the whole conversation.
  • As of editing the message, there’s no difference between online / offline. Recipient will always see the ‘edited’ status in the bottom-right of each message.
  • There is no per-chat preferences regarding this feature, Telegram server assumes every Telegram client has the required capability.

It’s kinda impossible to implement the same mechanism in Delta Chat without changes to the E-Mail standard. When a message is sent in E-Mail, it is sent forever, deleting the sent message does not affect the recipient’s end (recipient will receive the message anyway). Best you can do is to tell the recipient Delta Chat to delete the message since E-Mail providers won’t do that for you, because there was no such thing as retracting E-Mail in the world of E-Mail standard, some platforms might implement their own solutions regarding this but then they’re not standardized and they’re best not to be used in Delta Chat.

As of per-chat behavior, this is only intended to prevent “Enable retraction and delete the sent message, then disable it so the recipient couldn’t delete their sent messages” to gain an unfaired adventage. Toggling the option requires recipient approval, and implement a cooldown so you can’t spam toggling the preference.

Yes, I know it’s impossible to completely prevent these such things as the recipient could just use a traditional E-Mail client, but the design is to make sure at least Delta Chat client doesn’t have design flaws to be abused.

Or instead don’t give user any option to disable the retraction/deletion functionality, just like Telegram does. But then some could abuse this behavior to put Delta Chat users into bad situation, and there’re always users who want to use Delta Chat purely as an E-Mail client and not some modern messager based on E-Mail protocol. Per-chat behavior is used to make sure user only enable the behavior with trusted recipient.

So let me put some caveats in here.

  1. Y’all know how I feel about these Delta-generated messages when they are sent to any non-Delta MUA. They are inappropriate, intrusive, and for us who email people in multiple languages, an internationalization mess.

  2. We need to be careful about expectation management. We can’t be setting up expectations that later leads the user in trouble.
    2a. Users might get the expectation that their original messages can’t be seen once edited, but they can.
    2b. If we only send retraction messages to Delta MUAs (see 1) we get inconsitent editing UX across recipients.

All that said, two years ago I implemented for an IRC/Discord bridge a system of editing IRC style (from the IRC side) and sending that.

It supported both s/text/replacement/ and corrections*.

It’s in js.

I never got to use it because it turns out Discord bridges can’t edit (or some similar restriction) and also I hate Discord.

So for exmaple if someone sent this


It’d edit the preceding message to “So for example if someone sent this”

Uh, I now realize that you’d need the reverse of that. Since we’re not editing from the non-Delta side.

In headers (please use the X- prefix this time!) we can have the full replacement text + message id, to edit unambiguously. The problem, as I said before, is the body and how non-Delta MUAs will see it. I got really badly burned by changing the group name last week.

Edit: Why am I even thinking about this. “There is no such thing as retracting email” is right. The ten-second thing (or whatever time users put in) might be a better way to go. Don’t call it a delay in seconds, call it an, uh, editing window. (And of course, as soon as they start editing, stop the clock and restart it when they save. That should go without saying.)

On Mattermost I do edit old posts but for example on here and on Reddit I think there’s a time limit.

They are inappropriate, intrusive, and for us who email people in multiple languages, an internationalization mess.

I quickly came up a thought on this. Although it’s best to be discussed in a separate feature proposal.

Indicate your preferred language in header. For example like lang=en-us , and when Delta Chat needs to generate messages, use the corresponding language instead of current language. This should be done on a per contact basis (like public key exchanging that is tied to specific email address).

You can also do the same for the signature, that “Sent with my Delta Chat Messenger:” thing. Use a placeholder to indicate the default signature.

expectation management.

This needs to be done in UI part. Give user clear indications that Delta Chat retracts messages by sending additional deletion request. Recipient needs to use Delta Chat as well, and it’s not a guarantee if message will be deleted or not.

Also the per-chat toggle comes in place, if the recipient don’t use a Delta Chat then the toggle can’t be turn on since there will be no approval from recipient Delta Chat client. This needs to be done in both UI and core part.

1 Like

No, because these messages are for non-Delta MUAs (Delta Chat users won’t see them, they’ll just see the message update), and we can’t control what headers non-Delta MUAs send.

Also I’m learning on Mattermost that the other people often aren’t even noticing when I am editing posts waaay off screen. This whole editing shenanigans is… I am coming around to the time delay thing, but less so the retract message. (Not that I am the one you need to convince, I don’t make the decisions around here.)

The user story in the original feature request (autocorrects, temporary blackouts) is handled by the time delay.

Edit and we should get rid of that default signature. We are sending a sig while we are hiding sigs? Talk about dark pattern. We are embarrassing users with our ad while they might not even notice it.

Aaaah! :bulb::bulb::bulb::bulb::bulb:!!!

Delay is good when dealing with non-Delta Chat MUAs (they are used to email being slow + they can’t handle retract messages).

Retract messages are good when dealing with Delta Chat MUAs (they are used to chats being fast + they can handle retract messages).

Sooo… obvious solution is obvious! But, it’s gotta be 100%. Any non-Delta Chat MUA recipient means we don’t send retract messages.

Hum, maybe an adaptive delay like you suggested earlier would be more manageable if we can do it without much UX changes and without any extra setting. If there was no activity for some minutes in a chat we could delay message-sending for N seconds like you suggested. Deletion will then naturally unsend the message and a future re-editing would put the message back to draft mode, and would only be possible with messages that have not left the device. Note btw that you if you put your device to “offline” and then send a few messages you can delete them without problems and they will never leave the device and be removed from the local database. FWIW I happen to use it this way quite often as i don’t have a data plan but use WiFi only.

Yeah, this would be great. Different behavior for different recipients.

But I came up a question: How does Delta Chat handle the ex Delta Chat user? So the recipient tried Delta Chat once and then uninstalled it and went back to traditional e-mail client. How does Delta Chat determine if recipient ditched Delta Chat or only used other client to reply messages? (Because I do that sometimes, when I need to add advanced formats to the message)

One solution I quickly came up about was to add a “Disable Delta Chat specific features” button per contact basis. And prompt user if the recipient had sent a message using something other than Delta Chat.

1 Like

nah the maintains, is not accurate anymore… It’s heavily outdated. But its a wiki post, so feel free to help out with editing it and adding your proposals to places where it makes sense (like grouping similar ones under a headline).

as an user that use Delta Chat to chat mainly (even if I use Delta as my only MUA for all email activities) I would not like this delays in sending messages, if you have to wait some minutes before sending the message, what about you actually reading the message before sending it instead of sending right away and then reviewing an important message and feel embarrassed and edit it, that is a bit hard to understand to me

in classic email this would have no solution anyway


(meta: act-ually actions can never be made undone but it’s just a very new suggested illusion (and in many ways cheating and giving inhonest impressions) not really supportive in regard of effects and long term well-being and a “killer” of mindfulness and concentration skills, yet sure, as this requires effort and sacrifices, beloved. It’s of much benefit to be aware of such and act accordingly. Just for cases such is of interest for consideration. Kind of delay, how ever, to correct, giving such, taking such, isn’t that “bad” but even encouraging to reconsider. Rushing… :relieved:)

Alternative/naive: what if displaying the message in “draft-color” in the chat line (would btw. help with, on one hand good, small editor window) as long as “send” isn’t pushed (such helps to see the final product) and having an edit-icon on it as long certain delay would allow (whether caused by off-line or other delay of :rocket:) correction and stops the progress of sending by pushing, bringing it back into editor and draft color.

gosh, why not let people decide? So much discussion and still nothing implemented…

It’s great to have options! Let recipient decide whether to hide “deleted” messages, display “message deleted” or just mark a message with a small trash can. As for edited - show edit history, if you are concerned with illusions and mindfullness. I just hate fixing my typos with extra messages and like things to look nice in my chats, without thinking of every message as a publication…

As for email users - at first just don’t do anything, show message to sender that this user doesn’t support message deletion/editing. Keep it simple, but feature-full.

Delays? Strange idea, but can be an option for those who want it… Although I really don’t see why anyone would want a delay xD


I would really like to have this feature.
Personally, I don’t see a big problem in sending an updated message as a response to the edited one. It’s kind of must-have to be able to see the history of editing. And this behaviour will make it easy to get the last edited email, and if important, its history as well