Adding a new transport and making it primary can lead to missing messages on second device

[Hocuri]

Steps to reproduce:

• add a new relay on one device, and set it as default, while the other device is offline
• Send a message to a contact, and get an answer
• -> When the other device gets online, it won't download any of the messages that arrived in the meantime

The problem is that the second transport doesn't fetch existing messages.

Possible solutions are:

1. Always fetch all messages when adding a transport.
   • Pro: Simple and easy
   • Con: If there are a lot of messages on the server already, then all of them will be downloaded after logging in, potentially wasting a lot of mobile data. This would be mostly fine, though, because we don't recommend using existing accounts.
2. The first device sends uid_next in the Transports sync message so that other devices fetch the same set of messages. Not as simple as the first solution, but probably not too complex.
3. Do nothing code-wise, maybe advise users not to immediately switch transports

Iff solution 2. doesn't turn out to be more complex than expected, I would prefer it.

cc @link2xt @iequidoo

[link2xt]

This will be mostly solved by sending messages to all relays, as long as you don't also remove the first relay immediately.

[iequidoo]

This will be mostly solved by sending messages to all relays, as long as you don't also remove the first relay immediately.

Then we need to distribute somehow the full list of relays to our contacts, including new contacts who otherwise can't know about our old relays. Also the problem remains for non- Delta Chat contacts.

Syncing uid_next and uidvalidity to other devices doesn't look complex, but it requires a db migration adding such columns to the transports table apparently. Sync messages are forward-compatible.

[adbenitez]

when we listen to all relays there will not be a concept of "main relay" anymore and user will not "change main relay" etc. so this will be solved by that, right?

[link2xt]

Then we need to distribute somehow the full list of relays to our contacts

I opened #7865 for this.

when we listen to all relays there will not be a concept of "main relay" anymore and user will not "change main relay" etc. so this will be solved by that, right?

We already listen to all relays. There will be a concept of main relay for now because we need to decide which relay to use for sending.