Skip to content
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

Add self to the group when a MUA reply is received #4624

Closed
anaskaejdar opened this issue Aug 18, 2023 · 4 comments
Closed

Add self to the group when a MUA reply is received #4624

anaskaejdar opened this issue Aug 18, 2023 · 4 comments
Assignees
Labels
bug Something is not working

Comments

@anaskaejdar
Copy link

anaskaejdar commented Aug 18, 2023

  • Operating System (Linux/Mac/Windows/iOS/Android): Android
  • Delta Chat Version: 1.38.4

Expected behavior:

There are at least a couple ways it could be handled:

  • Deltachat would ignore a user added via a traditional MUA if that user was recently removed from the group. Deltachat would not put this user back into the member list. (I believe this is by far the more preferable behavior.)
    • Maybe DC considers whether the message is a reply to a previous message that was sent before the user was removed from the group.
  • The removed user's deltachat client would recognize that he/she has been added back into the group by the traditional MUA user.

Actual behavior:

It creates a major discrepancy in room state between the removed user and all the other users. The deltachat user that was removed continues to receive messages, but cannot himself send anything to the group. Why? His deltachat still only thinks he has been removed from the group. From his own perspective, he does not appear in the group's member list, and thus the text box et al are hidden away.

The strange part is that the other deltachat users in the same group will perceive that he is a member once again. He will appear in the member list just as before. For this reason, he will continue to receive messages from the group, though he cannot respond to them.

Steps to reproduce the problem:

  1. Have a bunch of email addresses to test with
  2. Make a group of three or four (or more) addresses.
  3. Send a message to the group
  4. Remove one of the members
  5. From a different address, and using a traditional MUA like K9Mail, send a reply-all in response to the earlier message (step 3)
  6. (notice: The removed user is almost certainly there in the To: field)
  7. In deltachat, perceive that the removed user is once again included in the member list, because of his inclusion in the traditional MUA message (step 5).
  8. In deltachat, send a message to the group
  9. (notice: The removed user received the message.)
  10. Try to send something to the group in deltachat, from the user that was removed in step 4.
  11. (notice: You cannot send anything to the group, as the text box is hidden away from you.)
  • Screenshots:
  • Logs:
@gerryfrancis
Copy link
Contributor

gerryfrancis commented Aug 22, 2023

@anaskaejdar Thank you for your very detailed report. I think the origin of the problem is the fact that messages about the removal of group members are sent to the affected members as well. Thus, messages sent from a MUA as reply to all afterwards are not helpful and will re-add already removed members to groups. As we cannot prohibit a MUA group user to send messages to already removed group members, the question at hand would be how to deal with such situations.

I could think of sending the removal message (which is the last a removed member is expected to receive) as bcc to the member who is about to be removed from the group. Then, when a MUA group user was about to reply to all afterwards, the removed member would not be applied to the list of recipients automatically anymore.

@link2xt
Copy link
Collaborator

link2xt commented Aug 24, 2023

This was likely introduced in #4185

The user being added back to the group as a result of a reply to an earlier message is expected, so as I understand the bug is that the removed user does not recognize that it is re-added. Then the solution is

The removed user's deltachat client would recognize that he/she has been added back into the group by the traditional MUA user.

@anaskaejdar
Copy link
Author

anaskaejdar commented Aug 25, 2023

Sounds good to me. The BCC idea is great, also.

Additionally, maybe if DC thinks you've been removed from a group, rather than merely hiding the input fields, it could replace them with a little message explaining why they're gone, and a button to _un_hide them if the user wants.

@link2xt link2xt changed the title Kicked users go to purgatory Add self to the group when a MUA reply is received Aug 25, 2023
@iequidoo iequidoo added the bug Something is not working label Aug 27, 2023
@iequidoo iequidoo self-assigned this Aug 27, 2023
iequidoo added a commit that referenced this issue Aug 28, 2023
Other MUAs don't set add/remove headers, so the only way for them to re-add us to the group is to
add us to To/CC/wherever. Previously it worked only for other members that are still in the group so
that they properly handled our re-addition, but we didn't.
iequidoo added a commit that referenced this issue Aug 28, 2023
Other MUAs don't set add/remove headers, so the only way for them to re-add us to the group is to
add us to To/CC/wherever. Previously it worked only for other members that are still in the group so
that they properly handled our re-addition, but we didn't.
iequidoo added a commit that referenced this issue Aug 30, 2023
Other MUAs don't set add/remove headers, so the only way for them to re-add us to the group is to
add us to To/CC/wherever. Previously it worked only for other members that are still in the group so
that they properly handled our re-addition, but we didn't.
@iequidoo
Copy link
Collaborator

