Subkey systems don't have to be crazy, they can work the same way as SSO. Nostr hasn't adopted one because people aren't especially concerned about it. https://github.com/nostr-protocol/nips/pull/1450
Discussion
I think it’s a mistake to not tackle that. Too often the UX gets sacrificed because everyone thinks that being tech literate is normal. A working subkey system that’s hidden from the user needs to be adopted, imo.
It’s very much like when I go to some “easy to use software” tool and then the first step is open up a terminal window and type some command… the vast audience that instantly checks out at the step is not appreciated.
The UX for a multi key system needs to be a simple key app, like an OTP app or authenticator (which itself is out of the ordinary for most but I think easy enough that it can work), then you go to any client that automatically creates a key, you copy or scan the QR to sign for it, and then that client is associated and treated as your account. Profile information and contacts are synced across npubs.
Then that client shows up in their key app, and at any point they can select it and “delete” it, which signs a new message saying it’s expired, deleted, compromised or whatever and it gets removed from your main npub association.
It would be even better if the main npub is actually shown in place of the client one, after they have been associated. 🤔
I don’t know but that feels like something that’s really important both for security, UX, and so that joining a new client is a very simple, in-band process. Maybe I’m wrong, but if nobody else builds it I might break down and do it, then annoy every client for not supporting it.
Much discussion went into this topic, and the conclusion has been so far that the interoperability of nostr apps would be seriously threatened by such a move.
We have nip46 bunkers and now with #Frostr I really think the subkey hell can and will be avoided.
Bunkers are okay, but complicate the system. Do you have a link on how FROST deals with lost keys?
I'm still surprised that people consider the separation of identity and authorization unnecessary. Combining them might be a core Bitcoiner philosophy though
Bunkers are great for power users but terrible UX for the average person.
I don’t know enough about frost to know if or how it solves the problem.
And interoperability would be purely a problem of adoption would it not? That seems like a bad reason to make a decision at this stage. “Soft forks” only get harder and this is an important one. The “damage” of not being integrated is simply creating a new key for a specific client or service., but that other services would still see as belonging to you if they support it.
In other words the problem would be isolated to clients that don’t support it would not not?
Can recommend latest [TGFN](https://thank-god-for-nostr.simplecast.com/episodes/frostr-wBOrP0Te) episode on Frostr.
It achieves the following:
- You can chop your nsec into shards (shamir secrets). These can generate valid signatures with an arbitrary threshold you configured initially
- You have your nsec (or just the shards of it) in cold storage and can distribute shards to bunkers, even custodians with high uptime in a safe way (eg 2 of 3, one at a custodian, one hot in your bunker and one only used when rotating)
- You can rotate the setup to a new set of shards. However, all setups remain valid (possible problem but not if you don't leak your cold storage nsec or threshold of shards). You cannot rotate your nsec though.
This achieves a kind of key rotation without nsec rotation, and still needs bunkers.
A subkey system would simplify the bunker problem but at the huge cost of transmitting, storing and coordinating a bunch of data on nostr for all events for just the subkey-related stuff.
The coordination part is the nastiest: Nostr is distributed so there is no guarantee of consistency. Therefore I wonder how you want to solve the problem of
"Am I really, really sure that I validated this event against the absolute latest state of this user's keys?
Was this event really signed before that old key has been deprecated?"
Nostr is designed so that no relay needs to be an absolute source of truth. The events themselves, signed by the pubkeys are. Self authentication. But what do we do when this assumption is broken? It all falls apart. You cannot have absolute consistency on nostr.
...and subkeys would not simplify the master key leak either.