The first reply suggests first just using a Private Use range, and then later applying to IANA for a permanent number. Maybe wait with the IANA process until there's two implementations in beta stage and interoperable.
The next steps, getting a Recommended=Y tick mark, is something you can do when people use it in production. But I'm not sure if that's worth doing.
The author continues to point out how the secp256k1 curve is not ideal if you're designing a protocol from scratch. To be interoperable with other implementations we can just pick another curve from the list (e.g. the mandatory one). I would say that's for (far) in the future.
I do think secp256k1 is a good choice for Nostr as long as Nostr itself builds on it. The curve also has the worlds largest bug bounty on it, making it a classic case of "bad in theory, good in practice". I don't think it's worth arguing with people about that though, as people did here: https://github.com/w3c/webcrypto/issues/82 - something about bringing a horse to water.
cc @JeffG.
💯 Yeah. Sounds like we're on the same page. Spec improvements, then demo using the default ciphersuite, then custom secp256k1. 🤝
Oddbean new post about login | logout