chatmail
Chatmail accounts can't initiate handshake without an already-established second channel
This issue affects all deltachat client UIs, but is rooted in the design of the chatmail servers, so I'll add it in this repo.
Scenario:
- A doesn't use any messengers yet, (or at least none that B uses) and installs deltachat. Following the pattern on the configuration screen, they get an account at nine.testrun.org. Someone else initiates a conversation, which works fine.
- A wants to chat with B on deltachat, who is not near them. (Or both of them use devices without working cameras, likewise, QR-code handshakes aren't possible).
- a. They get B's deltachat/mail address from C (which could be a person, a piece of paper, or a website). Expected process: A types B's address into deltachat and initiates a handshake. Reality: There is no possibility to type in an address of a potential chat partner. b. A gets B's deltachat/mail address from C via a deltachat message. Expected process: A clicks/taps on the address and initiates a handshake Reality: A gets a pop-up that tells them they can't chat with B (and need to set up the connection using a second channel, preferably the QR code). Side note: Today, the author and both A and B struggled half an hour with this until A installed signal just to be able to chat with B, and only afterwards we found out how the second channel handshake works without a QR code. So, while this issue only is a technical barrier if there is no established second channel and no way to scan QR codes, I find it to still be a huge skill barrier if a remote second channel exists, and people might (or, in today's example, did) decide to stick to the second channel altogether.
Proposed solution:
Allow chatmail servers to send the invite message unencrypted and, in deltachat, add a button to the popup described under 3b that initiates the handshake by sending the invite link to the mail address that was typed in/clicked on. If B already uses deltachat, they should then see a message along the lines of "A wants to chat with you. Accept?" and upon accepting, the handshake should be initiated as if B clicked on the link in a second channel, while a B who doesn't use deltachat (yet) sees the extant invite message in their mailbox. Also, in the deltachat UI, re-add the possibility to manually add contacts and present the prompt to initiate handshake as if they clicked on an address in a deltachat message.
- A wants to chat with B on deltachat, who is not near them. (Or both of them use devices without working cameras, likewise, QR-code handshakes aren't possible).
That's what the "Invite Link" is for under your QR code. You send this to them via any other method. Plaintext email, SMS, another chat service. Was there really no other option? You mentioned that you installed Signal to share the QR code, so you had their phone number and could have used SMS.
If for some reason they cannot click that link which would automatically open DeltaChat, then on the "Scan QR Code" screen there's a button in the upper-right corner that reveals a "Paste from Clipboard" option. This allows you to ingest the link this way.
The QR code is not a requirement, it's just a convenience.
Adding a way to add contacts manually without knowing their public key recreates the original problem that people experience with initial messages not being encrypted which people experienced if they were not using Chatmail servers.
I'm trying to figure out where the miscommunication is here from the DeltaChat side. Did you have the impression that it would be unsafe to share the QR code or invite link over an insecure channel?
Note: to be clear, I do not speak for the project
You send this to them via any other method. Plaintext email, SMS, another chat service. Was there really no other option? You mentioned that you installed Signal to share the QR code, so you had their phone number and could have used SMS.
We could not have used SMS, because B has signal on their laptop only. Also, while signal still needs a phone number to sign up, they don't need it to chat anymore, in fact they discourage from using the phone number to setup a conversation.
Also, if there already is an established second channel, why use deltachat? In our case, A didn't install signal to share the invite link or QR code, but to replace deltachat entirely as we couldn't figure out how to initiate a handshake.
I'm trying to figure out where the miscommunication is here from the DeltaChat side. Did you have the impression that it would be unsafe to share the QR code or invite link over an insecure channel?
We didn't see the invite link sans-QR-code at all, until A and B decided they would abandon deltachat and stick to signal.
If unencrypted handshake initiations are considered a problem, I don't see a solution for scenario a), which is a very common way how people establish chat contacts, so chatmail may be too secure for usability. Scenario b) could maybe be solved via some web-of-trust voodoo by using the existing trusted connections A-C and B-C as a behind the scenes second channel?
Chatmail as it is breaks deeply ingrained habits. Maybe those habits should be broken, but you have to at least guide people to new habits, and deltachat with chatmail at the moment fails to do so. The very least one could do is to warn that using chatmail comes with enhanced security at the cost of treasured comfort and habits before setting up a new profile. Because now, people who aren't deeply familiar with how chatmail works will setup an account and run into this problem and may decide that deltachat is inusable.
To drive the message home, this is the popup A gets in scenario b):
Granted, scenario b) might be solved in the user interface - make it waaay easier to send contacts as vcards than as pure email address. (This does the web-of-trust voodoo I mentioned above.) Atm, it's sligtly easier to send contacts the "right" way on android, but I find it easier to do it the "wrong" way on desktop.
On Thu, Feb 27, 2025 at 03:29 -0800, Wurzelkoch wrote:
Wurzelkoch left a comment (chatmail/server#472) Also, if there already is an established second channel, why use deltachat?
The second channel secures the end-to-end encryption between A and B. The server can not break "guaranteed encryption" if it's secured like this.
Second channel can be physical or a video call for QR-code scanning, or one needs to transfer a link "somehow" (any other messaging channel, including direct messages on social messages). We know of many users who succeed with this step but wording and flows can be further improved, for sure.
In any case, Signal also uses a second-channel, namely phone number network for registration. If you don't mind providing your phone number and relying on US servers, and are not interested in delta's chat-shared tool and game ecosystem, then there is not much point in using Delta Chat instead.
