Oddbean

Dont need to deprecate. But I see what you mean, re inconsistent UX. You can have apps that take advantage of it, and apps that dont. Ultimately nostr is permissionless dev, so some apps do some things, others do other things. Client/client standards can only go so far, at some point, when functionality is needed.

We have to decide if logging in with nostr is a desire-able thing to have. The ecosystem seems to be moving to passkeys, i don’t see why we necessarily need npub identities for login. There are many reasons you wouldn’t want that: privacy, etc.

So a private key is stored locally on device and the corresponding public key is stored in the server. That’s pretty much just Nostr sign-in. The only difference is that passkey approach generates a new key for every app. It’s like using a different private key for every nostr client.

BIP340 are Schnorr signatures? From: https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.07-2014-03-13.pdf Section: C.4.3 EC Schnorr "If a TPM supports ECC, it should support the TPM_ALG_ECSCHNORR scheme."

If half the clients adopt the NIP and half don’t, that’s basically a fork in the network. But the number of clients is small enough that a reset wouldn’t be that bad imo. Worth doing while the network is still young. Especially lack of key rotation needs to be tackled sooner

It's not a fork in the network, because the network of relays remains the same, and all events are both standard, and according to consensus. It's a fork in the clients, not the network. But nostr is exactly designed to have diversity of clients.

I used the term “fork” in a tongue in cheek way. I have been on nostr as long as you Melvin 😂 But the point stands that the user experience is equivalent to a “fork”, yes. The user experience would be split between two incompatible key management NIPs. As mentioned in this thread, it would require a kind of reset for users. But I think it’s worth it because nostr is still quite small and it’s a necessity for growth!

I dont disagree. This is what TimBL refers to as client/client standards, which is what we tried to build into Solid. The client/client standards suffer from the weakness that first movers get an advantage and that technical debt gets ossified quickly. 2+ different key management solutions (which is where we're heading btw) would indeed be indistinguishable from a fork for the end user perspective. The NIPs are a bit of a war zone, too centralzied, and it's hard to get people to agree on something. So we are going to have this problem in any case. If you zoom out, though, there are likely to be a first gen of clients, and a next gen of clients. Subkeys are a simple non intrusive addition. Just add a subkey array to your profile or to your nip-05, and then use that key, and signal to clients provably that it's part of your master key. Those that accept it can, those that dont want to, dont have to. IMHO the only way to do it is a full solution that has full version control anchored in the time chain, but we are a long way from that. Not just nostr, every social project needs this.

I’m in favor of doing the hard thing for the greater benefit in the future. And tbh maybe your solution doesn’t even go far enough. Why not the full pki? Let’s die on a hill worth dying on 😂