if setting up another device succeeded, but bcc_self is disabled, this will cause problems in all situations the user wants to use two devices afterwards.
while since 2 years, the default is "enabled", there are still older installations - and for some providers, we use a different default (eg. nauta has bcc_self disabled by default) - so we can expect this to be an issue on quite some installations.
options to deal with that would be
(1) enable bcc_self after a successful transfer
(2) add a warning if bcc_self is disabled after a successful transfer (we should make sure, the warning is not notified or so during transfer, for the warning itself, we can just reuse maybe_add_bcc_self())
at #825 we decided not to change bcc_self for the autocrypt setup message, because of leaving user decisions alone, and decided for (2) - not sure if that is still a valid argument for backup-transfer, which seems to be much more related to actually using a seconds device.
if setting up another device succeeded, but
bcc_selfis disabled, this will cause problems in all situations the user wants to use two devices afterwards.while since 2 years, the default is "enabled", there are still older installations - and for some providers, we use a different default (eg. nauta has bcc_self disabled by default) - so we can expect this to be an issue on quite some installations.
options to deal with that would be
(1) enable
bcc_selfafter a successful transfer(2) add a warning if
bcc_selfis disabled after a successful transfer (we should make sure, the warning is not notified or so during transfer, for the warning itself, we can just reusemaybe_add_bcc_self())at #825 we decided not to change
bcc_selffor the autocrypt setup message, because of leaving user decisions alone, and decided for (2) - not sure if that is still a valid argument for backup-transfer, which seems to be much more related to actually using a seconds device.