The NIP says: “Every nostr user has their own public key, which solves key distribution problems present in other solutions.” Does this mean that it will work with private relays that have an allow-list of npubs that are permitted to post?

Or just use the new DM system in Nostr, which uses this new encryption. :) What the NIP says is that the encryption on itself is not alone a good chat spec. But people can build really good ones on top of it.

I am not sure what one has to do with the other. What the sentence is trying to say is that the the encryption scheme doesn't not need to solve the key distribution problem.

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?

What about NIP-51 private lists then? I don’t think the change formally addressed private lists even though it says to use the same encryption scheme as NIP-04.

GM

We should migrate them to NIP-44... in time. The overuse of NIP-04 does make the private key less safe. The more it stays out there, the worse it gets for users.

Makes sense. There’s a couple NIPs that reference NIP-04 that need to be updated. Anyway, nice work to everyone who worked on it! This is huge.

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?

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.

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?

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 @Shawn was explicitly about the use of the pubkey and mixing signing and auth roles in one key.

> 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:

GitHub

NIP-17 (old 24) Sealed Gift-Wrapped Messages for Private DMs and Small Group Chats by vitorpamplona · Pull Request #686 · nostr-protocol/nips

This PR creates a new private messaging scheme from the learnings of many past proposals, including NIP-44, NIP-59, NIP-24, NIP-103, NIP-76. It bri...

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. @Mazin 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 🚀

@Fabian 👆😁