nip46: abandon nip04 entirely and just use nip44

[fiatjaf]

trafficstars

this is a placeholder PR that should only be merged once the full transition has happened.

nip44 support	decrypt	encrypt
gossip	✔️	✔️
amethyst	✔️	✔️
highlighter	✔️
snort	✔️	✔️
coracle	✔️
ndk	✔️	✔️
nostrify	✔️	✔️
nostr-tools	✔️
go-nostr	✔️
rust-nostr	✔️	✔️
nak	✔️
nostr-login	✔️
window.nostr.js	✔️
ditto	✔️
amber	✔️	✔️
nsec.app

can you edit this comment and include your library/app/etc?

[alexgleason]

Used my rare privilege to edit other people's posts to add amber to the list

[vitorpamplona]

I like this support table. It should be a staple in every PR.

[vitorpamplona]

FYI, the new text uses an example for signing kind 14, which should never be signed. :)

Maybe change it to kind 1059 or 13?

[arcbtc]

Why abandon? For bunch of use cases nip04 is great. Just have both and recommend for dms using 44

[mikedilger]

I think we should keep NIP-04 to document how that works because we cannot make all the nostr clients stop doing it, and there are many nostr clients now. Marking it as deprecated is good enough.

[mikedilger]

BTW gossip ticks both columns now.

[believethehype]

Rust Nostr also ticks both columns

[greenart7c3]

Amber ticks both columns

[melvincarvalho]

NIP-04 is used in lots of places other than listed. No finite list can capture Nostr ecosystem at this point. NIP-04 is indeed great, as @arcbtc points out, not least because it's much simpler. It plays well with the simplicity maxis.

[alltheseas]

Through nostrability we previously learned that it is not realistic to expect a NIP to be deprecated. Not because the upgraded NIP is not superior, but rather because of the independent and non-synchronized nature of nostr dev work.

The consequence of the above observation is that if @fiatjaf and NIP dev team advise NIP-XX is deprecated, many will switch, AND some will not.

If the devs that switch/upgrade to the superior NIP do not account for backwards compatibility to the older NIP, this could cause a negative experience for nostr users.

Multiply this times however many NIP upgrades take place (imagine the upgraded nostr binary NIP in lieu of JSON is next for discussion), and you will have a lot of "on nostr _______ doesn't work", or "I never knew you interacted with me" reports from users.

When considering these major changes, consider @pablof7z's view of how nostr wins is creating an awesome experience, not possible on the corpo-gulag monopolies such as twitter. Negative interoperability diminishes the chances of this victory.

The question for yall galaxy brain devs to consider is does this NIP upgrade benefit seriously outweigh the negative interoperability introduced to the network, striving towards the Pabloverse vision of nostr winning.

[melvincarvalho]

If the devs that switch/upgrade to the superior NIP

NIP44 isn't actually superior. It doesn't fix the privacy issues it aims to and is much more complex. NIP04 has its own strengths, especially for simple agent-to-agent communication, which will always be needed. Simplicity wins, which is why nostr succeeded over SSB.

If some central committee decides NIP44 is better, we'll just end up reinventing NIP04, similar to how nostr was invented to simplify SSB. Developers not in the central committee will see this as a rug pull, like what Google did with Angular, making nostr development seem unstable. Developers can't build on quicksand; they'll just spend their time on other things.

We have a lot to improve in nostr. Breaking what's already working shouldn't be a priority. It sends a bad message.

[vitorpamplona]

NIP44 isn't actually superior.

That's not true. NIP-44 encryption protects against many forms of attack that NIP-04 simply can't. NIP-04 is simple exactly because it ignores most of the cryptographic protections that were added onto NIP-44. Simplicity is the only thing NIP04 has going for it. Superiority is not there.

Also, for reference, there were TONS of discussions on how bad NIP-04 is:

• https://github.com/nostr-protocol/nips/issues/107
• https://github.com/nostr-protocol/nips/issues/270
• https://github.com/nostr-protocol/nips/issues/72
• https://github.com/nostr-protocol/nips/discussions/570
• https://github.com/nostr-protocol/nips/pull/572

[erskingardner]

I agree that NIP-04 is not great and NIP-44 is definitely better... but I don't like the idea of breaking user space.

