NIP-XX - Multiple Public Key Types and Signature Algorithms for Event Signing

[ice-orestes]

As mentioned in NIP-01:

Each user has a keypair. Signatures, public key, and encodings are done according to the Schnorr signatures standard for the curve secp256k1.

This is a limitation for Nostr adoption, as many Blockchains and other Cryptographic Networks have already identities in place using different ECC Public Key curves, and may use different Signature Algorithms. Even Bitcoin pre Taproot uses ECDSA/secp256k1 and not Schnorr/secp256k1.

In this case it is just the signatures that differ, and the public key derivation is based out of the same secp256k1 curve, so the public keys remain valid, but for other networks that use EdDSA signatures, for instance, not even the public keys would be valid, as the curve used is Curve25519 instead.

This means that Nostr identities would have to be different than the ones used in the other networks, making it impossible to consider a direct match between one network identity and the other, for instance, for having a smart contract as a Nostr identity (public key).

We want to eliminate this problem, and it is quite simple...

[vitorpamplona]

NACK. This is the same problem DIDs have with now over 200 different DID methods to validate signed credentials. Systems don't talk to one another because it's impossible to support all cryptographic suites.

[ice-orestes]

We are aware of the DID problem @vitorpamplona, but we think that this is not in the same scope. We don't suggest to support all cryptographic algorithms at all. As a matter of fact we don't suggest any specific algorithm, only to open up for the possibility of using other algorithms, but we think that adoption will be the main driver for the selection of algorithms.

If some client/relay decides to use some strange algorithm that no one cares about, then the other relays and clients won't be encouraged to implement it, so nothing will change, and those events won't be valid for most of the network. But if another client/relay uses a common algorithm and because of that is able to bring millions of users to the network, then maybe the other clients and relays would feel the motivation to include that algorithm and serve that user base as well.

This NIP is all about making Nostr an even more open protocol as stated in the first written line of @fiatjaf about Nostr Protocol:

The simplest open protocol that is able to create a censorship-resistant global "social" network once and for all.

As a final thought: not opening up for this possibility will mean that, other networks that would want to join Nostr, will be forced to fork of it and create siloed networks instead of joining forces.

[vitorpamplona]

You said you are aware but you are proposing exactly the same thing here. DID methods are all optional, in the same way you want to make this. They also thought that adoption will be the main driver for the selection of algorithms. It only created a mess of systems that don't even acknowledge each other. The same thing will happen to Nostr if your proposal passes.

[ice-orestes]

The same thing will happen to Nostr if your proposal passes.

The real question @vitorpamplona is: do you really think that the same won't happen, even if this proposal doesn't pass? The only difference will be that those networks will fork of Nostr, instead of joining us... for minority networks this might be a good thing (questionable...), but for large networks it will be a missed opportunity to build adoption for Nostr.

And the only difference will be that we'll end up having multiple Nostr "based" networks, instead of one single Nostr network composed of multiple sub-networks that can optionally be integrated with one another by simply implementing more signing algorithms on clients and relays. The later is more open and the benefits will be far greater than the cons...

[vitorpamplona]

those networks will fork of Nostr, instead of joining us

Do you realize that this PR proposal just formalizes the forks? They are still forks. Your proposal doesn't change anything. It's not because they use our event structure or our relays that suddenly they are "joining us".

You can either pick 2-3 curves, force them on EVERY SINGLE client and relay, and keep things compatible and interoperable with one another, OR you can add 10 curves that are all optional and no one will talk to one another, forking the protocol 10 times.

[ice-orestes]

Do you realize that this PR proposal just formalizes the forks? They are still forks. Your proposal doesn't change anything. It's not because they use our event structure or our relays that suddenly they are "joining us".

Well, not really... the difference is in the network effects or Metcalfe's law. And not only that, but also Nostr keeping the specs of the larger network in check, because if other networks fork of Nostr they will not feel the need to approve any changes to the protocol, as they are already forked anyway... on the other hand, by being in the same network, just using a different signature algo, will keep them contributing back to Nostr network and helping improve the specs. And later, if they prove that their network grows, clients and relays can integrate that user base very effortlessly, because the only divergence will be a signing algorithm support.

[vitorpamplona]

That looks like wishful thinking. As we have seen with DIDs, having multiple options for keys doesn't lead to better network effects and doesn't keep anyone in check with anything. They are just going to keep adding their dependencies to their fork of Nostr in the same way it happens with DID and VCs today. Nothing here tells me that history won't simply repeat itself.

[pablof7z]

This is insanity, sorry to be blunt, but not a whole lot of people are sitting on the sidelines thinking "if only nostr used the same curve as my [insert-shitcoin-here]!" Adoption on nostr depends on nostr providing something the market, people, want, not on supporting a myriad of curves.

This imposes a large tax, and like @vitorpamplona said, an ever expanding one, forks nostr, for absolutely no gain whatsoever.

NACK

[melvincarvalho]

Are you familiar with renostr?

Nostr, as a brand, has become quite tied to Taproot and Schnorr—whether that turns out to be a good or bad decision, we’ll have to wait and see.

I was one of the creators of the DID system, which took a more generalized approach. I get the sense that the nuances of that aren’t well understood by everyone in this thread. One thing we learned through DID was that the degree of optionality depends a lot on the method registry, which became quite political over time. Since you’re also looking at a method registry, it might be worth considering how it will be managed, who will control it, and what criteria will apply. When I set out on creating what became DID, it was intended as a uniform interface for Bitcoin, but it diverged significantly, and now Bitcoin’s more of an afterthought there.

As a final thought: not opening up for this possibility will mean that, other networks that would want to join Nostr, will be forced to fork of it and create siloed networks instead of joining forces.

If forking Nostr is on the table, I’d suggest considering a "soft" fork that’s backwards compatible. That way, generalized relays could still operate with existing Nostr events. Also, I personally like the idea of using URNs to prefix the signatures—maybe something similar to the ISBN structure could work well here.

I’d encourage working cooperatively with the existing Nostr network in a non-breaking way. For now, Nostr as a brand seems likely to stay tied to Taproot, at least in the medium term.

[melvincarvalho]

Another approach you could consider, instead of forking the network, is to allow users to include alternative keys in their profiles. These keys could be signed by the user’s existing Nostr key, which would maintain compatibility with the current network. This way, users could introduce new keys or signature types without breaking the existing structure, and relays or clients that support it could still handle those keys seamlessly.

It keeps things flexible and decentralized while avoiding the need for a fork or a major protocol change. Just a thought!