@Mike Dilger ☑️ 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.

Derivation is so tempting though. I fell into that rabbit hole for weeks before realizing that you can get most of the benefits with more flexibility using simple attestations:

GitHub

NIP-102: Subkey Attestation by ynniv · Pull Request #1450 · nostr-protocol/nips

This NIP defines a way to separate identity from authentication using hierarchical deterministic (HD) keys. This allows people to use one key pair ...

There are a lot of PRs on this doing almost the same thing. I did my version as #1837 Keychains. I thought about adding the attestation to the messages themselves so you don't have to pull a document with the attestation. The issue there is that you don't get up to date revocation information. I didn't notice or thoroughly read through your PR and I will do that now. But take a look at #1837 and we can hash out the differences and reasoning.

Revocation is the edge case, and irrevocable, so you get a better experience by assuming it hasn't been revoked and eventually confirming. It's basically the same as deletion events.

Adding more data (the attestation to the event) cannot possibly break anything. But after 1000 events with the same fairly long attestation, it starts to feel like space is being wasted. Clients could load up the keychain (or whatever you might call it) once and then this data doesn't have to be repeated over and over again.

Repeated data compresses easily though – it only really needs to be included in its entirety during signing and verification