This is a fairly naive idea that I've literally spent 10 seconds thinking about but why don't we just have a tag that signals which encryption scheme a given even uses? That would make it easy for libraries/apps/clients to detect which scheme to use for a given event and makes sure that we're always backwards compatible.

[fiatjaf]

That's the same as telling everybody you have to support both forever because you never know if you'll receive a NIP-04 or a NIP-44.

[erskingardner]

That's the same as telling everybody you have to support both forever because you never know if you'll receive a NIP-04 or a NIP-44.

I mean, that is basically true anyway though right? Even if we deprecate NIP-04 some clients won't update and we'll still have NIP-04 events around.

[fiatjaf]

I mean, that is basically true anyway though right? Even if we deprecate NIP-04 some clients won't update and we'll still have NIP-04 events around.

The idea here is that we will remove, delete, drop, erase NIP-04. If that doesn't happen then I'll consider this a failure and then drop NIP-44 instead from my stuff.

What do you mean by "having events around"? These events are ephemeral.

[alltheseas]

If there is no way to technically identify lack of compatibility between apps A and B, and surface that to the non-technical app end user, then maybe the simplest way to inform or warn of the poor UX is to say: -for nip-04 apps, app is only compatible with damus, app Y, app Z etc -for nip-44 apps, app is only compatible with apps listed in table at the top of this thread

And place the onus on the end user to find out which app(s) their counterparty is using. I think @staab has a similar approach in Coracle DMs.

@karnagebitcoin @robagreda is there a superior design solution in the case of incompatible DM (and potentially other feature) standards?

[staab]

This migration has three steps:

1. Signers add support for both nip 04 and nip 44
2. Clients stop sending nip04-encrypted events
3. Signers drop support for nip04

Knowing whether we can safely take step 3 is the hard part. Signers could monitor requests and update a database somewhere, or the devs could talk to each other, but I've drafted a general-purpose solution to problems like this here: https://github.com/nostr-protocol/nips/pull/1048/files, which would allow clients to signal that they've moved to the new way of doing things.

[staab]

Also, I'm confused, are we talking about the nip46 encryption algorithm only, or DMs? Coracle supports new-style DMs, but I can't confidently move my nip 46 implementation to nip44 until I know it's supported by all the signers people might use.

[fiatjaf]

This issue is just about nip46 encryption, but @alltheseas is talking about DMs for some reason.

[staab]

I added support for using nip46 encryption to welshman this morning, and tested it in Coracle against nsec.app, but it looks like 44 isn't yet supported there. I'm ready to upgrade, but signers have to go first.

[vitorpamplona]

I just merged Amethyst's NIP-46 impl and we will be doing nip44 encryptions out of the gate.

[ekzyis]

According to https://github.com/nostr-dev-kit/ndk/commit/722345bebd4459b5b66d66b4e1ded865fba89499, ndk also supports both now.

[pablof7z]

how about we just change the kind number and use nip44 on this new kind number? far less coordination required.

[fiatjaf]

how about we just change the kind number and use nip44 on this new kind number? far less coordination required.

It doesn't help, a client using nip44 will still not be understood by a bunker using nip04.

[vitorpamplona]

Can we all agree that the plan below is not hard to code? This is so small that, to me, projects that are not doing this should be considered abandoned and should not be used by anyone anymore.

1. Everybody decrypts both nip 04 and nip 44:

Use the utility function below to pick which decryption to use

fun isNIP04(ciphertext: String): Boolean {
    val l = ciphertext.length
    if (l < 28) return false
    return ciphertext[l - 28] == '?' && 
           ciphertext[l - 27] == 'i' && 
           ciphertext[l - 26] == 'v' && 
           ciphertext[l - 25] == '='
}

2. Everybody starts encrypting with NIP44 in their own timeline.

Just rename the function to call nip-44 instead of nip-04 methods.

3. Later, everybody drops support for 1.

[fiatjaf]

What is the state of Coracle, Highlighter and nsec.app?

[staab]

Coracle is ready to use nip44 once signers start supporting it

[fiatjaf]

Coracle is ready to use nip44 once signers start supporting it

Does that mean that if a signer sends a NIP-44 payload today it will work with Coracle?

[staab]

Yep, pretty much everything goes through a function that accepts either and detects 04/44