[Tracking Issue] Multi-transport

[link2xt]

Adding second transport and switching to it is already tested 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.

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 will remain global. If someone wants to configure it to something other than "all mails" (2) it is possible, but creating one transport which fetches non-chat messages and the other that does not is not going to be an option.

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

[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