I see. I've asked myself the same question previously, but I don't think so. The nip has been updated and refined several times in the last six months, but that part has always remained unchanged.
My understanding is that we're moving away from nip04 encryption only for DMs, everything else should be fine...
Why is NIP-04 still okay for the signer events when NIP-44 is preferred for DMs?
It would seem preferable to me to move all encrypted messages to a single standard, for the sake of code commonality.
My guess is that it's because signer events are "only" ephemeral events.
Nip44 was the first step at getting us away from nip04, with better crypto algos, and nip17 finally solved the metadata leakage issue that plagued nip04, and made it unsuitable for DMs (privacy concerns)
I agree on the single standard but I haven't taken the time to read the discussions in the different PRs, so there might be a valid reason that I'm not aware of...
There’s a clash of constantly updating specs with dozens of apps using the older versions.
Maybe it was nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn who said it: (paraphrased) do not count on spec deprecation on nostr. Therefore account for this in your app’s code.
Yeah, I think in practice nip 04 is usually still used, but I believe highlighter accepts nip 44. The best approach seems to be to accept both, but choosing which to publish is trickier.
> // TODO how should replies to 'nip04' encrypted messages be handled?
I'll probably have to support both in my project for compatibility, but that's not ideal.
Well get support for both! And any future versions. As long as things don't get too out of hand, noscrypt's encryption API was built to handle this.
nostr:npub1qdjn8j4gwgmkj3k5un775nq6q3q7mguv5tvajstmkdsqdja2havq03fqm7 thinks big, builds solid tools, but forgets to share links. Here’s one.
I love how we’re all on the same page…
Just pushed this PR today, to implement NIP44 for NDK signers … using Coracle as a model … which has a nifty little “check” during decryption to see if Nip04 is needed.
Ooh I'm working on remote signing right now, I'll take a look at that proposal.
that check is annoying af
i haven't updated it but the initial implementation of NIP-44 for Go did not correctly decode or encode the HMAC
so imagine me, trying to test a chatbot that was planned to be an administrative CLI fro my relay
stop it... don't push nip-44 on everyone like this, nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn this made me hate you a bit also
You can turn the toggle off and it won't bother you for that conversation
it turns itself back on all the time, it's annoying af, i would want to be able to disable it at all
but i am not using coracle these days, and i wrote an in-chat verification process that is like nip-42 except the user has to copy and paste a string, and then after all the fun of the nip-42 fiasco i quit trying to make an ACL for that time
I'll make sure the setting is remembered
there is nothing less secure about NIP-04 than NIP-44
they both use AES cipher modes, both use GCM, unless i am forgetting, and the only material difference as a cryptosystem between them is a diffferent HMAC and the use of a second layer that hides the origin from the relay
if you ask me, it's not actually doing anything useful, complicates things, and doesn't help anyone, and has just impeded the progress of DMs, application specific data and ephemeral message encryption by making two where there was one
really, cryptographically they are equivalent, the NIP-44 was only made to try and reduce metadata leakage, and that's irrelevant for ephemeral events
irrelevant
"hiding the origin from the relay" is useless, i don't even know why anyone thought that was helpful
hint: they know your IP address, or they can, and they can log that alongside your destination npub so it achieves nothing
IP address mixer? please
then you have a spam problem
t-y mleku/still shallow end
the reason is to hide IP you have to use layers of encryption and the relays that pass it on are then open to abuse from anyone to DoS them
not many people have been deep in the subject and i've been following Tor since 2006, just search "David Vennik" and you'll see, i was on the mailing list right at the beginning, this is part of my path to #bitcoin
nip04 uses AES CBC. nip44 uses xchacha20, which is a technically a counter mode cypher not CBC I believe. Nonces are used for encryption and MAC.
The other big thing is versioning and a binary concatenation spec which I think adds some really good future proofing.
https://github.com/nostr-protocol/nips/blob/master/44.md#encryption
