We have identified the main issues with Nostr direct messages (DM), listed roughly from most to least significant:
1. Different clients implement different DM NIPs (NIP-4 vs NIP-17), causing a lack of interoperability.
2. Users connect to different relays with little or no overlap, so recipients may never receive messages.
3. Message notifications are unreliable.
4. Spam — the system is vulnerable to unwanted messages.
5. Metadata privacy concerns: with NIP-4, others can see who is messaging whom; with NIP-17, others can see who is receiving DMs.
6. No forward or backward secrecy: if a private key is compromised, both past and future messages can be decrypted.
Note: “Nostr DM” here refers to the direct‑messaging feature of Nostr Microblog, not a standalone chat application.
They embody different design trade‑offs. This is why we ranked metadata privacy concerns and the lack of forward/backward secrecy lower in the issue list.
When you need to contact a Nostr microblog user, consider whether using Nostr DM is sufficient or whether you should use a dedicated chat app.
Login to reply
Replies (18)
In case of NIP17 DMs clients are required to send events to the recipients desired relays.
Why is overlap necessary?
Instead of NIP-17 messages delivered to NIP-4 clients being completely invisible, could there be a way for the NIP-17 client to send a NIP-4 message that informs recipient that *something* was sent but their client can’t display it?
Makes sense. But if we follow this rule strictly, then in a case where the sender’s client only supports NIP-17, and the recipient hasn’t published any 10050-listed relays on a relay, the sender’s NIP-17 message can’t be published at all, right?


Set all kind 1059 to be sent over the Nosflare blaster relay 🤓
The relationship between NIP-4 and NIP-17 is similar to:
iPhone ↔ iPhone: It uses iMessage first (Apple’s service). Blue bubbles.
iPhone ↔ Android: It uses SMS/MMS (the carrier’s traditional texting standard). This isn’t an “Android-only protocol,” it’s the old common language that all phones can speak. Green bubbles.
If at least one person in the chat is using a client that supports both NIP-4 and NIP-17, interoperability is no longer an issue.
Keychat is a standalone chat app. If a user adds their Keychat link to their Nostr microblog profile, it can partially serve the role of Nostr DMs.
For issues 1 and 2, since both sides of the conversation are using Keychat, those are basically solved.
For issues 3, 5, and 6, Keychat solves them completely.
For issue 4, if the user only uses relays that charge stamps, that’s also solved.


Yes I fallback to nip-04 in that case.
In practical terms, could it be possible for a Keychat user to send a message to a Damus or Primal user, but it’s just a link to download the app, similar to the one-time link but without the metadata?
Right now, if you log in to Keychat with your microblog ID and someone sends you a NIP-17 DM, Keychat can directly reply using NIP-17. We haven’t really talked about this feature much, so you might not be aware of it.
It can also receive NIP-04 DMs, but Keychat doesn’t yet support replying using NIP-04. We’re still debating whether we should support NIP-04 replies.
You could implement clear warning messages when using NIP-04.
Use red chat bubbles to distinguish NIP-04 messages.🤓
Thanks, this is all helpful.
Good idea. And yellow ones for NIP-17, green ones for either NIP-EE or your own standard.
You also need to route everything via onion and or i2p. Which Nostr unfortunately lacks.
Any goals towards Gift Wraps?
NIP-17 DMs already include Gift Wraps. 👇
"This NIP defines an encrypted chat scheme which uses NIP-44 encryption and NIP-59 seals and gift wraps."
GitHub
nips/17.md at master · nostr-protocol/nips
Nostr Implementation Possibilities. Contribute to nostr-protocol/nips development by creating an account on GitHub.
Gotcha, it gets confusing because of the number ordering. Thanks for pointing that out.