design(dm): UX for NIP-04/NIP-17 dual-protocol messaging and reachability

[NotThatKindOfDrLiz]

Summary

Divine currently sends DMs using a dual-protocol strategy: NIP-17 (gift-wrapped, metadata-private) as the primary protocol, with a NIP-04 (kind 4) fallback copy for interoperability with clients like Damus and Primal that don't support NIP-17.

This works technically, but there are UX and design gaps around how we communicate this to users and how we ensure reachability for users we need to contact.

Problem

• Most popular Nostr clients (Damus, Primal, etc.) still use NIP-04 as their primary DM protocol
• Some Divine users self-custody their keys and have no email address on file — DMs are the only reliable way to reach them (moderation notices, account communications, etc.)
• If a user doesn't have push notifications enabled for Divine, they may not know Divine has messaged them — but they would see it if the NIP-04 copy surfaces in their primary client
• There's currently no indication in the Divine UI about whether a message was sent/received via NIP-04 or NIP-17, or what the privacy implications are
• Users have no way to understand the metadata trade-offs between the two protocols

Design questions to resolve

• How should the UI indicate whether a conversation or message is using NIP-04 vs NIP-17?
• Should users see any kind of privacy indicator (e.g., NIP-17-only conversations are "private", dual-send conversations have visible metadata on relays)?
• When Divine sends system/moderation messages to users, should it always include the NIP-04 copy to maximize the chance the user sees it?
• Should there be a user-facing setting to control protocol preference?
• How do we handle the case where a conversation starts as dual-send but we later detect the recipient supports NIP-17?

Context

• Divine's dual-send implementation lives in dm_repository.dart — NIP-17 primary with NIP-04 fallback, plus cross-protocol deduplication
• NIP-04 exposes sender, recipient, and exact timestamp to relays; NIP-17 hides all metadata via ephemeral keys and randomized timestamps
• File messages (kind 15) are NIP-17 only — NIP-04 doesn't support file metadata
• Related PR: feat(dm): delete message for everyone via NIP-09 kind 5 events #2394 (NIP-09 delete for everyone)
• Related PR: feat(dm): add clickable URLs, long-press actions, and message reporting #2389 (clickable URLs, long-press actions, message reporting)

[NotThatKindOfDrLiz]

@Chardot This is medium priority for after we reach our current milestone, FYI.

[NotThatKindOfDrLiz]

cc'ing @untreu2 who can provide additional technical insight related to Nostr DMs

[untreu2]

Perhaps we could have a support chat, as in other apps, and use NIP-04 for that – while using NIP-17 for all other pubkeys.

The issue with NIP-04 is not so much the security of the messages as it is metadata leakage. This is because if we send NIP-04 messages alongside NIP-17, it becomes possible to see who is communicating with whom. In other words, if we have both NIP-04 and NIP-17 at the same time and send messages using both, it is as if we did not have NIP-17 at all.

If we only enable NIP-04 for the diVine support public key, this metadata leak will only affect the support chat. For other chats with NIP-17, maybe we can create a visual distinction by adding a 🔒 icon.