NIP44, the new audited encryption procedure by nostr:npub10jcnehsxwrjepupvh602pl83up0dh3wv3fqfwv062smygqvpeuwsk03kag to fully replace NIP-04 has been merged!

The NIP04 is now officially dead.

GM.

https://github.com/nostr-protocol/nips/blob/master/44.md


LET'S GO.


Contact your favorite client devs and ask them to implement the new sexy DM spec.
nostr:nevent1qqsqverhm9eka9uc3a0qpkzg7psayypypyvwx0hrqsh8qp4x05tpnmspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygzxpsj7dqha57pjk5k37gkn6g4nzakewtmqmnwryyhd3jfwlpgxtspsgqqqqqqsaga06z


nostr:note1qej80ktnd6te3r67qrvy3urp6ggzgzgcuvlwxppwwqr2vlgkr8hqxreskq

Wooooohooooooo!

Also sad cause now I have to work to implement it 😂


GM 🫂☕ Vitor, gracias por la información ✨


if Ur reading this please don't use nostr for Ur secret dm's, just use signal or simplex instead. nostr is meant to be a public protocol and if u read the nip you will see a bunch of shortcomings/compromises just to force DMS on nostr, which it isn't meant for


:catJAM:


«2) the relays are supposed to regularly delete older messages.»

Where is this defined? I haven’t deleted anything myself over the course of almost 2 years. Maybe relay implementations do this automatically? If so, i’m either blind or it’s very badly communicated


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?


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


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 nostr:nprofile1qqs0kymx4027fjf2322s0yduwt23hh3fr2p42h9jcc56jtld67qx3tqpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uq3jamnwvaz7tmvd9nksarwd9hxwun9d3shjtnrdakj7qgmwaehxw309aex2mrp0yhxummnw3exjcmgv4ejummjvuhsa6kd6c   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.


NIP44, the new audited encryption procedure by nostr:npub10jcnehsxwrjepupvh602pl83up0dh3wv3fqfwv062smygqvpeuwsk03kag to fully replace NIP-04 has been merged!

The NIP04 is now officially dead.

GM.

https://github.com/nostr-protocol/nips/blob/master/44.md


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 🚀


nostr:npub1n0sturny6w9zn2wwexju3m6asu7zh7jnv2jt2kx6tlmfhs7thq0qnflahe 👆😁


Buy travel eSIM https://www.lnesim.com no email/kyc