Expected behavior
Somehow include state changes (users added/removed, group title/avatar changed, etc) in a user-written message rather than sending an automated message announcing the change.
Actual behavior
The state change is autematically announced to all other group members via automated message. Here are a few big problems with doing it this way:
- The messages are worded poorly, saying “You added a new person,” or “You changed the group avatar.” It should instead say, “$USERNAME changed the group avatar,” or alternatively, “I changed the group avatar.” If it says “You,” it will make recipients think they are being accused of something, rather than being notified of something.
- The automated messages are translated into the device language. If one changes the room state using a device set to a language that the other group members don’t understand, then the automated message will not communicate what it’s meant to communicate, but will rather cause confusion and irritation.
- Sends at least one extra email that doesn’t need to be sent. Perhaps more, depending on the quantity of state changes. These will all translate into extra notifications, extra message entries in the thread (clutter), extra delta-chat style email headers which will occupy more server storage space than they need to.
Further explanation
Traditional email doesn’t have state change events as such, but rather any “state” information can change as part of any new message. Users can be added and removed without sending all participants an automated message that says You changed the room state in this way
Unfortunately, this means also that room state can be changed by any user at any time, and the changes can go unnoticed, as there is no notification of any change.
My proposed solution
- Keep the automated messages, BUT…
- If a message is already partially written when the state changes are invoked, don’t send the automated message but rather affect the changes as part of the message being composed, when it is sent. (similar to my proposal here Subject of emails - #98 by maemunman)
- If Deltachat receives an email message with an altered state included in it, the change needs to be indicated somehow, regardless of whether an automated message has been sent.
- Current behavior is rather less elegant than this: if a new message within an existing thread is received containing an altered state, there is a good chance DC will just spawn a new group to represent the state changes. This creates a disparity in user experience between sender and recipient, as a new group is not spawned for the sender, but only for (some of) the recipient(s).
Lastly, I am very tired at the time of writing. Excuse my errors, please.