6 ms·

> We also tried to use it, but frequently, messages will fail to decrypt with no option to retry. This is a years-old issue with Element, which never happened

> We also tried to use it, but frequently, messages will fail to decrypt with no option to retry. This is a years-old issue with Element, which never happened to me with other sending clients such as FluffyChat. It's unbelievable that it's unfixed given it's a dealbreaker as it results in permanently unreadable messages on your end (the "waiting" in "waiting for this message" is a lie). And since this needs to be fixed on the sending side, you NEED to use another messenger to fix the conversation (if at all, as this requires reading extremely long issues on github with buried suggestions many won't do). After getting it a few times most users would just dump Element and blame matrix as a failure to never touch it again. The excuse "we're working on this on the next client iteration" is actually ensuring a growing list of users will hit this (as it's bound to happen) and avoid matrix in the future. UI/onboarding issues are minor compared to the fact that the conversation can be randomly broken.

creatonez 3y ago
This just sounds like a description of Matrix's key sharing mechanism? Messages are supposed to be unencryptable if you don't have the keys, and bringing online another device (or having all your keys pre-shared so you don't have to) is what provides the keys. If you want to avoid this altogether, the UI prominently advertises the optional encrypted key backup service provided by the homeserver, and various manual options for sharing keys. If FluffyChat is not having this issue, it is probably overly eager to share encryption keys instead of allowing the user fine-grained access to control keys, which is successfully hiding the complexity of the ratchet encryption but potentially exposing the user to attacks to force the sharing of keys. Edit: I was looking around. While Matrix is well documented, Element's documentation is poor because they expect you to figure things out from popups in the UI -- fair enough, unfortunately most apps are like this, and Element's popups have gotten a lot clearer. But I did find these two pages from a university that seem to serve well as "Element's missing manual". Worth a read if you are trying Matrix for the first time, because it discusses some things that can look like bugs but are really user error. https://docs.matrix.kit.edu/en/settings/ https://docs.matrix.kit.edu/en/settings/ https://docs.matrix.kit.edu/en/faq/ https://docs.matrix.kit.edu/en/faq/
- rcxdude 3y ago
  reading a manual for a chat app to fix 'user error' that results in bizarre behaviour like this is not a reasonable solution.
- wakeupcall 3y ago
  A bit late to respond, but this is not an user error. From the bug description it SEEMS (because there's still zero feedback from the dev's front) that it's Element itself failing to send the keys in the first place, probably due to a mishandled connection/transmit error and not attempting to retry. It's not a protocol error, unless you count the fact there isn't a mechanism in place to ack at least asynchronously that decryption is ok. This is compounded by the fact that there seems no mechanism to recover for the receiver. The receiving client is just oblivious, it will _never_ be able to decrypt the messages and thus also never be able to backup the session keys if none of the clients associated with the account ever received the keys. The suggested work-around is forcing the sending client to rotate the session keys earlier and thus fix the _following_ messages only. I've been in situations where two element clients (both sending and receiving) failed to decrypt each other's messages. This is a pretty damning issue for a client that enables encryption by default.

creatonez 3y ago

This just sounds like a description of Matrix's key sharing mechanism? Messages are supposed to be unencryptable if you don't have the keys, and bringing online another device (or having all your keys pre-shared so you don't have to) is what provides the keys. If you want to avoid this altogether, the UI prominently advertises the optional encrypted key backup service provided by the homeserver, and various manual options for sharing keys. If FluffyChat is not having this issue, it is probably overly eager to share encryption keys instead of allowing the user fine-grained access to control keys, which is successfully hiding the complexity of the ratchet encryption but potentially exposing the user to attacks to force the sharing of keys. Edit: I was looking around. While Matrix is well documented, Element's documentation is poor because they expect you to figure things out from popups in the UI -- fair enough, unfortunately most apps are like this, and Element's popups have gotten a lot clearer. But I did find these two pages from a university that seem to serve well as "Element's missing manual". Worth a read if you are trying Matrix for the first time, because it discusses some things that can look like bugs but are really user error. https://docs.matrix.kit.edu/en/settings/ https://docs.matrix.kit.edu/en/settings/ https://docs.matrix.kit.edu/en/faq/ https://docs.matrix.kit.edu/en/faq/

rcxdude 3y ago
reading a manual for a chat app to fix 'user error' that results in bizarre behaviour like this is not a reasonable solution.
wakeupcall 3y ago
A bit late to respond, but this is not an user error. From the bug description it SEEMS (because there's still zero feedback from the dev's front) that it's Element itself failing to send the keys in the first place, probably due to a mishandled connection/transmit error and not attempting to retry. It's not a protocol error, unless you count the fact there isn't a mechanism in place to ack at least asynchronously that decryption is ok. This is compounded by the fact that there seems no mechanism to recover for the receiver. The receiving client is just oblivious, it will _never_ be able to decrypt the messages and thus also never be able to backup the session keys if none of the clients associated with the account ever received the keys. The suggested work-around is forcing the sending client to rotate the session keys earlier and thus fix the _following_ messages only. I've been in situations where two element clients (both sending and receiving) failed to decrypt each other's messages. This is a pretty damning issue for a client that enables encryption by default.