can you explain how a relay ensures that only *sender and receiver* can request these obfuscated messages because i don't understand how that can work (one-shot temporary sender keys with the identity receiver key makes it complicated how to decide from the relay side whether a message (1059/1060) is privileged to the user, you see what i mean?
𓅦 NOSTR tech update
This week we successfully implemented our Nostr-based messaging system based on NIP-17, instead of the still commonly used NIP-4.
NIP-4, the traditional direct messaging system in Nostr, has a significant privacy weakness: while it encrypts the message content, it exposes important metadata about who is talking to whom and when these conversations occur, "DM Reporter" (nostr:npub164r4kfyyre2w2yy85zdsvlyk8xl2rj99xqjk4r65zfvfeqycu8zq87448c) which seems to have been deleted from all relays made people aware of this.
At first our idea was to generate a unique keypair for communication with every client so it was harder to trace to see who is using our platform, luckily we found out that there was already a NIP with a better solution, namely NIP-17 which describes "gift wrapped" direct messaging.
The gift wrapped approach combines three NIPs to create a more private messaging system:
𓅦 NIP-44 provides strong encryption for the actual message content using modern cryptographic methods like ChaCha20 and HMAC-SHA256.
𓅦 NIP-59 introduces a clever three-layer wrapping system:
• The actual message becomes a "rumor" that isn't signed
• The rumor gets encrypted and sealed (kind 13)
• The seal gets encrypted, gift wrapped (kind 1059) and then posted by a randomized nostr key.
𓅦 NIP-17 ties it all together by defining how these wrapped messages should be handled, including:
• Using kind 14 for the actual chat message
• Randomizing timestamps to prevent time-based analysis
• Allowing users to specify which relays should receive their DMs
This approach provides several advantages:
• Hides who is talking to whom
• Makes it impossible to see when messages are exchanged
• Allows for message deniability
Relays are also advised to only serve wrapped messages (kind 1059) to their intended recipients, providing an additional layer of privacy protection.
Check out the code, fully open source:
https://github.com/DaedalusLabs
#grownostr #nip4 #nip14 #nip17 #nip44 #nip59
Discussion
The "p" tag helps with identifying events meant for a specific user. Also the NIPs specify a way for a sender which relay to deliver the encrypted message.
That specific chosen relay could enforce authentication before kind 1059 events get delivered that are meant for a specific pubkey. I hope this clear it up a bit 😉