Nostr Web Client

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.

ynniv 9mo ago 💬 1

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: https://github.com/nostr-protocol/nips/pull/1450/files

Reply to this note

Please Login to reply.

Discussion

Mike Dilger ☑️ 9mo ago 💬 1

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.

ynniv 9mo ago 💬 1

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.

Mike Dilger ☑️ 9mo ago 💬 1

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.

ynniv 9mo ago

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