Oddbean new post about | logout
▲ ▼
triskal | 11 months ago (raw) | root | parent | reply | flag 
 For #1, how do relays “not leak those events to anyone outside of authorized recipients” if the recipient npub is itself encrypted or otherwise obfuscated?
▲ ▼
Mazin | 11 months ago (raw) | root | parent | reply | flag 
 In the case of #1, the recipient npub is not obfuscated. Hence the relay is responsible for not leaking that event outside of the intended recipient.
▲ ▼
triskal | 11 months ago (raw) | root | parent | reply | flag +1 
 Gotcha. But that can already be done with NIP-04. How does NIP-44 improve on that? Just better encryption that does not increase the chance of nsec leakage?
▲ ▼
Vitor Pamplona | 11 months ago (raw) | root | parent | reply | flag 
 > Just better encryption that does not increase the chance of nsec leakage?

Correct. NIP-44 is not a new DM NIP (that will be another number). NIP-44 just defines a better encryption scheme that any other NIP (including a DM NIP) can use. The offered protections by NIP-44 are against the needs of that individual encryption and not against the needs of a new DM system :) 

In other words, you can definitely use NIP-44 in a way that is not private at all. The encrypted parts will be private, but all the other markers in the event can give everything away. It's like citing somebody in a NIP-04 message and adding a p-tag to that person outside the encrypted component.
▲ ▼
triskal | 11 months ago (raw) | root | parent | reply | flag +2 
 Thank you SO much for this explanation! 

I want to start up a private relay and I’ve been really concerned about the “best” way to implement E2EE DMs.

Looking forward to reading the next DM NIP that implements this.
▲ ▼
Vitor Pamplona | 11 months ago (raw) | root | parent | reply | flag 
 This is the new DM I am working on: https://github.com/nostr-protocol/nips/pull/686 and it is available on Amethyst right now. It tries to be as private as possible without having to have an AUTHed relay. I would argue that in extreme privacy implementations it could be more private than SimpleX. A client can have a DVM to connect to receiving relays for users and not leak your device's IP that would allow for some correlation even if everything is encrypted. 

nostr:nprofile1qqsrmpp2lmx4u2fl9zmxy7fnwp9rlwxwz5a2j8tep2c376n494z2gtgpzamhxue69uhkjmnzdauzumn0wd68ytnhd9hx2tcprpmhxue69uhkxetvd3shytnwdaehgu3wwa5kuef0qyghwumn8ghj7mn0wd68ytnhd9hx2tcwamxyd  has a very good start with inbox.nostr.wine. The way to see the relay is as a mail box for the user. The user is paying for the relay to receive and store any event that `p`-tags the user. They might be spam or real messages. It's not the relay's job to decide which is which. It's the user's job (via a good client that helps you manage your inbox) to delete things that are spam and clean up their account with the relay from time to time.
▲ ▼
Mazin | 11 months ago (raw) | root | parent | reply | flag +1 
 I’ll try to cut out some time to work on the inbox website and some proper explanations for how it works. The pricing isn’t well thought out either, could just be free for now since it’s mostly for testing.

So much to do can’t keep up 🚀