[vetinari]

> if you are part of a chat, any participant can send you the history of the chat.

Re-sending parts of the chat kind of removes the guarantees of the secret chat (just like backups defeat the purpose of e2e). These apps have also expiring and non-screenshotable messages, you don't want to resend that.

Ideally, all messages sent should be only decryptable by given set of keys (i.e. one key for each device used by each party of the chat; or, depending on the size of the message, ephemeral key used for message encryption, decryptable by each device that is supposed to receive it). Now the key distribution is the non-solved part.

[rakoo]

"Secret chat" is something only Telegram and pseudo-private messengers have. No application can ever provide assurance that messages aren't backed up. When it's sent, it's sent; you don't control it anymore. Re-sending the message is something you can only assume can be done. The experience given with expiring messages is just that: an experience.

Now, secret chats don't necessarily mean "this message can only be read by one device". To answer your second paragrah I disagree: a message shouldn't be sent to a given set of keys but to a given set of participants. Each participant may have one or more devices and should be able to read messages whatever way they want.

Also key distribution is "solved" by not counting on the user to do it but doing it for them: see what Matrix, Signal, Deltachat, XMPP (OMEMO) and probably others are doing.

[vetinari]

I disagree; if you are sending to participants instead of devices, you don't really have e2e. Any private key should never leave any device. If the user want to use several devices, his client should enroll multiple keys for him and the message should be decryptable by each of these keys. Also, the user should have visibility into which keys can decrypt the message, to avoid enrolling any keys behind his back.

That the user won't see on his device any messages sent before enrolling the new key? That's the point. Otherwise, the user should use the normal/non-e2e messages.

Thus, the key distribution as it is "solved" is being lax with them.