Thread - Nostr Hypermedia

@fiatjaf @Vitor Pamplona NIP-17 obviously doesn't work with whitelisted relays because you have to create a random pubkey to send the message. Could you instead, at some point (maybe when you first follow someone as it's a public event anyways), send a single encrypted message to the recipient intended for the transfer of a symmetric key? That way you could: 1. Encrypt a message using the symmetric key 2. Send it to the relay the pubkey is whitelisted on 3. The recipient's client, probably only checking for that event kind and narrowed to pubkeys they follow) would then attempt to decrypt it using the symmetric keys it's holding 4. The recipient's client would then store the message appropriately

Replies (3)

fiatjaf _@fiatjaf.com 11 months ago

I sincerely believe we should nuke all DM and encrypted stuff from Nostr. But if you want a more charitable answer then yes, it doesn't work with whitelisted relays. It could work though if you match the receiver pubkey, which is available in the giftwrap, and accept any messages to that recipient. You could also require PoW from the sender to decrease spam. But ultimately the best solution is to have two pubkeys used only for encryption, one for the external giftwrap, another for the internal encrypted message, then you share the external key with the relays you're listening for DMs and then they can decrypt the giftwrap and see who is messaging you, then accept the message if it's a friend or WoT, or reject it if it's spam, or even send a message back (not from your key, just a random message) saying that in order to send you a message they must pay 10 satoshis (or something like that). This is not a super hard fix, but very annoying because you have to announce these two extra public keys and share the corresponding private keys around, syncing them across devices -- but we'll ultimately have to do that anyway in order to be able to use bunkers, frost bunkers, musig2 bunkers, SGX bunkers, and also because it is a good idea to decouple encryption from identity. See also

GitHub

nip4e: decoupling encryption from identity by fiatjaf · Pull Request #1647 · nostr-protocol/nips

this is inspired by MLS, but much simpler, and definitely not trying to be a group communication system, but only a way for users to encrypt things...

1 replies ↓

fiatjaf _@fiatjaf.com 11 months ago

Now here's the stupid solution that works better than everything else and can be done today as most clients are ready to oblige: just require the sender to AUTH against the relay before publishing its very secretive message.

Nyxter nyxter@fountain.fm 11 months ago

Encryption in Nostr plays a vital role and requires further development. I believe it's possible to enhance functionality by implementing multi-level encryption, where different sets of keys are used for different tasks. As new use cases emerge, the need for multiple key sets will become more apparent. This is why the idea of ID keys makes sense. Right now, I’m exploring the concept of an encrypted chat that allows one of the participants to make the conversation public. This would involve using a symmetric key, ensuring privacy while enabling controlled disclosure when necessary.