group-member-, -name and -icon messages and non-delta-chat-clients

[r10s]

currently, in groups, we send out a separate email when a member is added, removed or when the group-name or -icon is changed. this is also true if the groups is an "ad-hoc" group created implicitly by a non-delta-chat-client.

the separate email are sent to all group members, so also to the ones that do not have delta-chat.

esp. the last point may be annoying for the receiver and may be unexpected for the sender (that changed eg. just a typo in the group name).

question is how we can reduce or even get rid of these messages - without making the shared group state more flaky.

1. we could avoid sending these messages to non-delta-chat-members (eg. by checking is_dc_message for the last N messages)
2. weren't there even ideas to get rid of the added/removed messages completely? cc @link2xt?

i both cases, somehow clients need to be eventually consistent somehow, at least not much worse as it is now :)

other ideas are very welcome, i did not thought things to the end just now, this issue is currently mainly to discuss ideas.

[link2xt]

My proposal is to deprecate dc_add_contact_to_chat and dc_remove_contact_from_chat, and replace them with dc_add_contact_to_msg(context, dc_msg_t *msg, contact_id) and dc_remove_contact_from_msg. This way member list changes can be attached to messages just like images etc.

When sent, this should result in the changes being applied and at the top of the message the text is added:

+ [email protected]
- [email protected]

if alice is added and bob is removed. This format is occasionally used in real email conversations and does not require translation.

[link2xt]

Maybe also introduce dc_msg_set_chat_id, so chat ID can be set before sending the message and the core can check if membership changes are valid for this chat.

The second argument of dc_send_msg and dc_set_draft should be set to 0 then and left for compatibility with the code that still does not use dc_msg_set_chat_id.

[Simon-Laux]

I'm against changing the ui and outside api too much, so I would prefer changes that don't change apis the UI's use. or does your proposal not result in ui changes and I miss understood?

[link2xt]

It requires changes, but will be compatible so no problem if it's implemented only on one platform at first.

Without changing UI the best thing that can be done is grouping all changes into a single message when user clicks "confirm" in group modification dialog.

[adbenitez]

grouping removals and additions in a single message would be a good first step, I am all in for not sending this changes to non-delta clients but not happy if group consistency (which is messy already) gets worse

[adbenitez]

+ [email protected] - [email protected]

this looks a bit cryptic and I am pretty sure will cause the same complains than the "member removed by me" and maybe worse because it looks more machine output than human message

[OzancanKaratas]

I think a comma-separated list of actions can be used.

I hope I didn't misunderstand and make a confusing suggestion.

[Septias]

Should we use the github discussion forum for discussions instead of using an issue labeled with discussion ?

[r10s]

Should we use the github discussion forum for discussions instead of using an issue labeled with discussion ?

i think, it is fine here. there are no so many ongoing discussions here, most of them go to the forum - and drawback would be to open another place where devs should be "in" plus another dependency that makes potentially moving away from github harder.

[r10s]

tracked more on-point at https://github.com/deltachat/deltachat-core-rust/issues/3784 now