Group deletion flow is incomplete

[saulmc]

From Caroline:

• when group is blocked, in the group the message I see “Do you want to join this group” the options “Decline” or “Join this group” appears in the group chat.
• When I kill the app and reopen the blocked chat is in requests folder, before “joining the group” I am able to see all of the messages including the ones sent during the group being blocked.

We need to unblock this by answering #220 Undelete a group

My MVP proposal here is:

• Put deleted group conversations in a sub-view like Requests/Spam that is only accessible through settings.
• Pop an alert when a user tries to tap into a conversation from this list. Options: "View" "View and Undelete"
• Swipe to undelete instead of swipe to delete

[lourou]

Was the group declined, blocked, or deleted?

The option to delete a chat is a Converse-specific feature that saves the deletion in the Converse backend. The deletion of a chat is not broadcasted to the protocol, only allowed/blocked peers are.

Should we remove the "delete" option from the Converse backend? This might have a side effect where deleted conversations might appear again for some users. Mitigation: write a migration that blocks the peers from deleted chats on the protocol level.

[saulmc]

This specifically refers to deleting groups. When deleting from the homepage, the user is given the option of whether to block the inviter of the deleted chat:

Note that there are two still-undesigned areas of the product that in the future should also trigger deletion:

• On the group profile page
• When declining a group request

In all of these situations, it is acceptable for the group to only be deleted from Converse, and still show up in other apps.

[lourou]

For 1:1 chats, the consent is on the peer level, vs. delete is on the conversation level and only on Converse's backend.
For groups, the consent is on the conversation level, and not on the peer like in 1:1s.

1. Do we still need the "deleted" option for groups as consent for groups (allowed/blocked) is set at a protocol level?
   Suggestion: For group chats, a current delete operation could trigger a block/deny and therefore be spread to the protocol

2. Blocked and denied chats would be made accessible through settings, like the mock screenshot below in Profile > Action > Blocked Chats

[lourou]

Following the daily, we opted to:

• Keep the delete option for 1:1 chats
• Use the block/unblock on the protocol level for group chats
• For group chats, change the "Delete" wording and offer the user to "Block" and "Unblock" the chat instead
• Declining a group chat invite equals a block

[saulmc]

@lourou @nmalzieu @nplasterer During yesterday's discussion I was caught up by the technical details and whiffed the real product question here about the user expectation when "trashing" a group conversation.

Given these things:

1. "Block" and "delete" are the same action: *completely remove this group chat from my inbox and do not show me further messages"
2. "Block" is not an available action for groups in Messenger, WhatsApp, Telegram, or Signal. Options ranging from least to most destructive are "Archive" (only relocate this group chat to my inbox's archive section), "Delete": (completely remove this group chat from my inbox and do not show me further messages -- in some apps leave it too), "Leave", or "Leave and report".
3. (Assumption) Most users will primarily associate "block" with 1:1 conversations and will not understand how it applies to a group
4. Presently there is no support for leaving groups in XMTP
5. XMTP can't guarantee permanent removal of a group as long as group block state portability is limited by message history

...I don't think we should be using either "block" or "delete" to describe our destructive action.

Instead, until "Delete" and "Leave" can actually be supported, I think "Remove"/"Undo Remove" would be best. It aligns with the user's intent to "get this out of my inbox", leaves room for less permanence than "delete", and doesn't have a preexisting association like "block".

[nplasterer]

I like the reasoning here. Sounds good to me.

[lourou]

I agree! I will update the wording accordingly and make some adjustments for the removed chats view on iPad and web, as it uses a split screen instead of a single screen on iOS and Android.

[saulmc]

@lourou Darick's suggestion was to add this action sheet before entering a restored conversation. This pairs with #559

[lourou]

@saulmc Implementation done with "Remove/Restore" wording for consistency. See attached image.

Note: "View and Restore" presents navigation challenges:

1. Returning to outdated Removed Chats list after restoration could be confusing
2. Modifying nav stack to return to main chat list might disorient users
3. Using a modal/overlay keeps context but requires more work

Need to balance user understanding, consistent navigation, and smooth UX. Thoughts on best approach?

[saulmc]

I think navigating back to main or requests (depending on consent) is actually expected here. Once I've restored the conversation, back should take me to wherever the conversation was restored "to".