[rakoo]

> No multi device support.

That's an issue with your client and protocol, not with e2e

> No shared history for group chats.

Same

> Scaling get progressively harder with increasing participants.

Same

> No transcoding for video.

Now that's a more palpable issue. Also no size reduction of photos which is probably more used as a media.

[vetinari]

> That's an issue with your client and protocol, not with e2e

That's issue with distributing the keys among multiple parties.

> No shared history for group chats.

> Same

Exactly. What's e2e good for, if you give keys to the entity that does the archiving?

[rakoo]

If you have 2 devices, one device can send messages to the other, all e2e encrypted. It's the same for group chats: if you are part of a chat, any participant can send you the history of the chat.

All those issues are protocol-related. E2E only stipulates that the message can't be read between the two ends, it doesn't say you can't send a technical message for making a better UX.

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

[est31]

Doesn't even have to send the full history of the chat, it can only send you the encryption key while the history is stored on the server.

[rakoo]

Indeed, and you can go even further: with e2ee there is no need for central server beyond dumb distribution of opaque blobs. So the history can be exchanged by the whole network and the encryption keys shared recipient by recipient on a need-to-know basis. That's what bitmessage is doing, for example

[vetinari]

(At least Threema does it this way): Server doesn't really store the messages long term; only until the receiver picks it up. With just two devices - sender and receiver - you have a guarantee that once the single receiver picks it up, there's none else to do the same and can be safely dropped.