feat: default bcc_self to 0 for new accounts

[link2xt]

This is part of #7357 needed to get rid of is_chatmail distinction between profiles. Previously the setting was default to 1 for non-chatmail and 0 for chatmail.
See also previous PR #7440

[iequidoo]

It's better to change the default to 0 then and add a db migration for old accounts which sets 1 for non-chatmail. We always did it this way before. This way if it's set to 1, we know it's set by us, not by the user (EDIT: probably):

• Either by the migration
• Or by the multi-device detection logic.

And if it's set to 0 explicitly (not to None), that's definitely done by the user.

[link2xt]

Knowing whether the user has ever changing the setting manually looks like future-proofing for a never happening future. We already don't know if it was set to 1 by the user because we set it automatically. And we don't need to know if it was set to 0 by the user, we still want to set it to 1 when setting up a second device regardless of whether the user has ever turned it off.

[iequidoo]

And we don't need to know if it was set to 0 by the user, we still want to set it to 1 when setting up a second device regardless of whether the user has ever turned it off.

True, but changing a user-modified setting from version to version silently isn't what a software normally does. Usually it's suggested to merge the config or at least to review the new settings.

[link2xt]

As for changing the default and migration for old accounts vs setting the new default in configure(), migrations have many problems:

1. Migrations may affect existing users. If the migration is incorrect, it will break setups of many users.
   Changing the default set during configuration cannot affect existing users because they don't run configuration.
2. Migrations are not tested. They have to be tested manually in all configurations. Setting the new default during configuration is tested immediately by CI and the only case that needs to be tested is fresh setup.
3. Users sometimes downgrade during "setup second device", e.g. if they have new desktop and setup somewhat outdated F-Droid build as second device or copy from new Android/iOS to outdated desktop setup.
   When we change how we treat missing settings by setting default, it means that the setting may change the value during the downgrade.
   It seems to be not the case for this change because we change the default to "0" and for all cases where we have previously treated it as "1" we store it manually in the database, but this is only checked manually.
4. Migrations prevent testing with existing setups. We cannot just test PRs with migrations with our accounts without making a backup. Once merged to main, they cannot be reverted without coordination with everyone who may have ran it.

I think we need to write down something regarding avoiding SQL migrations when possible in STYLE.md.

I have added a migration to this PR now to get rid of complicated logic in the default that depends on IsChatmail which we need to remove eventually anyway because of multi-transport.

But I still need to test the migration manually for chatmail and non-chatmail before merging, I think so far it was not executed at all by anyone because CI is not testing it.

[link2xt]

I did some manual tests.

1. Setup a non-chatmail account with mailo.com before migration.

> set addr xxx@mail.com
> set mail_pw ...
> configure
> get bcc_self
bcc_self=Ok(Some("1"))

2. Setup a chatmail account before migration.

setqr dcaccount:ci-chatmail.testrun.org

At this point REPL said "Config set from QR code, you can now call 'configure'", but the account is already configured at this point. (opened #7450 )

> get bcc_self
bcc_self=Ok(Some("0"))

3. Switched to this branch with migration.

> get bcc_self
bcc_self=Ok(Some("1"))

4. Running new branch with mailo.com database.

> get bcc_self
bcc_self=Ok(Some("1"))

Version is 139 in the "info" output.

5. Running new branch with chatmail database.

> get bcc_self
bcc_self=Ok(Some("0"))

Version is 139.

6. Removed everything, switched to old version again.

7. Setup mailo.com in the first database, set bcc_self to 0 manually.

Configured mailo.com again, checked the database version is 138, ran set bcc_self 0.

8. Setup a new chatmail account in the second database, but set bcc_self to 1 manually.

9. Updated to this PR with db version 139.

10. Opened mailo database

> get bcc_self
bcc_self=Ok(Some("0"))

11. Opened chatmail database

> get bcc_self
bcc_self=Ok(Some("1"))

[hpk42]

On Sun, Nov 16, 2025 at 10:54 -0800, iequidoo wrote: @iequidoo commented on this pull request. > @@ -146,6 +146,9 @@ pub enum Config { /// /// Should be enabled for multidevice setups. /// Default is 0 for chatmail accounts, 1 otherwise. + /// The default is only used for old accounts. > And we don't need to know if it was set to 0 by the user, we still want to set it to 1 when setting up a second device regardless of whether the user has ever turned it off. True, but changing a user-modified setting from version to version _silently_ isn't what a software normally does. Usually it's suggested to merge the config or at least to review the new settings.

"multi-device" setting is at best something we don't even offer in UI. It should just work. Asking users to "merge the config" and "review new settings" might be fine for linux-distro level things but it's certainly not what happens for users of instant messengers like Whatsapp or Signal. Talking about "a software" is a much too broad focus for discussing the issue at hand.

[link2xt]

Asking users to "merge the config" and "review new settings" might be fine for linux-distro level things

It's not fine even for Linux distro, I don't like that maintainers ship default configs in the same location as production configs instead of some examples directory and I have to merge them manually each time I update. This might have been fine when updates were received on CDs every few years or if you never update to the next major release.

[iequidoo]

With "review new settings" i meant adding a device message like "Send copy to self" was auto-set to 0 on update to version X. You may want to review it because you set it manually. Most users won't see it because they don't touch it or even use chatmail, so it may be untranslated.