+
Skip to content

feat: Don't apply chat name and avatar changes from non-members #6976

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 9, 2025

Conversation

iequidoo
Copy link
Collaborator

@iequidoo iequidoo commented Jul 4, 2025

Non-members can't modify the member list (incl. adding themselves), modify an ephemeral timer, so they shouldn't be able to change the group name or avatar, just for consistency. Even if messages are reordered and a group name change from a new member arrives before its addition, the new group name will be applied on a receipt of the next message following the addition message because Chat-Group-Name-Timestamp increases. While Delta Chat groups aimed for chatting with trusted contacts, accepting group changes from everyone knowing Chat-Group-Id means that if any of the past members have the key compromised, the group should be recreated which looks impractical.

This is in continuation of the discussion in #6901.

Non-members can't modify the member list (incl. adding themselves), modify an ephemeral timer, so
they shouldn't be able to change the group name or avatar, just for consistency. Even if messages
are reordered and a group name change from a new member arrives before its addition, the new group
name will be applied on a receipt of the next message following the addition message because
Chat-Group-Name-Timestamp increases. While Delta Chat groups aimed for chatting with trusted
contacts, accepting group changes from everyone knowing Chat-Group-Id means that if any of the past
members have the key compromised, the group should be recreated which looks impractical.
@iequidoo iequidoo requested review from Hocuri and link2xt July 4, 2025 22:19
@Hocuri
Copy link
Collaborator

Hocuri commented Jul 6, 2025

Non-members can't modify the member list (incl. adding themselves),

Really? Then I was remembering this wrongly. cc @link2xt

@iequidoo
Copy link
Collaborator Author

iequidoo commented Jul 6, 2025

Really? Then I was remembering this wrongly.

This if is_from_in_chat around which i moved the code is exactly for accepting membership changes only from members.

NB: This PR breaks applying a new group avatar from a just added member if messages are reordered, but i'm not sure it's a frequent scenario. Alternatively, we can leave the code as is and add a comment why we allow group name changes from non-members, but forbid ephemeral timer changes (maybe ephemeral timer is a more critical thing, but i'd say that the group name too because a wrong one can break chat search for users).

@link2xt
Copy link
Collaborator

link2xt commented Jul 9, 2025

Non-members can't modify the member list (incl. adding themselves),

Really? Then I was remembering this wrongly. cc @link2xt

Yes, we ignore the changes by non-members. In theory (https://github.com/chatmail/models) we apply the changes because otherwise no nice properties hold and reordering of messages may break consistency, but in practice we ignore the changes if they come from non-member. This was changed in #6436

@iequidoo
Copy link
Collaborator Author

iequidoo commented Jul 9, 2025

In theory (https://github.com/chatmail/models) we apply the changes because otherwise no nice properties hold and reordering of messages may break consistency, but in practice we ignore the changes if they come from non-member.

Eventual consistency still preserves, i.e. if all members continue to send messages and no new group membership changes happen, all members will have the same member list eventually. I think this is sufficient

@iequidoo iequidoo merged commit 374a5ef into main Jul 9, 2025
29 checks passed
@iequidoo iequidoo deleted the iequidoo/apply_chat_name_and_avatar_changes branch July 9, 2025 20:39
@link2xt
Copy link
Collaborator

link2xt commented Jul 9, 2025

In theory cases like this break:

  1. Alice removes Bob.
  2. Alice leaves the group.
  3. Everyone in the group gets the message that Alice left.
  4. Everyone in the group gets the message that Alice removed Bob.

Now nobody thinks that Bob is removed except Alice. The group can be in this "inconsistent" state indefinitely.

Eventually Alice is added back to the group and with the next message "implicitly" removes Bob.

@iequidoo
Copy link
Collaborator Author

  1. Everyone in the group gets the message that Alice removed Bob.

I think that if this message has Date between Alice's joining and leave timestamps (inclusive), it should be applied. We don't do this currently though (maybe we should if it's easy to implement).

Various group partitioning scenarios are broken, like Alice and Bob remove each other in parallel (and there are no other members, for simplicity), and now there are two separate groups -- one with Alice and another with Bob. But i think it's more practical to allow group partitioning than trying to fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
点击 这是indexloc提供的php浏览器服务,不要输入任何密码和下载