[Tracking Issue] Multi-transport

[link2xt]

Adding second transport and switching to it is implemented in #7348
There are APIs to list transports, add transports, remove transports and reconfigure existing transports.
Selecting the "primary transport" works by setting configured_addr to one of the already configured transports.

Closed issue: #7400

Multi-device support

UIs will have to not offer the option for multi-transport initially because users first need to update all devices to support multi-transport. In the current state user can delete all common transports from devices, and devices will not even be able to see each other sync messages anymore.

We need sync items to add transports, delete transports and maybe set primary transport. Explicit message for setting primary transport is likely not needed, we can always set the primary transport to the one we have seen the message from self last time. It is not important to keep primary transport synchronized, sending from any of the transports should be fine.

• synchronize transport addition and deletion across devices. I don't exactly like the idea of sending credentials for the transport in a sync message, but the first transport is not sent like this and for additional transports you likely use chatmail, so it is new just generated credentials and sending them to self immediately is not worse than not allowing to configure a second transport.

PR: #7485

TODO

Postponed for now:

• Do something about messages that were still in SMTP (or IMAP APPEND) queue when the primary transport is changed. Maybe resend them or mark as failed at least. Currently they are "lost": feat: allow adding second transport #7348 (comment)
• Update connectivity view to display the status of all transports. Maybe remove oboxes into mvboxes: feat: allow adding second transport #7348 (comment)
• Get rid of is_chatmail config and return one is_chatmail (or "editable") per transport so UI knows whether the transport is editable. Chatmail is not editable. For now all transports are editable, this was also the case for old chatmail profiles with a single transport, so does not need to be addressed immediately.
• ask for TURN server and notifications only on primary transport for now
• Fetch from all IMAPs in background fetch? For now we will fetch from the primary transport.

Shared mailbox settings

There are some settings that are currently configured globally that we don't want to make configurable per-transport:

• sentbox_watch (removed in feat: Remove Config::{SentboxWatch,ConfiguredSentboxFolder} (#7178) #7189)
• show_emails (defaults to showing all messages, will stay this way)
• mvbox_move (defaults to 1 for non-chatmail, will default to 0)
• only_fetch_mvbox (very special setting, defaults to 0 and should default to 0, we want to get rid of it eventually)

show_emails default is "all mails" (2). Configuring it to anything else only makes sense for "shared mailbox" usage which is not supported: https://delta.chat/en/help#can-i-use-a-classic-email-address-with-delta-chat
We don't want users to change this setting to any other value, but cannot just remove it for existing setups. For configuring second multi-transport this setting should be disabled.
See #7400 and #7348 (comment)

mvbox_move and only_fetch_mvbox will remain, but will only apply to the first transport. They should be moved to the first transport configuration in the UI.

For mvbox_move the plan is to explicitly set it to 0 when configuring the first transport, regardless of whether it is chatmail or not. It will also be required to be set to 0 to configure second transport and will not be settable to 1 if multiple transports are configured. Default in case there is no database row should remain as it is.

only_fetch_mvbox will also be required to be set to 0 to use multi-transport. Some users have a server-side rule that moves chat messages (by encrypted messages to movebox

1. mvbox_move, only_fetch_mvbox, show_emails should be explicitly set in the database when configuring the first transport. We cannot change what the "unset" value means.
2. Configuring second transport should not be possible if one of these settings is set to non-default value.
3. Changing any of these settings to non-default value should not be possible if there are multiple configured transports.
4. Changing configured_addr changes the primary transport. When setting configured_addr, it should be checked that corresponding transport exists.
5. User ID in the key should be updated with the new list of addresses or the new primary address

Android issue about using list_transports API: deltachat/deltachat-android#3970
Desktop issue: deltachat/deltachat-desktop#5648

Large part is implemented in #7348

is_chatmail deprecation

#7494

bcc_self aka "send copy to self" aka "multi-device mode"

Previously bcc_self setting was defaulting to 1 for non-chatmail and to 0 for chatmail.

Since #7440 is merged, default is always 0.
iOS issue: deltachat/deltachat-ios#2908
Desktop issue: deltachat/deltachat-desktop#5752
DeltaTouch issue: https://codeberg.org/lk108/deltatouch/issues/127

The goal is to have bcc_self turned off for all new profiles when the first transport is configured, regardless of whether "chatmail" or "classic email login" flow was used.

UIs need to always display the setting regardless of whether the profile is a "chatmail" profile. All users will see this settting and may turn it off manually if they are sure they have no other devices.

Android PR implementing this: deltachat/deltachat-android#4019

Maybe we should not turn the setting on when importing/exporting a backup on the disk instead of using "setup second device" option. If the user manually sets up a second device by moving a backup over USB, they need to enable the setting manually. The other device may enable the setting automatically because of a sync message.

[iequidoo]

Maybe we can also add smth like ShowEmails::AllFolders (but not enable it by default) for users that still want to see emails from all folders? UIs can be adapted later. #7234 should be closed anyway apparently. Scanning all folders is cheap code-wise because we anyway have code for scanning Spam, we only need to handle FolderMeaning::Unknown additionally. CC @gerryfrancis

[hpk42]

Maybe we can also add smth like ShowEmails::AllFolders (but not enable it by default) for users that still want to see emails from all folders?

No, the plan is to know for sure that all multi-transport profiles will have no shared mailboxes. You will need a dedicated address for each transport and only INBOX is ever read, nothing else.

[iequidoo]

No, the plan is to know for sure that all multi-transport profiles will have no shared mailboxes. You will need a dedicated address for each transport and only INBOX is ever read, nothing else.

I'm not sure what shared mailboxes are, but some users have server-side rules sorting emails into multiple folders and if we scan Spam anyway, we also could scan other folders as before. This logic can be disabled unconditionally for chatmail though.

[adbenitez]

I'm not sure what shared mailboxes are, but some users have server-side rules sorting emails into multiple folders and if we scan Spam anyway, we also could scan other folders as before. This logic can be disabled unconditionally for chatmail though.

"shared mailboxes" is an email account you use both for chatting/dc and classic email, using a classic email client and Delta Chat at the same time with the same inbox/account

we don't support that use case so we want to get rid of such legacy options that have low impact and complicate thinking about features and state

we also don't want to waste energy and time discussing some rare use cases like people sorting email in different folders, this is not needed, the use case is you use Delta Chat with some account and you don't need to move anything to folders, all is encrypted and in the inbox

[adbenitez]

Maybe we should not turn the setting on when importing/exporting a backup on the disk instead of using "setup second device" option. If the user manually sets up a second device by moving a backup over USB, they need to enable the setting manually. The other device may enable the setting automatically because of a sync message.

I think it is better to be safe than sorry, and enable multi-device in that case, the impact is lower than the troubles an user will be in if importing via backup and multi-device is broken