> but if they "actually delete it"--which I imagine you want--then they might also forget any unique identifier stored with the message, which likely makes it hard to know that this message was both already received and deleted in the past.
I would expect any messaging app to work like email, where you're also in control of the email server. Once you receive someone else's message, it's in your inbox, and you can delete it forever as well. The email message model is more intuitive, and I would love for modern instant messaging clients to work the same way except in real time. Of course when you have that level of control, you would need to make it paywalled or subscription of some kind.
The other is deleting a message that was sent to someone else from _their_ inbox. Which email does not allow you to do.
Except some clever people tried to implement this (notably Outlook and/or Microsoft Exchange has such a feature IIRC) where it sends another email to "recall" the earlier message. It's funny when you receive those recall messages in a non-Microsoft email client and on a different server than the Exchange sever they're using. I.e. you just ignore their request to recall and now you _really_ go read the message they're trying to recall, because it makes it _more_ interesting. Also googling this quickly it seems even if you stay completely within the Microsoft ecosystem it only works if the recipients didn't open the original email yet:
With message recall, a message that you sent is retrieved from the mailboxes of the recipients who haven’t yet opened it.
Regardless what I'm really saying is that it's all probably smoke and mirrors on the client server (plus client UI). The server is probably configured to keep all messages anyway, and it gets "tombstoned" and not sent by the middle tier server. I don't know of course, but I was talking about how users are not really in control as they think they are.
Yes I'm sure that is the feature on paper. There's no way to know (unless there's a leak or something) but I'm willing to bet this isn't really the case and there are backdoor keys to this encryption, if anything to comply with whatever government wants, as has been the case with Apple and iPhone encryption in the past already.
The email model was just an example of how, in my opinion, it should be simple and straight forward. We're just talking about people sending text to other people, just like email. The only difference is on the client side, so how fast it happens and what kind of interface is presented with features to interact with the data. Ideally like owning your own email server, you would control not just the interface but the database with the data as well. This could mean some redundant messaging if the other server decides to send it again, but that isn't really a problem.
This whole industry is meant to harvest user information. Richard Stallman tried to warn us. Jaron Lanier called it "siren servers", because they hypnotized people into using their services. I hope this encourages people to question this and and to look for alternatives.