add api `dc_create_email()` and `dc_list_address_contacts()`

[r10s]

as dc_create_group_chat() can no longer be used to create "unencrypted groups", we aim for a new api to create a email-like group.

that api would first time make the subject a primary option 🎉 cffi would look lilke ...

uint32_t  dc_create_email(dc_context_t* context,  const char* subject);

... and jsonrpc similar. would also be fine to only add jsonrpc.

in the UIs, in case of non-chatmail accounts, we will then have an option "New E-Mail" beside "New Group"

EDIT: Citing #6932 (comment):

We also need API to list email contacts. Otherwise there is no way to create anything other than a group with only self.
Maybe even a separate PR because it is useful by itself to modify existing adhoc groups.

[Simon-Laux]

so email chat would be basically a single email thread with a fixed subject?
is there a document/post that explains the big picture of these email changes?

[r10s]

not that i know of :)
it is all about internal discussions :)

[iequidoo]

AFAIU create_group_chat() with protect=false can't be reused for this (even if it's not used by the UIs) because it still creates a group chat which can only have pgp contacts. The only difference is that it can have unverified contacts.

[iequidoo]

At the Core level we currently have

pub async fn create_group_chat(
    context: &Context,
    protect: ProtectionStatus,
    chat_name: &str)

I'd add

pub async fn create_group_ex( // No "_chat", we're in the chat module, let's switch to namespace style.
    context: &Context,
    pgp: Option<ProtectionStatus>,
    name: &str)

and implement create_group_chat() as a wrapper (maybe deprecated).
At the json-rpc level i'd add create_group_chat_nopgp() or create_address_group_chat() because it's still a group chat technically (how it is called/translated in UIs is another thing). I'd avoid using the word "email" because currently we don't use it in the Core for this purpose. Overall the naming should be consistent and use less different words, having the terms "pgp contact" and "address contact" is enough (it's obviuos that an email address is meant).

EDIT: There's Chat::is_encrypted() in Core and {FullChat,BasicChat}::is_encrypted in json-rpc. Then better to use this words instead of "(no)pgp", at least for chats.

[hpk42]

On Sat, Jun 21, 2025 at 15:52 -0700, iequidoo wrote: iequidoo left a comment (chatmail/core#6927) At the Core level we currently have ```Rust pub async fn create_group_chat( context: &Context, protect: ProtectionStatus, chat_name: &str) ``` I'd add ```Rust pub async fn create_group_ex( // No "_chat", we're in the chat module, let's switch to namespace style. context: &Context, pgp: Option<ProtectionStatus>, name: &str) ``` and implement `create_group_chat()` as a wrapper (maybe deprecated). At the json-rpc level i'd add `create_group_chat_nopgp()` or `create_address_group_chat()` because it's still a group chat technically (how it is called/translated in UIs is another thing). I'd avoid using the word "email" because currently we don't use it in the Core for this purpose. Overall the naming should be consistent and use less different words, having the terms "pgp contact" and "address contact" is enough (it's obviuos that an _email_ address is meant).

the way how we think and discuss delta chat mechanics, also on the UI side, has changed constantly the last years. With pgpbranch, chat identify is controled by a secret key and not by an email address. UX/UI has been gradually shifting towards reducing email addresses as identifiers. With the upcoming pgpbranch releases that dance will be complete. "Email address" or "email contacts" are then by definition cleartext. For vertical naming consistency, it is better to name the jsonrpc/ffi APIs "create_email" or similar. Core and UI "nouns" in APIs are easier to make sense of if consistent.

[missytake]

There was also some discussion at DIFF to not send out member_added and other system messages in email chats, but otherwise mostly keep the UI the same. The recipients would receive changes in membership or subject with the next email that is sent by the user (with the send button).

[Simon-Laux]

There was also some discussion at DIFF to not send out member_added and other system messages in email chats, but otherwise mostly keep the UI the same. The recipients would receive changes in membership or subject with the next email that is sent by the user (with the send button).

sounds different than what's in this desktop issue:

hide "add member" and "show QR invite" buttons for non-pgp group chats and disable/hidde option/button to remove members (available API: FullChat.is_encrypted)
~ deltachat/deltachat-desktop#5059

---

My thoughts on situations like this:

It is impossible for me to check if sth. is missing in the plan or what the current version/state is, if it is not documented. would be great to have a minimalistic protocol/log of the internal discussions that mentions the result and the considerations/decisions that were taken.
abstract + bullet points on the considerations would already be plenty.

Would save tons of questions if there was a list of decisions, like "we know you can not change recipients anymore in an existing email group and this is intentional because of <technical reasons> and we promote clone group instead for the use case of adding someone" (this is a made up example statement, because I don't know your plan)

[r10s]

at least for the first iteration, it seems fine to not allow membership changes or subject changes at all,
esp as they're also not possible for ad-hoc groups created by incoming mail.

[iequidoo]

esp as they're also not possible for ad-hoc groups created by incoming mail.

Moreover, technically at the core level non-pgp group chats and ad-hoc groups will be the same thing in the pgp-contacts branch (in main the former have grpid-s generated locally). They are just created in different ways.

There was also some discussion at DIFF to not send out member_added and other system messages in email chats, but otherwise mostly keep the UI the same. The recipients would receive changes in membership or subject with the next email that is sent by the user (with the send button).

Btw, i think it's quite easy to implement in Core and this way not to complicate the UIs' logic. We have working group membership consistency algo now, and the same algo is used for group names. It's fine to publish changes to a group later, conflicts will be resolved using timestamps passed in messages.

EDIT: Still there are races possible. Imagine Alice renaming the group but making a typo, and then sending a message. Then, say, Bob renames the group completely but doesn't send a message immediately. Then Alice fixes the typo and her group name finally wins which looks wrong. EDIT: The same race is possible with immediately sent messages of course, just less likely.