Fixed by #4638

iequidoo added a commit that referenced this issue Aug 31, 2023
…3782)(#4624)

- If we don't know the parent (=In-Reply-To) message, then completely recreate the group member list
  (i.e. use the member list of the incoming message) (because we assume that we missed some messages
  & have a wrong group state).
- If the message has a "Chat-Group-Member-Removed: member@example.com" header, then remove this
  member.
- If the message has a "Chat-Group-Member-Added: member@example.com" header, then add this member.

That means:
- Remove all checks for the presense of `ContactId::SELF` in the group. Thus all recipients of a
  message take the same decision about group membership changes, no matter if they are in the group
  currently. This fixes a situation when a recipient thinks it's not a member because it missed a
  message about its addition before.
- Recreate the group member list if we don't know the parent (=In-Reply-To) message, even if the
  sender isn't in the group as per our view, because we missed some messages and our view may be
  stale.
iequidoo added a commit that referenced this issue Sep 2, 2023
…3782)(#4624)

- If we don't know the parent (=In-Reply-To) message, then completely recreate the group member list
  (i.e. use the member list of the incoming message) (because we assume that we missed some messages
  & have a wrong group state).
- If the message has a "Chat-Group-Member-Removed: member@example.com" header, then remove this
  member.
- If the message has a "Chat-Group-Member-Added: member@example.com" header, then add this member.

That means:
- Remove checks for the presense of `ContactId::SELF` in the group. Thus all recipients of a message
  take the same decision about group membership changes, no matter if they are in the group
  currently. This fixes a situation when a recipient thinks it's not a member because it missed a
  message about its addition before.
  NOTE: But always recreate membership list if SELF has been added. The current/older versions of DC
  don't always set "In-Reply-To" to the latest message they sent (it depends on timings), so we need
  this heuristic currently.
- Recreate the group member list if we don't know the parent (=In-Reply-To) message, even if the
  sender isn't in the group as per our view, because we missed some messages and our view may be
  stale.
iequidoo added a commit that referenced this issue Sep 2, 2023
…3782)(#4624)

- If we don't know the parent (=In-Reply-To) message, then completely recreate the group member list
  (i.e. use the member list of the incoming message) (because we assume that we missed some messages
  & have a wrong group state).
- If the message has a "Chat-Group-Member-Removed: member@example.com" header, then remove this
  member.
- If the message has a "Chat-Group-Member-Added: member@example.com" header, then add this member.

That means:
- Remove checks for the presense of `ContactId::SELF` in the group. Thus all recipients of a message
  take the same decision about group membership changes, no matter if they are in the group
  currently. This fixes a situation when a recipient thinks it's not a member because it missed a
  message about its addition before.
  NOTE: But always recreate membership list if SELF has been added. The current/older versions of DC
  don't always set "In-Reply-To" to the latest message they sent (it depends on timings), so we need
  this heuristic currently.
- Recreate the group member list if we don't know the parent (=In-Reply-To) message, even if the
  sender isn't in the group as per our view, because we missed some messages and our view may be
  stale.
iequidoo added a commit that referenced this issue Sep 2, 2023
…3782)(#4624)

- If we don't know the parent (=In-Reply-To) message, then completely recreate the group member list
  (i.e. use the member list of the incoming message) (because we assume that we missed some messages
  & have a wrong group state).
- If the message has a "Chat-Group-Member-Removed: member@example.com" header, then remove this
  member.
- If the message has a "Chat-Group-Member-Added: member@example.com" header, then add this member.

That means:
- Remove checks for the presense of `ContactId::SELF` in the group. Thus all recipients of a message
  take the same decision about group membership changes, no matter if they are in the group
  currently. This fixes a situation when a recipient thinks it's not a member because it missed a
  message about its addition before.
  NOTE: But always recreate membership list if SELF has been added. The current/older versions of DC
  don't always set "In-Reply-To" to the latest message they sent (it depends on timings), so we need
  this heuristic currently.
- Recreate the group member list if we don't know the parent (=In-Reply-To) message, even if the
  sender isn't in the group as per our view, because we missed some messages and our view may be
  stale.
iequidoo added a commit that referenced this issue Sep 6, 2023
…3782)(#4624)

- If we don't know the parent (=In-Reply-To) message, then completely recreate the group member list
  (i.e. use the member list of the incoming message) (because we assume that we missed some messages
  & have a wrong group state).
- If the message has a "Chat-Group-Member-Removed: member@example.com" header, then remove this
  member.
- If the message has a "Chat-Group-Member-Added: member@example.com" header, then add this member.

That means:
- Remove checks for the presense of `ContactId::SELF` in the group. Thus all recipients of a message
  take the same decision about group membership changes, no matter if they are in the group
  currently. This fixes a situation when a recipient thinks it's not a member because it missed a
  message about its addition before.
  NOTE: But always recreate membership list if SELF has been added. The older versions of DC don't
  always set "In-Reply-To" to the latest message they sent, but to the latest delivered message (so
  it's a race), so we need this heuristic currently.
- Recreate the group member list if we don't know the parent (=In-Reply-To) message, even if the
  sender isn't in the group as per our view, because we missed some messages and our view may be
  stale.
iequidoo added a commit that referenced this issue Sep 6, 2023
…3782)(#4624)

- If we don't know the parent (=In-Reply-To) message, then completely recreate the group member list
  (i.e. use the member list of the incoming message) (because we assume that we missed some messages
  & have a wrong group state).
- If the message has a "Chat-Group-Member-Removed: member@example.com" header, then remove this
  member.
- If the message has a "Chat-Group-Member-Added: member@example.com" header, then add this member.

That means:
- Remove checks for the presense of `ContactId::SELF` in the group. Thus all recipients of a message
  take the same decision about group membership changes, no matter if they are in the group
  currently. This fixes a situation when a recipient thinks it's not a member because it missed a
  message about its addition before.
  NOTE: But always recreate membership list if SELF has been added. The older versions of DC don't
  always set "In-Reply-To" to the latest message they sent, but to the latest delivered message (so
  it's a race), so we need this heuristic currently.
- Recreate the group member list if we don't know the parent (=In-Reply-To) message, even if the
  sender isn't in the group as per our view, because we missed some messages and our view may be
  stale.
iequidoo added a commit that referenced this issue Sep 6, 2023
…3782)(#4624)

- If we don't know the parent (=In-Reply-To) message, then completely recreate the group member list
  (i.e. use the member list of the incoming message) (because we assume that we missed some messages
  & have a wrong group state).
- If the message has a "Chat-Group-Member-Removed: member@example.com" header, then remove this
  member.
- If the message has a "Chat-Group-Member-Added: member@example.com" header, then add this member.

That means:
- Remove checks for the presense of `ContactId::SELF` in the group. Thus all recipients of a message
  take the same decision about group membership changes, no matter if they are in the group
  currently. This fixes a situation when a recipient thinks it's not a member because it missed a
  message about its addition before.
  NOTE: But always recreate membership list if SELF has been added. The older versions of DC don't
  always set "In-Reply-To" to the latest message they sent, but to the latest delivered message (so
  it's a race), so we need this heuristic currently.
- Recreate the group member list if we don't know the parent (=In-Reply-To) message, even if the
  sender isn't in the group as per our view, because we missed some messages and our view may be
  stale.
iequidoo added a commit that referenced this issue Sep 9, 2023
…3782)(#4624)

- If we don't know the parent (=In-Reply-To) message, then completely recreate the group member list
  (i.e. use the member list of the incoming message) (because we assume that we missed some messages
  & have a wrong group state).
- If the message has a "Chat-Group-Member-Removed: member@example.com" header, then remove this
  member.
- If the message has a "Chat-Group-Member-Added: member@example.com" header, then add this member.

That means:
- Remove checks for the presense of `ContactId::SELF` in the group. Thus all recipients of a message
  take the same decision about group membership changes, no matter if they are in the group
  currently. This fixes a situation when a recipient thinks it's not a member because it missed a
  message about its addition before.
  NOTE: But always recreate membership list if SELF has been added. The older versions of DC don't
  always set "In-Reply-To" to the latest message they sent, but to the latest delivered message (so
  it's a race), so we need this heuristic currently.
- Recreate the group member list if we don't know the parent (=In-Reply-To) message, even if the
  sender isn't in the group as per our view, because we missed some messages and our view may be
  stale.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is not working
Projects
None yet
Development

No branches or pull requests

4 participants