Very draft mode here. Lots of tweaking to come. These are noted to be just NSECs and NPUBs on the network and are just specially named behind the scenes for Key Manager and Client Side Use.

For Nostr users, this effort aims to make the platform more flexible and user-friendly by introducing a system where you can manage multiple public identities (npubs) from a single private key (nsec). Imagine having different npubs for public posts, private chats, anonymous engagement, or temporary interactions like event subscriptions—all securely linked under one root key you control. This could enhance your privacy by letting you separate your online activities, simplify key management by reducing the need for multiple standalone keys, and make it easier to join niche communities or try new features without risking your main identity. However, adopting this would mean new ways to handle keys, apart from clients, which is healthy, and its success depends on how seamlessly Nostr apps integrate and explain this system to avoid confusion.

This is a necessary solve for massive adoption.

nostr:nevent1qqs8lypu4fug50c68w8zc0adkgd495crx54pfy4n6hns0m4vza7gp3qpzemhxw309ucnjv3wxymrst338qhrww3hxumnwhax9fy

nostr:nprofile1qqswuyd9ml6qcxd92h6pleptfrcqucvvjy39vg4wx7mv9wm8kakyujgua442w where does this NIP-ID overlap with the goals of your NIP-A0? And where does it expand on it? Would a collab make sense? Or, would keeping effort separated but complimentary make sense? I’ve been in touch with a dev team regarding implementation of a key storage method on hardware. But haven’t explored yet with any client developers. Let me know if you’d like to explore collaborating. Client dev and Relay dev engagement are next on my list.

You can't in general derive two different NPUBs from the same NSEC, or have two different NSECs for the same NPUB. There might be high order reflections/overrlaps, but they end up being mathematically equivalent. For example, these two NSECs are the same:

3501454135014541350145413501453fefb02227e449e57cf4d3a3ce05378683

cafebabecafebabecafebabecafebabecafebabecafebabecafebabecafebabe

But most nsecs won't have a reflection.

IMHO if nostr is to move to a masterkey-subkey situation, we should use that opportunity to allow for different kinds of keys and different cryptosystems. I want an ed25519 device key issued by my master nsec (and if nostr doesn't support it I don't care because I can still use it in my own projects). Ideally I'd want an ed25519 master key but I predict that nostr won't move in that direction because of the "one way" rule.

Also, I want my current keypair to be a device key under a master key that doesn't even exist yet. Because everybody already knows me by this keypair. Clearly it cannot be derived from the future master key.

For both of these reasons, I don't think deriving device keys from a master key is going to work. I think they should be independent and simply one signs the other.