Scanning QR for existing contact doesn't update relay list

[DarkCat09]

• Operating System (Linux/Mac/Windows/iOS/Android): any
• Core Version: 2.51.0
• Client Version: AC 2.51.0

Both users suddenly lost connectivity to all of their relays. They added another relay, which is accessible, and set it as main. Of course, they still couldn't communicate, because there was no way to announce a new relay list to each other (clients know only about old relays so they try to send updates there).

That's why the friends used a different channel (e.g. met IRL) to send their QR codes once again.

Expected behavior

They would expect that clients update their relay lists according to the contact info inside the QR codes, and they can continue talking in Delta.

Actual behavior

But Delta Chat client doesn't update a list of announced relays on scanning a QR in case a contact already exists. It simply opens the existing chat without altering any contact info.

Now, both users have no way to restore connectivity between their profiles unless the old relays are accessible (if users don't delete them).

Steps to reproduce the problem

0. Create two profiles and init a DM chat between them.
1. Block the chatmail relay(s) that these profiles are connected to, e.g. with iptables.
2. Add new relay(s) to these profiles, set it as a main relay instead of the blocked one.
3. Try to send messages in DM, expected to not work.
4. From the first profile, generate a contact link or QR code, and then try to add a new contact by this link/QR from the second profile.
5. Relay list in "Encryption info" doesn't change, profiles still can't send messages to each other, this is unexpected.

Screenshots

Anyone needs?
I can make a screencast on reproducing the issue.

Logs

N/A

[DarkCat09]

both users have no way to restore connectivity

Actually, there is a way, even multiple, but a third profile is required.

• They can ask the third person to add them to the same chat. I'm not sure how exactly this works (probably smth related to securejoin protocol), but after they join, relay list gets updated.

• Alternatively, 1st user can ask 3rd user to send them a contact of 2nd (as an attachment) and import the contact. It's sufficient to restore connectivity, 2nd user doesn't have to do anything.

[link2xt]

They can ask the third person to add them to the same chat. I'm not sure how exactly this works (probably smth related to securejoin protocol), but after they join, relay list gets updated.

When new member is added to the chat, Autocrypt-Gossip headers are sent with the keys of all members, to make sure new member has the keys of everyone else and everyone else has the key of a new member. Public keys contain the list of relays in the direct key signature.

[hpk42]

we probably can remove the securejoin shortcut for "key already known" at https://github.com/chatmail/core/blob/main/src/securejoin/bob.rs#L100-L118 and always run the full protocol. We need to make sure alice and bob use the new QR/From addresses for exchanging handshake messages respectively, without regarding them as authenticated like when they come from keys. update probably removing the shortcut is not neccessary and not really the problem. it's rather that alice must use bob's From address for replying to bob. I might give this a try in a PR, already have a failing python test ...