[cross-platform] Show "Conversation deleted" to User A when User B deleted it on their side

[lamat1111]

Issue

When a user deletes a conversation, the other party has no indication that messages will no longer be received. This creates a broken communication loop where users send messages into the void without any feedback.

Current Behavior

• User A deletes conversation with User B via ConversationSettingsModal
• deleteConversation only removes local data (src/db/messages.ts:1108-1119)
• User B continues sending messages thinking they're being delivered
• User A never receives these messages (conversation is gone)
• No delivery status or error indication for User B

Root Cause

The messaging protocol lacks conversation lifecycle management:

• No conversation state synchronization between parties
• No message delivery status tracking
• Message types only include post, reaction, event etc. (see src/api/quorumApi.ts:75-174)
• Missing conversation management types like conversation-deleted

Potential Solutions

1. Pre-deletion Notification (Medium complexity)

Send deletion notice before deleting conversation locally:

• User confirms deletion → Send "I am deleting this conversation on my side" message
• After message sent → Execute local deleteConversation()
• Other party sees deletion notice in their conversation thread

Implementation:

• Add ConversationDeletedMessage type to src/api/quorumApi.ts
• Update deletion flow in ConversationSettingsModal.tsx:85-118 to call submitMessage() first
• Handle display of deletion notices in message UI (similar to system messages)

Advantages: Leverages existing message infrastructure, simple failure mode, clear communication

2. Simple Warning (High complexity)

Show warning when sending to potentially inactive conversations - Actually complex because requires conversation state detection mechanisms that don't exist.

3. Delivery Status Tracking (High complexity)

• Track message delivery failures
• Show delivery status indicators
• Warn users when messages consistently fail

4. Full Conversation State Sync (High complexity)

• Extend protocol with bidirectional conversation state queries
• Real-time conversation existence validation
• Handle complex edge cases and race conditions

Key Files

• src/components/modals/ConversationSettingsModal.tsx:85-118 - Deletion logic
• src/db/messages.ts:1108-1119 - Local deleteConversation method
• src/components/context/MessageDB.tsx:2509+ - submitMessage flow
• src/api/quorumApi.ts:75-174 - Message type definitions

Investigation Needed

• Analyze message delivery reliability mechanisms
• Research protocol extension feasibility
• Define conversation state synchronization requirements
• Assess impact on existing message flows

[winged-pegasus]

This could probably be solved by just sending a "delete" type message rather than post to a conversation. This would put the conversation into an "archived" state and a message similar to the one that is already in place for a conversation that has not been accepted.

This would mean we could create a "Archived" section for stale, manually archived, or deleted conversations.

[lamat1111]

I also noticed that if user A sends a DM again to user B after deleting the conversation o their side, it reopens the deleted conversation for them, instead of starting a new one from scratch.

[winged-pegasus]

1. all messages should be deleted for that conversation
2. all current encryption states are deleted for the conversation
3. the conversation is deleted after the above are deleted
4. user profile info has been stored in the conversation data
5. I'm unsure exactly what you're seeing, so it's hard to know what you're referencing.
6. possibly there may be some additional data that needs to be deleted, but not sure what that would be
7. users's do a "handshake" when they initiate a conversation, e.g. user A sends a message to user B, but until user B sends back a response, they don't get any profile/user information. This state should be reset after a conversation deletion.
8. If User A deletes the conversation on their side, User B may see an additional "deleted conversation" memo at the end of the conversation , but User B will still have the message history until they delete it, too.
9. If User A or B resend a message, that handshake should have to be re-initiated, however for User B the conversation will start after the "User A has deleted the Conversation" message. User A will not see anything other than the message they just sent to B (or what B just sent to them).
10. The entire conversation history with User B should have been deleted and there should be nothing to see (no profile information, no previous messages from before deletion, etc.). If User B sends a message to User A (who has deleted their Conversation), it should appear to User A as a brand new conversation, including having the warning/info message on the bottom about no user information being sent until they reply.
11. If you are meaning that User A, after deleting, sends a message to B and there is profile information, either A. it's stored somewhere (can check that), or B. it's getting pulled because the keys to the profile information weren't deleted.

[lamat1111]

I only noticed this once, locally.
I deleted the conversation on user A side. Then I sent a new message from user A to user B. When user B replied, the entire old conversation on user A side reappeared, with the new message from user B at the bottom.
Maybe test on your side.

[winged-pegasus]

This worked for me.

However, I did notice that User B -> User A doesn't work. User B likely needs to reset keys and restart the initialization sequence (it likely was trying to use old encryption keys that User A no longer has and so the messages fail to be retrieved.

Otherwise, it seems to work as expected, User A deletes. User A resends a message (no profile info for User B, yet), User B receives and replies, User A receives and has User B's profile info. User A only has messages sent after deletion.

[winged-pegasus]

This has been deployed in #82