Of course!

😻

nip4 or nip17 ?

Even I don't know the difference

bro 🫠

going to start a dev debate if i answer this honestly but it's a known client compatability issue. just please use nip17

I’m not the tech guy… ask Proud…

@Proudmuslim 👀

re: NIP-17 is there a support table anywhere? I'm not sure which client to use

NIP17 - NIP-17 - Private Direct Messages

Read more about the NIP17 on {{appUrl}} - NIP-17 - Private Direct Messages

NoorNote, Yakihonne, 0xChat, Amethyst, Nostur, Coracle... to name a few. Too many clients for anyone to have a full/accurate list.

NIP-04: encrypts the message content but leaks metadata: anyone can see who is messaging whom, when, and how often, since sender/receiver pubkeys and timestamps are visible on relays. NIP-17: fixes this by wrapping the encrypted message inside a gift-wrap (NIP-59): the outer event uses a random throwaway key, a randomized timestamp, and is sealed so relays and observers cannot see the real sender, receiver, or timing. The actual message is only visible to the intended recipient after unwrapping two layers of encryption. In short: NIP-04 = encrypted content, public metadata. NIP-17 = encrypted content + protected metadata.

NIP-04: encrypts the message content but leaks metadata: anyone can see who is messaging whom, when, and how often, since sender/receiver pubkeys and timestamps are visible on relays. NIP-17: fixes this by wrapping the encrypted message inside a gift-wrap (NIP-59): the outer event uses a random throwaway key, a randomized timestamp, and is sealed so relays and observers cannot see the real sender, receiver, or timing. The actual message is only visible to the intended recipient after unwrapping two layers of encryption. In short: NIP-04 = encrypted content, public metadata. NIP-17 = encrypted content + protected metadata.

NIP-17 only hides the sender ID , not the recipient ID. External observers can still see that a certain person is receiving messages. A better approach is to decouple the sending address and the receiving address from the ID, and continuously rotate both of them. Addresses and IDs serve different purposes and should not be conflated. An ID should not be used as an address.

Why doesn't it y'use empherical keys as an if specifically on encrypted comm in dm?

The solution you mentioned is not suitable for a chat app, that is, for long-term conversations between friends. If you think about automating and programmatically managing the ephemeral key update mechanism, you’ll end up with the Signal protocol.

A hybrid is possible I think I'm creating something like that. But your approach is very very good nonetheless.

you were right

Already use Amethyst on mobile, will look into whether primal supports it on desktop