I'm also fine with keeping the option on desktop, but at least remove it on mobile. There has been a case not so far ago that user attempting to fix something just clicked around all the option and exported the keys from some profile, imported in all other profiles etc., when asked said something along the lines of "maybe I imported, maybe not, don't actually remember if i touched that setting" and it was difficult to debug what happened and why the user now has different verified and autocrypt key and has signature verification failures. The key had an user id with a different email address in there, so clearly was a key import or changed the address and reconfigured existing account.

some advanced people actually want to import their existing keys, so I will at least leave it forever in desktop as a fallback, I am not sure how big impact it is to hide the settings, most users don't go to advanced settings or touch such options unless they are actually advanced users trying to do stuff with encrypted keys, but it is also a minority the people that would want to do that and as long as desktop still allows it, it should be fine (or maybe if developer mode is enabled?)

I'd be sad to see the autocrypt setup message go away. As an ecosystem, e-mail interoperability needs to demonstrate that a person can have at least two different clients connected to their mailbox at the same time. And i'd hope that delta could be one of those clients. if delta can't share its baseline cryptographic state with other willing interoperable clients attached to the same account, then it's going to create just another silo (even if it's a much nicer and more permissive silo than many of the others in the messaging space). At the moment, if a MUA developer asks me "how can my MUA share cryptographic state with another MUA", my current answer is "try to handle (generate and produce) the autocrypt setup message; you should be able to interop with Deltachat, and can test it there."

It would be a disappointment for me if i could not point to this open offer for interoperability, even if it's not widely exercised at the moment. It is a much lighter ask to encourage interop when there is something to actually interop with.

Notice this is hidden only for chatmail servers, in which you are not supposed to use a classic MUA with since it is for chatting not for normal email and you also don't know the account password easily so can't configure a classic client, if people are using the email account they use with other MUA the option will be there

thanks for the clarification, i hope this scope is indeed limited. but as long as my cadence of message retrieval and delivery fit the expected profile, and i'm sending and receiving mostly e2ee mail, i'm still not sure why i can't use a chatmail server.

how does delta know that this is a chatmail server, by the way?

Receiving Autocrypt Setup Message is going to work even for chatmail accounts, so it is possible to import the key into chatmail profile this way.

how does delta know that this is a chatmail server, by the way?

By checking for XCHATMAIL IMAP capability. But it's really about distinguishing "chatmail" profiles from "classic email" profiles, so maybe we should change this to just remember this locally when account is created because it's two different onboarding flows.

For "chatmail" profiles we really want to avoid users managing the keys manually because the key is treated as the identity of the "profile" in Delta Chat. The profile can just use chatmail servers to relay messages, but we try to hide email addresses there.

For "classic email" users treat the email address as their primary identity, and keys are then tied to this identity via signatures.

as much as i'd like to agree with you that "classic email" with OpenPGP relies on cryptographic bindings between e-mail addresses and public keys via OpenPGP certifications, the reality is that those bindings are still widely done on an adhoc basis, with people performing some kind of TOFU (or HOFU -- "hope on first use"). Autocrypt and WKD and DANE+OPENPGPKEY offer three different automatable ways to bind e-mail addresses with OpenPGP certificates, none of which have to do with OpenPGP identity signatures ("certifications"). Anyway, if the goal is to move to cryptographic certificates as the root of identity, that's an interesting thing, but it doesn't preclude use of "normal mail" as long as those linkages are clear to all parties involved.

Interesting about the XCHATMAIL IMAP capability. are the semantics for this documented somewhere? it seems to me that this would be something that the MUAs sharing an e-mail count would need to negotiate among themselves, not something that either a server could set (or unset) unilaterally, or that a MUA could decide on their own, unilaterally without cooperative indications from the other MUAs attached to the account.