Please correct me if I’m misunderstanding. Key distribution was necessary because in other implementations (except NIP-04), users don’t post the message using their actual npub. Clients had to generate an alternate key pair to encrypt the message, so it looked like the message was posted by some random npub. Therefore it wasn’t compatible with private relays because the relay didn’t have that npub on file.
I’m hoping that this NIP solves that problem so that encrypted DMs can be sent to private relays which use an allow-list of npubs that have permission to post.
If that’s not the case for this NIP, my next question is: how do private relays support it?
> Clients had to generate an alternate key pair to encrypt the message, so it looked like the message was posted by some random npub.
This is the correct way to implement private messages. The relay should not use the pubkey in the signed message to test against an allow list. Private relays CAN use an NIP-42 AUTH method to authenticate the connecting user (and not the signing user) and make the allow list about the connecting user. The signed message itself must hide the real user as much as possible because it can be easily broadcasted outside of this relay.
Needless to say that private relays that authenticate the user can track everything about the user and thus, by definition, are not very strong in privacy.
I’m not sure this is a great solution. The paid authenticated user could effectively spam your relay with infinite pubkeys and you would need to monitor usage and block users. That’s a good bit more administration than is currently required for single pubkey users.
The way I see it there are two paths for “hiding” DM metadata.
1) AUTH and trusting the relay. Send your DMs to a small list of trusted relays that properly implement AUTH for private events and do not leak those events to anyone outside of authorized recipients.
2) Giftwrap everything on public relays and make sure you DON’T AUTH to any relays you don’t explicitly trust. Relays you’re connected to can still track you by IP but less public metadata is leaked.
I’m not sure combining the two makes a ton of sense. AUTH + giftwraps doesn’t accomplish any relay facing privacy, right? If it only helps externally, is it not the same trade offs as option 1?
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?
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.
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?
> 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.
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.
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.
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 🚀
As you know, this is basically why we made inbox.nostr.wine. I really don’t think it works out of the box with a typical paid relay.
It combines I think the best two properties of 1&2 in a way that works.
Anyone can write to inbox WITHOUT AUTH as long as the note tags an inbox subscriber.
Then any inbox subscriber can query for their giftwraps only after AUTH so we never leak that event outside its intended recipients.
Lastly, we address spam by letting kind 1984 reports from any subscribed user automatically delete any note they are tagged in.
Agree. What I wrote is explicitly about testing the pubkey of the event against the allow list. The pubkey is the signer and that should not happen. The p-tag can be used like you guys do to run the allow list. That's fine. You don't even need auth in those cases.
My answer to nostr:nprofile1qqs0kymx4027fjf2322s0yduwt23hh3fr2p42h9jcc56jtld67qx3tqpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uq3jamnwvaz7tmvd9nksarwd9hxwun9d3shjtnrdakj7qgmwaehxw309aex2mrp0yhxummnw3exjcmgv4ejummjvuhsa6kd6c was explicitly about the use of the pubkey and mixing signing and auth roles in one key.
Oddbean new post about login | logout