Oddbean

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 😂