feat: Don't send system messages to unencrypted groups #6933
Conversation
Unencrypted groups are usually ones with other MUAs which don't understand Delta Chat system messages and show them as weird emails.
Unencrypted groups are usually ones with other MUAs which don't understand Delta Chat system messages and show them as weird emails. Self-removal returns an error now, otherwise remaining members won't know about it. It should be disabled in UIs and the user should resolve it on their own (e.g. by asking other members).
|
The other problem with this idea is that if you remove or add members, but then don't send any messages, e.g. because you have drafted something but never finished, you have still updated the timestamps of the members. And by the time you send the message, the timestamp of the change is not the current timestamp, but the timestamp of when you have added the member. |
|
It's still better than just missing functionality and most of the time it'll work as expected, an exception is if you e.g. added a member A, but another member added and removed A while you were drafting, and situations like this. The problem already exists for encrypted groups when you're offline and add a member and then draft and send a message. Maybe it's even good to send the old timestamp. If the user never finishes the draft and just forgets about the modification (moreover, no system message is added), the old timestamp may have no effect at all. |
|
An unwanted race is found however, citing @link2xt:
|
|
Another unwanted race: if the user renames a group but receives another group rename while drafting a message, the user's group name change is lost. Now i think all this is better to be done by cloning unencrypted groups. That would be much closer to what classical MUAs do by providing message trees. But cloning should be implemented in Core apparently, it should include the replied message in the new chat at least and preserve the chat name. Maybe instead of the current "Clone Chat" we should add "Extended Reply" to the message menu and if the chat name/members are modified, the reply goes to a new chat. Also, for symmetry, messages with unencrypted group name or member changes should go to a new unencrypted chat. This will resolve a race when the user sends a message and it goes to wrong recipients because of membership changes just arrived. Maybe we even should remove message assignment by In-Reply-To/References then because we also have assignment by group name + member list now (see |
|
What if we set a new recipient list + subject only in the client, and only send it to core when a message draft is started? And then don't let an incoming message override the changed parameters while a draft is set? I think cloning chats is not what users want here, because then the conversation is split up among several chats and you can't see the whole topic at one glance anymore. E-Mail is about Thread-based communication after all, not about membership-based communication like chat. Added recipients are an exception, those you might want to include in CC if someone just introduced them. We could let adding recipients happen even if a draft is set. Then again - it's not so bad if someone isn't included in CC, that happens all the time in the email world; it will just be messy to display. If a subject change is lost due to the race that doesn't matter so much, but an added recipient... |
Then various race conditions are still possible because we don't apply incoming changes to the group for some time and they may conflict with local changes or with undoing of local changes. Maybe smth simpler works here instead of accumulating changes locally, e.g.:
By not accumulating local changes we make less differences here with Delta Chat encrypted groups, particularly in relation to group membership and name consistency algorithm. |
See commit messages.
NB: Self-removal from unencrypted (ad hoc) groups returns an error now, otherwise remaining members won't know about it. It should be disabled in UIs and the user should resolve it on their own (e.g. by asking other members).