# What are your thoughts on Signal's policy for edited messages? **URL:** https://discuss.privacyguides.net/t/what-are-your-thoughts-on-signals-policy-for-edited-messages/37347 **Category:** Questions **Created:** 2026-04-22T17:38:45Z **Posts:** 50 ## Post 1 by @PurpleDime — 2026-04-22T17:38:45Z **TL:DR: When you edit an unread message on Signal, the recipient can see all the changes you made. Is that a good thing? I don’t think so.** I’m sure a lot of you know that when you edit a message on Signal, the recipient can still see not just the original version but every version of the message if you edited it multiple times. IMHO, if the user has not seen the message, we should be able to hide all the edits from them. If you are having an argument with your partner over text and send a harsh reply that they have not seen but that you quickly edited, they would still be able to see your harsh words. I understand that if the recipient hasn’t seen the message, I can still delete it, but I wish we could hide edits. I remember when Telegram introduced the ability to edit and delete past messages, one of my friends felt that the way Telegram implemented it was wrong because it shattered the integrity of messages. Telegram allows you to delete messages you sent months or years ago with zero indication that you deleted anything. This can easily change the meaning of past conversations when someone reads them back again. It can easily create a lie. It’s actually the primary reason my friend stopped using Telegram. Signal’s way of implementing edited and deleted messages is a good counter to that, but I wish it were possible to hide edits when the recipient has not seen the message. If the recipient has seen the message, I’m ok with them having access to previous versions. **What do you think about it?** --- ## Post 2 by @Archer — 2026-04-22T17:55:34Z I think in general its a good thing to have high transparency about edits that where made. Maybe there could be a grace period, in which you could make edits that are not logged if the other person has not seen them. --- ## Post 3 by @lyricism — 2026-04-22T17:57:22Z > [@PurpleDime](#): > > I wish it were possible to hide edits when the recipient has not seen the message. How would this be actually work? Even if the recipient has not yet read the message, their device has likely retrieved it and they may have seen the content in the push notification. It is poor UX for the recipient to not be able to see changes to a message they already have on their device and may have already seen. It would also entirely depend on the recipient’s client cooperating. If you are trying to hide something about a message you are sending from the person you are sending it to, you will have no guarantees that any measures will actually succeed because they may be using a client that simply doesn’t cooperate while reporting it does. The closest feature Signal has already to this threat-model-wise is disappearing messages, but disappearing messages provide a benefit when communicating with non-adversaries when both want to ensure a third party couodn’t seize a device and review the entire chat history. There is no such benefit for this feature, it would only be for the purpose of helping you against an adversarial recipient, which Signal is not capable of actually providing safety against. --- ## Post 4 by @PurpleDime — 2026-04-22T18:12:41Z > [@lyricism](#): > > t is poor UX for the recipient to not be able to see changes to a message they already have on their device and may have already seen. I hear you, but I am specifically referring to a message the recipient has not seen. Also, I am not against the recipient knowing that the message was edited even if they haven’t read it. But giving them access to previous versions in this context is IMO, unnecessary. > [@lyricism](#): > > If you are trying to hide something about a message you are sending from the person you are sending it to, you will have no guarantees that any measures will actually succeed because they may be using a client that simply doesn’t cooperate while reporting it does. Maybe so, but most people use the default client. Most Signal users use the official Signal app. They don’t use Molly. Also, when I send a message that was unread and deleted before it’s read, I am confident that the recipient hasn’t seen it. So why not have the same feature for edited messages? The risk level is the same. > [@lyricism](#): > > There is no such benefit for this feature, it would only be for the purpose of helping you against an adversarial recipient, which Signal is not capable of actually providing safety against. I disagree. The recipient doesn’t have to be adversarial. Hiding edits to an unread message achieves the same thing as deleting the message. So why not allow it? --- ## Post 5 by @otterfoghornrainfall — 2026-04-22T18:26:47Z To me the edit system is valuable for the sake of transparency. The case you describe is an edge case where one should use delete (or take a beat to let their emotions cool and proofread before hitting send) instead of placing responsibility on the app. I don’t think this level of nitpicking is helpful. Signal serves hundreds of millions of people, and the current edit policy seems like a wise choice for all but a handful of situations, and in those situations there are other remedies (as you yourself noted). It’s also probably a fair amount of work to build this hyper-specific functionality, and that time can be better spent on less frivolous features. --- ## Post 6 by @lyricism — 2026-04-22T18:31:09Z > [@PurpleDime](#): > > I am specifically referring to a message the recipient has not seen As I mentioned push notifications mean there is no way to know if it has actually been seen. > [@PurpleDime](#): > > But giving them access to previous versions in this context is IMO, unnecessary. To you, as the sender. Maybe the recipient prefers to keep that record. It’s not your decision, as the content is already on their device. > [@PurpleDime](#): > > most people use the default client The default client can act uncooperatively in this context if the recipient creates a backup before the message is edited. You don’t need a third party client for this. > [@PurpleDime](#): > > when I send a message that was unread and deleted before it’s read, I am confident that the recipient hasn’t seen it. Why? Not everyone sends read receipts, and even if they do again they can see it in their push notifications which doesn’t send a read receipt even if they have them enabled. Also, if the message was sent more than 24 hours ago, it actually doesn’t delete it from the recipient’s device. Even if less than 24 hours ago, if they have a backup created since it was sent they will still have the content in the backup. > [@PurpleDime](#): > > The recipient doesn’t have to be adversarial Someone you are messaging who if they can see past edits to messages you’ve sent them is problematic for you is by definition, at least to some degree, adversarial. > [@PurpleDime](#): > > Hiding edits to an unread message achieves the same thing as deleting the message Not technically speaking. Deleting messages is a convenience thing, and signal actually explicitly doesn’t guarantee that it will be deleted on the recipient’s end (they specifically document this as “best effort”). Content can’t be deleted from backups created after the message was sent, for example. Editing needs to be reliable, because it updates the content and produces a new event. It doesn’t make sense to provide reliable delivery of edits and unreliable hiding of edit history. > [@PurpleDime](#): > > So why not allow it? I mean if it’s the same thing _to you_ why not just delete the message and resend it then? --- ## Post 7 by @shadowwwind — 2026-04-22T19:26:23Z > [@PurpleDime](#): > > Maybe so, but most people use the default client. Most Signal users use the official Signal app. They don’t use Molly. Also, when I send a message that was unread and deleted before it’s read, I am confident that the recipient hasn’t seen it. So why not have the same feature for edited messages? The risk level is the same. Hiding edits would create the assumption that it is hidden, which creates confusion for users. It would be like a downgrade attack which you in general want to avoid. Being transparent about, this can potentially be seen by other users, is a good thing. --- ## Post 8 by @PurpleDime — 2026-04-22T19:28:28Z > [@lyricism](#): > > It’s not your decision, as the content is already on their device. It’s not my decision, but it’s not really the receiver’s either. It’s Signal’s decision. They are the ones who chose to implemented it this way. > [@lyricism](#): > > Someone you are messaging who if they can see past edits to messages you’ve sent them is problematic for you is by definition, at least to some degree, adversarial. In the context of an ongoing argument that started before the message was edited, yes. But sometimes letting the recipient see the edited message can start the argument. I’ll give an example. Your friend tells you that they had a skateboard accident, and broke their arm. A month goes by and they are still healing. You text them: > _- Hey, how’s your **leg.** Is it completely healed?_ Realizing your mistake you edit the message to: > _- Hey, how’s your **arm**. Is it completely healed?_ Your friend sees the original message and gets upset because they’ve discussed their accident multiple times with you, and the fact that you asked about their leg instead of their arm shows that you are a terrible listener. I’ve seen arguments start exactly like this with both friends and family. Not allowing the recipient to see your edits would be beneficial in this context. It’s kind of like when your partner sends you to the grocery store to buy apple juice, and instead you buy orange juice, but you realize in the car that you made a mistake and go back to get the apple juice. Does your partner need to know that you almost came back with the wrong thing? No. > [@lyricism](#): > > The default client can act uncooperatively in this context if the recipient creates a backup before the message is edited. You don’t need a third party client for this. Even so. The risk is the same as when I delete an unread message. > [@lyricism](#): > > Why? Not everyone sends read receipts All of my Signal contacts use Signal primarily because of me. They don’t really use it to talk to other people on it, and hence accept the default settings. Read receipts are on. I have changed the chat settings many times for our chats, and they never commented on that or intervened to change it to their liking. > [@lyricism](#): > > even if they do again they can see it in their push notifications which doesn’t send a read receipt even if they have them enabled. The risk remains pretty much the same so it would make sense to hide edits for unread messages, IMHO. > [@lyricism](#): > > Not technically speaking. Deleting messages is a convenience thing, and signal actually explicitly doesn’t guarantee that it will be deleted on the recipient’s end (they specifically document this as “best effort”). They can offer the same warning for edited messages. I am willing to take that risk. > [@lyricism](#): > > Editing needs to be reliable This is why I am in favor of indicating that a message was edited. I actually think it’s a must. But I don’t think the integrity of a message is betrayed when the receiver doesn’t have access to prior versions that they never saw before they were edited. > [@lyricism](#): > > It doesn’t make sense to provide reliable delivery of edits and unreliable hiding of edit history. But deleting a message that was unread also hides the history. It rightly doesn’t hide that the message was deleted, but it hides the content of the message. > [@lyricism](#): > > I mean if it’s the same thing _to you_ why not just delete the message and resend it then? I do that. I’ve sent media (pictures, videos, photos) by mistake and deleted them because they did not appear in the order I wanted. But when it comes to text, from a UX point of view, editing is easier than deleting. Because if I just want to edit a sentence in a 5 line text, deleting it requires that I copy the message, send it to myself, and then delete it. After that I have to edit the message in my “notes to self”, copy it once it’s completed, and paste in my chat. It’s more effort. --- ## Post 9 by @PurpleDime — 2026-04-22T19:30:57Z > [@shadowwwind](#): > > Hiding edits would create the assumption that it is hidden, which creates confusion for users. It would be like a downgrade attack which you in general want to avoid. I don’t understand what you mean. Can you please elaborate? > [@shadowwwind](#): > > Being transparent about, this can potentially be seen by other users, is a good thing. I agree. But my argument is that showing that a message was edited without showing the edits, is transparent enough. --- ## Post 10 by @notwithstanding — 2026-04-22T20:14:29Z Edit history is fine. Everybody makes mistakes. --- ## Post 11 by @trilobyte — 2026-04-23T17:49:46Z I have no strong feelings. I’ve used platforms that work both ways and for most people in most situations they work equally well. I’d rather adjust my own behavior than try to change a platform. @notwithstanding > Edit history is fine. Everybody makes mistakes. Agreed, if I see someone wrote something, regretted what they said or felt they phrased it poorly, and then edited it to be more considerate then I am not really going to have a negative impression of them. If we interact in person they are not going to get to edit their responses after speaking, so one assumes I already know about this and am okay with it at that point. Their effort into being considerate is obvious. But also… @lyricism > Someone you are messaging who if they can see past edits to messages you’ve sent them is problematic for you is by definition, at least to some degree, adversarial. Yeah, if it were me talking to a spouse or friend, they could simply ask me not to read their edit history if I hadn’t seen what they said pre-edit. If I agreed, someone who knew me well would have no reason to doubt me due to my history with them. Adversarial might seem like strong phrasing, but we’re really talking about a specific situation where someone either won’t agree to that or can’t be trusted to follow through on what they say. There are benefits and drawbacks of both ways of handling edits. However, regardless of how Signal handles it, I don’t think the aforementioned situation should be what they base their design choices on. --- ## Post 12 by @mooseberg — 2026-04-23T21:22:22Z I had no idea the original message of Signal edits were visible, which feels like a privacy violation to me. The idea that you should just delete your message if you don’t want the original to be read is fine… if you’re aware of that fact in the first place. Most messengers don’t work this way in my experience. I’m fine with the logic of it but this should be abundantly clear when editing a message. --- ## Post 13 by @seize — 2026-04-23T21:26:42Z Assuming original messages, before an edit, are visible has been my default assumption about nearly all internet messaging/communication tools I’ve used over the years. Once the message leaves your device no service can reasonably make guarantees about who can or can not see the message on the receiving end. --- ## Post 14 by @anon19752758 — 2026-04-23T21:39:44Z I second this. Also I don’t think Signals threat model is to protect you against yourself. As other people said: once a message is sent, it’s sent. Pretending it’s tracelessly deleted and it never happend (like Telegram does) is just security theater. If you don’t trust your chat partner don’t send them messages. If they are getting so pissed about you getting something wrong (like mistakenly asking about an injured leg instead of an arm) it’s not the messengers problem. It might be the relationship. Or how do you handle this in real life? --- ## Post 15 by @WhyRhy — 2026-04-23T22:06:51Z Copy message. Delete message. Paste message - making amendments. Post message. --- ## Post 16 by @_TrustyRocinante — 2026-04-24T03:02:08Z I think it’s the best solution. If you’re using Signal then I would assume you have some grasp on personal responsibility regarding handling your own data. I think it also subtly promotes transparency and trust to the recipient in showing your mistakes and corrections, rather than the sometimes ominous “edited”. I also like that they give you the option to delete the entire message and start again if it’s really a problem. But 99% of the time it will be typos and readability fixes that people edit messages for. I edit my comments on this forum often because I’m impatient (case in point: I typed “inpatient”) and don’t proof-read enough lol. I appreciate that this forum sometimes asks for a reason why you’re editing, because I never really thought about what that could imply to the reader. TL;DR I think it’s the best option. My backup solution would be “undo send”, that we have on email clients. But that would make instant messaging slow as balls. --- ## Post 17 by @Treant — 2026-04-24T04:11:13Z > [@PurpleDime](#): > > If you are having an argument with your partner over text and send a harsh reply that they have not seen but that you quickly edited, they would still be able to see your harsh words. This is a personal problem, not a Signal problem. If you can’t control yourself enough to not send harsh words that you will regret later then it’s not Signal’s job to help bail you out. Edit history always seemed to me to be an important log for potentially abusive messages. If someone was sent a threatening message or something constituting harassment, the edit history ensures the message can’t just be redacted/changed to something unremarkable to protect the sender from consequences. There is still the deleted message workaround anyway. And while that could also be exploited it seems necessary to keep for people to protect themselves if a phone is stolen or seized or something like that. --- ## Post 18 by @Expert4870 — 2026-04-24T04:59:36Z It’s perfect now. Other options create transparency, usability, and privacy problems for no real benefit. Want to change something without your contact seeing what it was before? Delete for everyone. And send the new one. Want to make an edit and don’t care if it is seen? Edit. I am happy with Signal’s UX—I can’t ask for anything more on the UX front. I don’t need anything that Discord or WhatsApp DMs gives. Signal is clean, intuitive, and features are implemented well. I even like stories :grinning_face:. ps I don’t use Signal—I use [Molly](https://infosec.exchange/@mollyim@fosstodon.org/116454503588326050). --- ## Post 19 by @PurpleDime — 2026-04-24T11:55:00Z > [@mooseberg](#): > > I had no idea the original message of Signal edits were visible, which feels like a privacy violation to me I didn’t know about it either. I found out soon after the feature launched when a friend told me. It’s the same friend who left Telegram for Signal because of how they implemented deleted and edited messages. > [@mooseberg](#): > > The idea that you should just delete your message if you don’t want the original to be read is fine… **if you’re aware of that fact in the first place.** That’s the key part. I don’t think most people are aware, and, in my opinion, that is good enough of a reason to change it. > [@seize](#): > > Assuming original messages, before an edit, are visible has been my default assumption about nearly all internet messaging/communication tools I’ve used over the years. I don’t think most people make that assumption when the message is unread. That’s the point. > [@anon19752758](#): > > I don’t think Signals threat model is to protect you against yourself. That’s a fair argument. But **when Proton Mail, and other email services allow you to unsend an email within minutes or seconds after you clicked send, aren’t they protecting you against yourself?** Signal was not the first messaging app to introduce editing sent messages. It was Telegram. And as there are justified critiques for how Telegram implemented this feature, I think this is a justifiable one for Signal too. Signal chose to implement it this way. I think it is a fair compromise to ask that if a message is unread, edits should not be visible to the receiver. But if it has been read, then it’s fair to show them the changes that were made. > [@anon19752758](#): > > If they are getting so pissed about you getting something wrong (like mistakenly asking about an injured leg instead of an arm) it’s not the messengers problem. I agree. It’s not Signal’s problem. But I don’t think it’s unreasonable to request a change to this feature all the same. It’s not Proton’s problem if you made a mistake in your email to a potential employer either, but it’s still nice to be able to unsend it. > [@_TrustyRocinante](#): > > If you’re using Signal then I would assume you have some grasp on personal responsibility regarding handling your own data. That may be true today because Signal is a very small player compared to its competitors, who are 20 times bigger. But **would it be true if Signal was the most popular messaging app?** Unlikely so. I don’t think it’s accurate to assume that if you use Apple, it’s because you care about privacy and hence have some grasp on personal responsibility regarding handling your data. When I believed Telegram respected privacy, I tried to convince my friends to join, and I used privacy as my main argument. My friends did join Telegram, but not because of privacy. It was because of Telegram’s superior UI and UX over WhatsApp and the many features the latter didn’t have, like a desktop app. Also at the time, WhatsApp had an outage in many countries, and because of that, some people were more open to try alternatives. There are people who use Signal primarily because their family or friend asked them to. Because they care about keeping in touch with them, they are willing to make that change. They are not moved by privacy. None of my friends or family are on Signal because of privacy. > [@_TrustyRocinante](#): > > I think it also subtly promotes transparency and trust to the recipient in showing your mistakes and corrections, rather than the sometimes ominous “edited”. I agree. But it’s a level of transparency that is not necessary, IMHO. Transparency is already present when there is an indicator that the message was edited. **People can be put off by seeing your process and revisions, especially if it’s not pretty. As the saying goes, you only get one chance to make a first impression.** At one of my previous jobs, I used to stay up late because I was overwhelmed by the workload and the tasks I had to do. It was extremely anxiety-inducing. I had just started the job. My boss didn’t know I worked late. I sent my reports to her the moment I finished them, that is, at 2 o’clock in the morning. Although my boss only read those reports at 9 when she got into her office, she saw the time at which I sent them, and she called me to her office. To her, it was clearly a sign that I could not handle the job if such tasks took me this long. If I had scheduled my emails to be sent at 9 am, which was not possible, my boss would have never gotten that negative impression of me. > [@_TrustyRocinante](#): > > But 99% of the time it will be typos and readability fixes that people edit messages for. That is certainly my experience. But in a work context, people can be judged for that too. And people often won’t judge you the same based on who you are. An Italian person might be judged less harshly than a Chinese person if they make the same English spelling mistakes and both work for the same company in the US or UK. I have definitely observed this. > [@_TrustyRocinante](#): > > I edit my comments on this forum often because I’m impatient I hear you. But this post is not about PG. I am not advocating for PG to hide edits. I am specifically talking about Signal, in the context where the message was unread by the recipient. > [@Treant](#): > > If you can’t control yourself enough to not send harsh words that you will regret later then it’s not Signal’s job to help bail you out. It’s not about harsh words. I gave examples where there are no harsh words and the recipient is still upset. > [@Treant](#): > > Edit history always seemed to me to be an important log for potentially abusive messages. If someone was sent a threatening message or something constituting harassment, the edit history ensures the message can’t just be redacted/changed to something unremarkable to protect the sender from consequences. This is certainly good argument for it. > [@Expert4870](#): > > I don’t use Signal—I use [Molly](https://infosec.exchange/@mollyim@fosstodon.org/116454503588326050). I have Molly on my phone, but I stopped using it for two reasons: 1. It can be really slow to update new messages. 2. Using it with a password is too cumbersome. --- ## Post 20 by @anon76815711 — 2026-04-24T12:06:50Z I agree with the transparency sentiment, after all you have to assume your message has been seen, since the recipient could just be offline directly after receiving it. (And live with the mistake you made.) – **Edit: Before reading on, be aware this seems not to be in the official app.** I’m using the degoogled unofficial version Signal-FOSS, which utilizes patches from Molly, IIRC. ~~Which bring me to this (sorry if I missed it already mentioned) :~~ **The workaround of deleting and resending does not work.** ~~At the bottom of **Settings-\>Chats** :~~ ![Screenshot_20260424-134328_Signal](https://forum-uploads.privacyguidesusercontent.com/original/3X/d/d/dd240a9977aaa13360280acddd2fbe393591c925.png) **This renders any remote control useless.** I initially enabled all, but then decided against it. It’s just not ethical. Just be a decent fellow to others if you expect them to be as well. --- ## Post 21 by @anon19752758 — 2026-04-24T12:16:10Z I think it might be best for you to take this to the official [Signal forum](https://community.signalusers.org/) if you want to see this changed. There have however been quite many [such posts](https://community.signalusers.org/t/private-edit-history/64935) and they’ve been discussed a lot of times so don’t expect too much traction or very nice answers. --- ## Post 22 by @WhyRhy — 2026-04-24T13:21:03Z > [@anon19752758](#): > > don’t expect too much traction or very nice answers Very well put! And politely… The Signal forum, as ‘unofficial’ as it purports to be, is not the sort of place to _discuss_ anything. Many years ago, it was “okay”. It is quite a hostile area with questionable moderation. As much as this specific topic doesn’t affect me, I’m pleased to read about the _discussion_ here in PG. It would highly likely be abruptly closed down over there quicker than you can say “_supercalifragilisticnarcissisticpersonalitydisorderexpialidocious_” --- ## Post 23 by @seize — 2026-04-24T13:44:06Z > [@PurpleDime](#): > > That’s a fair argument. But **when Proton Mail, and other email services allow you to unsend an email within minutes or seconds after you clicked send, aren’t they protecting you against yourself?** I think the problem here is that it is much easier for a non “real time messaging” service, otherwise known as email in this case, to implement a system in which the client is prevented from viewing the edit history. I do suppose this differentiation is a little less clear given that IMAP is, more or less, _constantly_ syncing with the email server, where as traditional POP email only synced with (and fetched from) the server at the active demand of the user. With regard to assuming edit history is visible: > [@PurpleDime](#): > > I don’t think most people make that assumption when the message is unread. That’s the point. I do think Signal could potentially give a clearer warning _(in app perhaps)_ that edit history is visible, but I do not see this reason alone as justification enough to remove the ability to see edit history from messages that have “yet to be read”. I also think that, as others have said in this thread, defining when a message is actually unread vs just not viewed in app would add enough complexity that the simpler approach to removing edit history for these messages would be to do so universally, and personally I see to much value in edit history for that to be worth it. I will say that I do not _personally_ send particularly long/complex messages over signal, and many of my communications on there are with people who understand my writing style and process, so perhaps I just don’t fit the scenario of having to hide my edits on Signal. When I do need to write to less personally acquainted individuals, or in a more formal setting I often draft my intended writing at least once before sending in the hopes of avoiding edits after the fact. **Side Notes:** Scheduled message sending feels like a separate issue, though I 100% rely on such features myself. > [@PurpleDime](#): > > If I had scheduled my emails to be sent at 9 am, which was not possible, my boss would have never gotten that negative impression of me. The edit history on this forum has been hidden for some time now because of [this topic from 2024](https://discuss.privacyguides.net/t/replace-the-word-deleted-with-retracted-or-similar/22658) > [@PurpleDime](#): > > ![](https://forum-cdn.privacyguides.net/user_avatar/discuss.privacyguides.net/_trustyrocinante/48/14185_2.png) \_TrustyRocinante: > > > I edit my comments on this forum often because I’m impatient > > I hear you. But this post is not about PG. I am not advocating for PG to hide edits. I am specifically talking about Signal, in the context where the message was unread by the recipient --- ## Post 24 by @seize — 2026-04-24T13:50:49Z Where exactly is the screenshot you provided from? As going to _settings → chats_ in the **official** Signal Android app, does not show these settings. At least as far as I could tell anyway. --- ## Post 25 by @PurpleDime — 2026-04-24T14:36:05Z > [@anon76815711](#): > > The workaround of deleting and resending does not work. > […] > **This renders any remote control useless.** This is fascinating. I did not know about these settings. Thank you for informing me. **I am guessing they are disabled by default?** > [@seize](#): > > Where exactly is the screenshot you provided from? I don’t see them either. Would appreciate some clarification @anon76815711. > [@anon76815711](#): > > I initially enabled all, but then decided against it. It’s just not ethical. > > Just be a decent fellow to others if you expect them to be as well. I agree. Although Snapchat is not a messaging app anyone should trust for privacy, I remember hearing stories about women, sometimes even minors, having sent explicit disappearing pictures to a boyfriend and being shocked to find out that with a simple screenshot, those pictures were shared without their consent. > [@anon19752758](#): > > I think it might be best for you to take this to the official [Signal forum](https://community.signalusers.org/) if you want to see this changed. That may not be a bad idea. > [@anon19752758](#): > > don’t expect too much traction or very nice answers. I don’t know what you mean by “nice answers”. I don’t expect everyone to agree with me, and I welcome disagreements as long as they’re expressed politely. Also, this post was intentionally addressed to the forum, not Signal. My goal is to gauge the opinion of people here and have a discussion, which we are having. > [@WhyRhy](#): > > The Signal forum, as ‘unofficial’ as it purports to be, is not the sort of place to _discuss_ anything. Many years ago, it was “okay”. It is quite a hostile area with questionable moderation. I did not know that. Thanks for the heads-up. > [@seize](#): > > I do think Signal could potentially give a clearer warning _(in app perhaps)_ that edit history is visible, That would be a step in the right direction. If people are made aware, then they have more control. If you had a pop-up warning every time you’re about to edit a message for the first time during any given day, it would be very effective without being too cumbersome. Either once a day for the first chat in which you wish to edit a message or once a day for every chat in which you wish to edit a message for the first time during that day. > [@seize](#): > > but I do not see this reason alone as justification enough to remove the ability to see edit history from messages that have “yet to be read”. I understand. > [@seize](#): > > I also think that, as others have said in this thread, defining when a message is actually unread vs just not viewed in app would add enough complexity that the simpler approach to removing edit history for these messages would be to do so universally, and personally I see to much value in edit history for that to be worth it. That’s fair. > [@seize](#): > > I will say that I do not _personally_ send particularly long/complex messages over signal I get that, but the people I use Signal with are mostly the people closest to me (emotionally). Some of them are friends and relatives I have not seen in years, even though we know each other very well. And from my experience, even with close people, tone can easily be misinterpreted via text. Even emojis can miscommunicate a tone. If you had just lost a loved one and a friend just sent you this: :cry:, I know some people who would be upset, including myself. Even though the intent may not be bad, I would personally take it as a form of disrespect. > [@seize](#): > > When I do need to write to less personally acquainted individuals, or in a more formal setting I often draft my intended writing at least once before sending in the hopes of avoiding edits after the fact. I try to do that too. > [@seize](#): > > Scheduled message sending feels like a separate issue, though I 100% rely on such features myself. I really hope Signal implements scheduled messages in the desktop app and that they add silent messages to both desktop and mobile. > [@seize](#): > > The edit history on this forum has been hidden for some time now because of [this topic from 2024](https://discuss.privacyguides.net/t/replace-the-word-deleted-with-retracted-or-similar/22658) I did not know that. Thanks for letting me know. **I assume a user can still see their own edits?** --- ## Post 26 by @seize — 2026-04-24T14:52:48Z > [@PurpleDime](#): > > ![](https://forum-cdn.privacyguides.net/user_avatar/discuss.privacyguides.net/seize/48/2843_2.png) seize: > > > The edit history on this forum has been hidden for some time now because of [this topic from 2024](https://discuss.privacyguides.net/t/replace-the-word-deleted-with-retracted-or-similar/22658) > > I did not know that. Thanks for letting me know. > > **I assume a user can still see their own edits** As far as I know, users can still see their own edits, yes. > [@PurpleDime](#): > > I really hope Signal implements scheduled messages in the desktop app […] As I only use signal on Android I tend to forget that scheduled messages aren’t available across all clients, which does suck in my opinion. > [@PurpleDime](#): > > people I use Signal with are mostly the people closest to me (emotionally). Some of them are friends and relatives I have not seen in years, even though we know each other very well. And from my experience, even with close people, tone can easily be misinterpreted via text. Even emojis can miscommunicate a tone. Fair --- ## Post 27 by @anon76815711 — 2026-04-24T15:42:42Z Huh, I use an unofficial Signal-FOSS and these settings are in Settings→ Chats, right at the very bottom. (Edit: And yes, they are disabled by default.) I believe Signal-FOSS utilizes the degoogling patches from Molly, maybe these are cherry-picks? Not sure… (Edit: Someone using Molly would have to look, I guess.) Then again, if these are anywhere, one must assume the protocol/feature set supports this, even if it is simply ignoring the deletion request. I haven’t actually tested this, because I’m the one in my circles who made them use Signal. If I’m to tell them I can bypass this, it would leave a bad taste for them and they might feel confirmed to stay with WhatsApp. (As paradoxical as this is to us folks.) --- ## Post 28 by @seize — 2026-04-24T15:51:44Z I presume this is what you mean: [https://www.twinhelix.com/apps/signal-foss/](https://www.twinhelix.com/apps/signal-foss/) > Also adds new preferences to keep view-once messages, disable remote deletion, control media deletion, and disable expiring messages. I am curious why you chose to use this fork of Signal instead of something like [Molly](https://molly.im/) instead. --- ## Post 29 by @PurpleDime — 2026-04-24T15:59:12Z > [@anon76815711](#): > > I use Signal-FOSS Never heard of it. **What is a Signal-FOSS? Is it another fork of Signal?** I thought Molly was the only one. I also though Signal was already FOSS. > [@anon76815711](#): > > I haven’t actually tested this, because I’m the one in my circles who made them use Signal I see. > [@anon76815711](#): > > If I’m to tell them I can bypass this, it would leave a bad taste for them and they might feel confirmed to stay with WhatsApp. (As paradoxical as this is to us folks.) Yeah, I can definitely imagine such a scenario. You’re not using the official app, you’re using a different one which gives you more control than the average user. I wonder if Signal is aware of this feature in their forks. If you don’t use these features at all, I can see why you would deem it unnecessary to alert your contacts, but the second you use it, even if it’s just with one person who happens to a colleague, it becomes incumbent upon yourself to tell all your contacts IMHO. If I was in your circle and knew that you used this feature with someone else, it wouldn’t matter that you promised not to use it with me, even if that promise was sincere. **Why did you opt for Signal-FOSS instead of the original app?** --- ## Post 30 by @anon76815711 — 2026-04-24T16:51:43Z Off-topic: @seize @PurpleDime > **Why I stuck with the Signal-FOSS fork** > > I used the official app at first, then found out about Signal-FOSS in my quest to avoid any proprietary software whereever I feasibly can. This was pretty early for me (so details might be fuzzy) and I assumed it was an official FOSS flavor. Then tried Molly and it had a severe battery drain on my device. I went back to Signal-FOSS and later found out about it being unofficial (when I knew what I was doing). > > I just stuck with it then, since Molly is more than I need and I didn’t want to check for the battery drain again (as isolated as these reports for me and others are). And I have to trust another party for both, so there wasn’t any personal benefit to switch again. Maybe these features prompt me to take another look at which app to use. @PurpleDime > **Off-topic - FOSS** > > Signal is not completely FOSS, because it uses Google’s FCM for push notifications for example. Molly and Signal-FOSS use WebSocket, I believe. There are other things as well, I think some binaries or artifacts are either proprietary or at least not entirely free software. These apps patch those dependencies out when possible. --- ## Post 31 by @WhyRhy — 2026-04-24T16:59:55Z > [@anon76815711](#): > > If I’m to tell them I can bypass this, it would leave a bad taste for them and they might feel confirmed to stay with WhatsApp. (As paradoxical as this is to us folks.) Thankfully, I’m of an age where not many associates would be inclined to do this. Whilst _I_ could, I won’t. As much as it is largely out of my control, if I found out someone was not using the official client, I’d not communicate with them. On the other hand, given the basic features of the official client compared to other similar communicators, I do fully understand why some may choose to use a Signal fork. Evidenced within this very thread and the questions around edited messages which, when you think about it, is arguably moot all the while forks are being used that bypass many other areas of concern. --- ## Post 32 by @seize — 2026-04-24T17:06:58Z > **Offtopic** > > This is probably off topic at this point but I generally would recommend **against** 3rd-party/unofficial clients for something as sensitive as Signal. > > [TeleMessage](https://discuss.privacyguides.net/t/hacker-who-breached-communications-app-used-by-trump-aide-stole-data-from-across-us-government/27761) may have been a special case, but I can’t imagine other forks out there have similar problems (intentional or not). --- ## Post 33 by @anon76815711 — 2026-04-24T17:10:14Z > **Off-topic** > > I get where you are coming from, but there always will be a way to bypass these restrictions. Even if screenshots would not be permitted in the app and everyone uses the official one, one could always take a photo with another device of media or messages before they time out. > All in all, it’s just a safe messaging channel, without means to prevent circumventions on-device or after-sent. --- ## Post 34 by @WhyRhy — 2026-04-24T17:32:06Z > **Offtopic** > > We’ll go with Off-Topic, although arguably circles back to the topic at hand given the handling of editing messages and subsequent speak about forks. But I will concede (although irritating as I can’t quote within hidden text. > > “Always be a way to bypass…” > > Indeed. This comes back to the ‘threat model’ question. This isn’t within my threat model. My associates (and myself) do not use forks. This is intentional for a few reasons which is immaterial here (some lack capability, but a few do not but have agreed not to use forks for the sake of the groups we are in and who we speak with). > > A lot of the time it is said about “speaking to adversaries”, which I do not do. And that argument has its own flaws in any case. The OP’s question fits in with this. I’d largely agree with what is suggested, particularly for my usage. Not so much for those using forked clients due to the bypassing in any case. But then I mitigate with what is suggested by the OP and delete the message and re-post. None of this will then be known to the recipient (other than it’s been deleted). Unless, of course, they bypass this. See: fork above. --- ## Post 35 by @Libre_Software_Enjoyer — 2026-04-24T20:03:18Z > [@PurpleDime](#): > > If you are having an argument with your partner over text and send a harsh reply that they have not seen but that you quickly edited, they would still be able to see your harsh words. I think this is an edge case and one could formulate a different case where its good that the honest version is preserved for the reciepent --- ## Post 36 by @otterfoghornrainfall — 2026-04-24T20:04:11Z This post has been stuck in my craw for a few days now. I’m not a journalist, but I imagine there are cases where seeing the history of edits they missed can be helpful to reveal if a source is being consistent, making slight corrections or sizable changes to message content. Similar situations likely occur with government officials who use Signal for secure communication, where information needs to be recorded and not so flippantly malleable. The OP’s almost solipsistic insistence that the technology is faulty because they can think of a scenario or two where it could slightly inconvenient and unwillingness to imagine its value is honestly exhausting and counterproductive to actual privacy discussion. The bright side of this, I suppose, is that it has made clear to me that this is not a forum to engage in meaningful privacy discussion, and I should put me energy elsewhere. So that’s nice. --- ## Post 37 by @WhyRhy — 2026-04-24T20:23:50Z > [@otterfoghornrainfall](#): > > The OP’s almost solipsistic insistence I can’t work out if this is humour or not. > [@otterfoghornrainfall](#): > > is honestly exhausting and counterproductive to actual privacy discussion It’s a discussion. This means you will hear from both sides or even many sides. Whether you agree or not is immaterial. This is, quite literally, discourse. > [@otterfoghornrainfall](#): > > has made clear to me that this is not a forum to engage in meaningful privacy discussion, and I should put me energy elsewhere _Really_?! --- ## Post 38 by @PurpleDime — 2026-04-24T23:29:28Z > [@anon76815711](#): > > Why I stuck with the Signal-FOSS fork Thanks for explaining. > [@anon76815711](#): > > Signal is not completely FOSS I did not know that. > [@WhyRhy](#): > > given the basic features of the official client compared to other similar communicators, I do fully understand why some may choose to use a Signal fork. IMO, Signal has made a ton of progress in the last couple of years. It’s people like @maqp who [made me understand why Signal was so slow to release new features](https://telegra.ph/Why-you-should-stop-reading-Durovs-blog-posts-11-25) compared to apps like Telegram. It’s because, unlike Telegram and WhatsApp, Signal’s priority is always privacy. E2EE is baked into every feature, and it is very hard to achieve, which is why it takes time. With this insight, I gained a lot more respect for Signal, and I find myself to be more patient with their release of features. But I can appreciate that for some people, even in the privacy community, it is still lacking. > [@anon76815711](#): > > there always will be a way to bypass these restrictions I never thought that a fork would make it easy to exploit vulnerabilities. This is new knowledge for me. > [@Libre_Software_Enjoyer](#): > > I think this is an edge case and one could formulate a different case where its good that the honest version is preserved for the reciepent This was just one example I gave among several. I reject the idea that the first draft or any draft that came before the final one is the “honest” version. It suggests that the final version of any text is inherently dishonest, which is preposterous. > [@otterfoghornrainfall](#): > > I imagine there are cases where seeing the history of edits they missed can be helpful There certainly are. I don’t deny that. > [@otterfoghornrainfall](#): > > Similar situations likely occur with government officials who use Signal for secure communication, where information needs to be recorded and not so flippantly malleable. It depends. I imagine that there are protocols in place. Since the [Signalgate scandal](https://www.theverge.com/news/838582/signalgate-pentagon-oig-report-pete-hegseth), it has been my understanding that only low-level and, at best, mid-level government employees are given the OK to use Signal in an official capacity. High-level government employees are not allowed. > **OFF TOPIC** > > You would be surprised how many times I hired or consulted an expert in a given field to give me an opinion on something, and they tell me things orally that they refuse to confirm in writing. Like they’ll tell me something was not built up to code but will not explicitly confirm it in writing, even though they believe it 100%. It’s happened enough times that it has made me consider recording conversations every time I hire an expert. > > This is also why every time I contact a local business or organization I need a service from, I do it in writing first via email. If they don’t respond to my emails, I call them. And after they give me the information I need over the phone, I ask them to confirm it in writing. Multiple times, a company quoted me one price in person and a different one when I called them over the phone, which is why I always ask for confirmation in writing. > [@otterfoghornrainfall](#): > > The OP’s almost solipsistic insistence that the technology is faulty You’re putting words in my mouth. I never said or suggested that it was _ **faulty** _. There are various ways to implement edited messages, as not all apps do it the same way. I simply shared my critique of Signal’s implementation and asked the PG community what they thought about it. > [@otterfoghornrainfall](#): > > unwillingness to imagine its value is honestly exhausting and counterproductive to actual privacy discussion. Clearly, you have not been following the thread because [I have conceded multiple points that others have made,](https://discuss.privacyguides.net/t/what-are-your-thoughts-on-signals-policy-for-edited-messages/37347/19) which evidently indicate that I can appreciate the value that people see in it. > [@WhyRhy](#): > > ![](https://forum-cdn.privacyguides.net/user_avatar/discuss.privacyguides.net/otterfoghornrainfall/48/11846_2.png) otterfoghornrainfall: > > > has made clear to me that this is not a forum to engage in meaningful privacy discussion, and I should put me energy elsewhere > > _Really_?! I am surprised too. I have found this discussion very engaging and have learned a lot from other people’s views. Just because I don’t agree with someone doesn’t mean their feedback is not valuable to me. The overwhelming majority of the time, hearing other people’s feedback sharpens my perspective. I enjoy the exchanges we have. --- ## Post 39 by @anon76815711 — 2026-04-25T08:05:20Z > [@PurpleDime](#): > > I never thought that a fork would make it easy to exploit vulnerabilities. I would not call it vulnerabilities, maybe an exploit, but that’s also a bit much. You always have to assume you cannot correct anything once you pressed the send button, no two ways about it. Reasons being: - You can not do anything if the recipient is offline right after receiving the message, neither delete/resend, undo send, nor edit. - Timing out messages or media can be photographed with another device. - (Forks can just ignore anything of the above.) - Absence of any check mark (“sent” and “received”) is no indication that it has not been sent, nor received, since your own connection could be delayed. - Even if there is a possibility to hide the edit or even the entire message, Android, another app, or a connected smart device could have already logged the original one. The only (flawed and incomplete) way around some of this would be a private notification/message without sender and content (handshake “message”), enforcing a reception response as soon as the app is open and only then let the server send the actual message, making any remote function for the sender obsolete again. (Something like this, where -/\> indicates end of influence of sender: Sender sends message to server -\> server sends notification for undisclosed message to recipient -\> recipient sends acknowledgment to server or _sender_, if disclosed -/\> sender auto-authorizes server if not stopped before -\> server sends message to recipient) (Also, given the arguments above, reports for sent/received / check marks in general are a mere convenience as of now and don’t serve a verifiable purpose at all.) --- ## Post 40 by @maqp — 2026-04-25T09:27:17Z > [@PurpleDime](#): > > IMHO, if the user has not seen the message, we should be able to hide all the edits from them. What you send is out of your hands by the time the recipient receives it. There’s no guarantee that the recipient’s device will abide by any request to delete or edit the message. Giving the sender vague promises about what you can achieve is poor design. The only place I see for it is collective agreement against third parties, basically, disappearing messages. The weird part is the edit feature retains the original message, but you can destroy remotely the sent message. The disparity between should be either explained, or resolved to either direction. Deleting the messages is useful if you want to take back what you said, but the “this message was deleted” messages can be even more eyebrow raising in some cases. Remote message deletion does answer a “I need to get rid of this message but I can’t reach them and we don’t have disappearing messages enabled now” threat model so I kind of get it. The trade of is cyber bullying etc where you don’t want the other person to walk over your right to retain evidence on your device. It would be interesting to know how Signal behaves if you block someone, can they still issue message deletion requests. --- ## Post 41 by @JohnDose — 2026-04-25T13:20:38Z Personally, I find the edit history a useful feature. But might as well be happy if those settings were customizable when creating the chatroom (such as in SimpleX, where various functions can be adjusted) --- ## Post 42 by @anon76815711 — 2026-04-25T14:11:03Z > [@maqp](#): > > What you send is out of your hands by the time the recipient receives it. I would argue it is already out of your hand after pressing the send button and being online, because your connection could drop right after that, the server delivers the message anyway. (Other concerns in [my post above](https://discuss.privacyguides.net/t/what-are-your-thoughts-on-signals-policy-for-edited-messages/37347/39).) I get OP’s point wanting a feature that would not show edits before first read, after all, no one would (need to) know if the edit was preemptive. > **Off-topic** > > > [@maqp](#): > > > > the “this message was deleted” messages can be even more eyebrow raising in some cases. > > I hear you, but this should be seen as the Signal equivalent of “Hey, …never mind.” IMO. > However, even in my family someone would try to read between the lines or interpret what that could have meant… --- ## Post 43 by @PurpleDime — 2026-04-25T16:33:04Z > [@anon76815711](#): > > You always have to assume you cannot correct anything once you pressed the send button, no two ways about it. That’s a good point. I personally don’t like feeling rushed when I have to reply to a message. But I often do. My contact is not necessarily putting pressure on me to respond promptly, though that can of course happen, but it’s often me wanting to reply ASAP. I am sure I am not the only one who, when they see someone make a post about a topic they absolutely want to contribute to, feels pressured to reply right away, when the reality is, there is no rush. It’s just that we really want to add our contribution immediately. Most of the time there is no rush to reply to a message, but we behave as if there is. It’s kind of like driving. I see so many people driving fast and inappropriately, even when there is no traffic, as if there is some kind of life-or-death emergency, but 99% of the time, that is not the case. People just want to rush. > [@maqp](#): > > Giving the sender vague promises about what you can achieve is poor design. Fair enough. In this case, I go back to the compromise I suggested earlier. To the extent that most people do not know that edited messages are visible, what we need is the following: > [@PurpleDime](#): > > […] a pop-up warning every time you’re about to edit a message for the first time during any given day. It would be very effective without being too cumbersome. Either once a day for the first chat in which you wish to edit a message or once a day for every chat in which you wish to edit a message for the first time during that day. > [@maqp](#): > > Deleting the messages is useful if you want to take back what you said, but the “this message was deleted” messages can be even more eyebrow raising in some cases. I disagree on this. The recipient doesn’t need to know what you deleted if they never saw it, but I think it’s good to let them know that you deleted a message. Different apps implement this differently. Signal and WhatsApp have similar implementations where they indicate a message was deleted. Telegram doesn’t show the recipient anything, which can betray the integrity of an exchange if it was reviewed later. I recently had to show WhatsApp messages for a potential lawsuit. Because I prefer to use WhatsApp on web, I took the screenshots from there. However, months after taking the screenshots, I remembered that I have fingerprinting off on Firefox, which changes my time zone. This means that if a screenshot said I received a message at 10 am, I didn’t actually receive it at that time. I actually got it at noon. The time of the message would likely not matter in the case, but if the contacts I was speaking to are in the same time zone as me, I could be accused of doctoring messages, when I didn’t. At least not intentionally. --- ## Post 44 by @anon76815711 — 2026-04-25T17:19:31Z > [@PurpleDime](#): > > Signal and WhatsApp have similar implementations where they indicate a message was deleted. Telegram doesn’t show the recipient anything, which can betray the integrity of an exchange if it was reviewed later. I agree, but there is a great counterargument: This way, Telegram eliminates one on-device evidence that there has been a specific correspondence between two parties (besides deleting a whole contact chat), which could be seen as a privacy/anonymisation benefit. Of course, one could always deny any compromisable topic, but a burst of deletion-evident messages (like in WhatsApp or Signal) tied to a specific time frame can suggest involvement in e.g. activistic events, or authoritarian regimes might even consider it obstruction of justice. > **Off-topic** > > > [@PurpleDime](#): > > > > My contact is not necessarily putting pressure on me to respond promptly, though that can of course happen, but it’s often me wanting to reply ASAP. > > […] > > Most of the time there is no rush to reply to a message, but we behave as if there is. > > I get that, which is why in the early days of WhatsApp, when there was a modded version with “invisible mode”, I used that app because of this single feature. > Also, when they introduced (or was it Telegram?) to disable read-status and online-status in exchange for not seeing them either, I was an immediate adopter. > > I can only recommend trying to make a habit out of not immediately replying to feel calmer, and also lift some expectation pressure from your contacts over time. > Downsides are forgetting the notification or dismissing it accidentally and not remembering, which also applies to messages you _have_ read. --- ## Post 45 by @PurpleDime — 2026-04-25T17:37:28Z > [@anon76815711](#): > > Of course, one could always deny any compromisable topic, but a burst of deletion-evident messages (like in WhatsApp or Signal) tied to a specific time frame can suggest involvement in e.g. activistic events, or authoritarian regimes might even consider it obstruction of justice. This is why perhaps disappearing messages is the best setting for that context. Deleting specific messages instead of a whole chat, without any notification that there was any change, can also paint a lie in Telegram. I am not convinced that they had privacy in mind with how they implemented this feature. Telegram, also doesn’t let you see previous version of messages that you edited, but I remember reading somewhere that they have access to it. Also, when they first introduced edited messages, you could edit any old message, even from weeks or months ago. So again, you could create a lie, even though there would be an indication that the message was edited. I believe that when they updated the feature, they made it so that you couldn’t edit a message after 48 hours, which is still pretty long. With Signal, I believe it’s only a couple of minutes or at best an hour. --- ## Post 46 by @anon76815711 — 2026-04-25T18:03:03Z > [@PurpleDime](#): > > Deleting specific messages instead of a whole chat, without any notification that there was any change, can also paint a lie in Telegram. I am not convinced that they had privacy in mind with how they implemented this feature. Yeah, I’m sure it was just a simpler implementation to delete a message without a placeholder, the little privacy benefit just came with it. And yes, you can absolutely abuse this to fabricate a lie or story, but one can’t deny its benefit, albeit a very small and for most people irrelevant one. It’s a double-edged sword. --- ## Post 47 by @Mitsuha — 2026-04-26T08:58:19Z > [@PurpleDime](#): > > I wish it were possible to hide edits when the recipient has not seen the message Think of it as “signal shows YOU that recipient can potentially see all edits” instead of “signal shows recipient all your edits”. There many forks of telegram that can log all edits and deleted messages, official telegram shows nothing. So people(who are using official tg) might think that if they edited/deleted message - nobody can see original message. --- ## Post 48 by @PurpleDime — 2026-04-26T10:52:09Z > [@Mitsuha](#): > > Think of it as “signal shows YOU that recipient can potentially see all edits” instead of “signal shows recipient all your edits”. This is true because to the extent that most Signal users don’t know that their contacts can see their edits, most of those contacts won’t know either. > [@Mitsuha](#): > > There many forks of telegram that can log all edits and deleted messages, official telegram shows nothing. So people(who are using official tg) might think that if they edited/deleted message - nobody can see original message. This is another thing that I didn’t know. As I said earlier, it is my understanding that Telegram has record of your edits, even though you can’t see them yourself. All that being said, I am surprised that forks of Signal and other messaging apps, allow you to view edits and deleted/disappearing messages. I have always thought of forks and modded apps as good things that allow you to have more features like block ads, but I never saw them as was to do things that are not very ethical. From a security perspective, I think it would be good for recipients to have an indicator when their contacts are using a fork or modded version of Signal. --- ## Post 49 by @Mitsuha — 2026-04-26T12:29:58Z > [@PurpleDime](#): > > As I said earlier, it is my understanding that Telegram has record of your edits, even though you can’t see them yourself. I don’t know that but if message was delivered then fork can just keep it forever. If you later delete that message, telegram fork on recipient phone can keep it and just show that this message was deleted. I’m not sure if it’s possible to mitigate that, signal clients are open source, when client get message - it can store it forever. > [@PurpleDime](#): > > From a security perspective, I think it would be good for recipients to have an indicator when their contacts are using a fork or modded version of Signal. Also not sure if this is possible with open source clients. Telegram introduced this feature recently and in couple days most of the popular forks was able to bypass it. --- ## Post 50 by @Libre_Software_Enjoyer — 2026-05-08T18:56:19Z > [@PurpleDime](#): > > ![](https://forum-cdn.privacyguides.net/user_avatar/discuss.privacyguides.net/libre_software_enjoyer/48/11842_2.png) Libre\_Software\_Enjoyer: > > > I think this is an edge case and one could formulate a different case where its good that the honest version is preserved for the reciepent > > This was just one example I gave among several. I reject the idea that the first draft or any draft that came before the final one is the “honest” version. It suggests that the final version of any text is inherently dishonest, which is preposterous. I did not mean that editing something is dishonest, but that there are many situations when its benefical if you see the unedited version