let UI know that a secure-join is ongoing

[r10s]

when the UI started a secure-join (via QR code or invite link), it is already allowed to write messages.

in general, this is okay - might be eg. there was anyways some chatting before, or one device is offline and one wants to get an urgent message out.

however, with chatmail, that can send only encrypted messages, sending attempts before secure-join has finished will fail, resulting in bad UX.

otoh, we should not do add much clutter to UI: if secure-join finishes fast (as it usually does), that would result in some flickering, the user has not read whatever we wrote and gets confused. therefore, the "half blocked" dialog is not really matching.

ad-hoc, the following comes to my mind UI wise:

1. write "One moment ..." to the placeholder, but still allow tying and using attach and everything

2. if the user really manages to text their message and hit "Sent" before secure-join finishes, show a warning "sending unencrypted messages might fail"

as a side-effect, this would also target the issue with non-chatmail, that QR code scanning still allows to send unencrypted.

that is doable UI-wise without much effort.

not, that this only affects one-to-one chats - groups are not usable anyways until secure-join is finished. with instant-onboarding allowing create-account&&secure-join in one step, this becomes even more visible

core-wise, i can imagine API as dc_chat_is_securejoin_ongoing() - but i also do not have the full picuture, maybe we already have sth?

[link2xt]

In case of Alice (inviter) chat is created when vc-request is received:
https://github.com/deltachat/deltachat-core-rust/blob/17701b78d6c163dda210c117aaba0d9d0566e6fe/src/securejoin.rs#L339-L343
At this point chat is already usable for Alice because Bob sends Autocrypt header in vc-request message and Alice can get public key from it to encrypt.

So this issue is only on the Bob (joiner) side and only if Bob does not have Alice's key yet.

How bad would it be if we always create the chat as hidden ("blocked") on the Bob side:
https://github.com/deltachat/deltachat-core-rust/blob/17701b78d6c163dda210c117aaba0d9d0566e6fe/src/securejoin/bob.rs#L34-L43

We already do this in case of joining a group, so maybe it is fine not to show the chat in case of setting up contact until we get some reply from Alice? Showing this chat immediately is not nice anyway because you cannot see Alice's avatar yet.

[r10s]

So this issue is only on the Bob (joiner) side and only if Bob does not have Alice's key yet.

yes, thanks for clarifying 👌

How bad would it be if we always create the chat as hidden ("blocked") on the Bob side [...]

that would mean, there is no feedback in case of Bob or Alice are offline?

and also no permanent state being shown in case the state does not change for minutes or hours?

tbh, i am pretty happy with the current UX element, that, after scanning an invite code, always an item is added to the chatlist

We already do this in case of joining a group

i do not think, this is true. or i misunderstood :)

i just tried: even if both, Alice and Bob are offline during scanning, Bob (the joiner) sees joined group immediately, including name. Bob cannot send and does not have member list and avatar yet, but that is a minor, compared to the really nice, intuitive instant and persistent feedback

or do you mean by 'hidden ("blocked")' the behaviour that can_send() returns false. maybe we should additionally check that the chat was started by a secure-join (or is empty beside info-messages), so failing secure-joins do not make existing one-to-ones unusable.

maybe also a timeout could do the job: after a secure-join, a chat stays inactive for a 10 seconds or until DC_EVENT_SECUREJOIN_INVITER_PROGRESS=400, that would already solve a lot of issues (but we should add some info messages as for groups: "waiting for the device of Alice to reply" ... and then either "messages are guaranteed e2ee" or, if there is no key, "Alice did not reply yet, messages will not be e2ee until Alice replies")

[iequidoo]

Afair, it's prohibited to send unencrypted messages only to contacts residing on other domains? So, the core should know whether sending a message would succeed (the core only should know if we use a chatmail). Maybe just gray out the Send/airplane button if so? And add a system message explaining why it's unavailable. Optionally, if we don't use a chatmail, we can display the Send button with an unlocked padlock and in another color letting the user know there will be no e2ee

[hpk42]

On Thu, Apr 18, 2024 at 13:49 -0700, bjoern wrote: > So this issue is only on the Bob (joiner) side and only if Bob does not have Alice's key yet. yes, thanks for clarifying 👌 > How bad would it be if we always create the chat as hidden ("blocked") on the Bob side [...] that would mean, there is no feedback in case of Bob or Alice are offline? and also no permanent state being shown in case the state does not change for minutes or hours? tbh, i am pretty happy with the current UX element, that, after scanning an invite code, always an item is added to the chatlist

I agree that a new chatlist element for Bob is good as feedback. However, that Bob can currently send unencrypted messages breaks the reliability/promise of "click on this invite link to get a secure channel".

... maybe we should additionally check that the chat was started by a secure-join (or is empty beside info-messages), so failing secure-joins do not make existing one-to-ones unusable. maybe also a timeout could do the job: after a secure-join, a chat stays inactive for a 10 seconds or until DC_EVENT_SECUREJOIN_INVITER_PROGRESS=1000, that would already solve a lot of issues (but we should add some info messages as for groups)

Makes sense to me. How about roughly this: 1. If Bob's chat with Alice has no messages yet and securejoin is in progress, and Bob doesn't have Alice's key provide a system message like: "Establishing secure chat with <Alice>, please wait a bit." and set can_send=False. 2. After TIMEOUT seconds either the "guaranteed e2e established" message is there (and can_send is set to True) or we provide another system message: a. If we have no fingerprint-matching autocrypt-key of Alice: "Could not yet establish secure chat with Alice but you may already send an un-encrypted message now". b. If we have a fingerprint-matching autocrypt-key of Alice: "Could not yet establish secure chat with Alice but you may already send a message now." The TIMEOUT should be 10-20 seconds so that we are reonasably sure that the app remains active and receiving also on mobile devices. If the app is killed during this time then we may need to do step 2 for any pending bob-join chats (right now, bob can only join one chat at a time, see #2777, also worthwhile to tackle soon IMO).

[r10s]

How about roughly this [...]

sounds good and is what i also imagined roughly.

also great that we do not need any UI changes by that (apart from setting some stock strings)

thanks for the precise writeup, that should make implementation easy and pretty straight forward

however, i have no good idea about how to realise the timeout in rust, so that'd better be done by more rust ppl :)

[r10s]

i wrote the outcome of this discussion into a new issue, #5512, also thinking over events.