Discussion
Agreed.
Interesting. Sounds like trying to build the key management system of Hive but without a fast free trustless text storage base layer.
Good luck.
Not an expert in terms of technical implementations but all I can say is that I think we need a solution where we can store a key offline in a safe way and still be able to use apps without a hassle. The whole online identity is attached to it, so we need some ways to ensure that a hack does not compromise everything and we need to start from zero (building up a reputation, connections etc.)
Fair argument. And yes, I think we do need a delegation solution. Maybe some galaxy brain adapter signature so that we don’t need to break backward compatibility is the way. Not a cryptographer ™
could someone ELI5 why nostr keys can’t do something like bitcoin’s xpub?
NIP-26 uses BIP-32 hierarchical, deterministic address generation, just like an XPUB does. But NIP-26 it does not broadcast the XPUB. It broadcasts just the latest pubkey, which is analogous to an address in Bitcoin.
fiatjaf’s critique of NIP-26 is that if it is adopted widely, then identifying people by pubkey no longer works. Everyone needs to be on the lookout for new keys. This makes NIP-26 effectively mandatory since anyone not using it wouldn’t be able to follow people (a key feature of nostr).
There’s probably a cryptographic solution which allows for a stable identifier with hierarchical keys. It just hasn’t been discovered/proposed yet, to my knowledge.
really appreciate the explanation! it sort of sounds like the inverse of how xpubs are used in bitcoin, where you WANT 3rd parties (clients/relays) to be able to dereference the root pubkey.
In #Bitcoin, you generally don’t want want the whole network to track your behavior. So the standard guidance is not to reuse addresses (hashed pubkeys). In the rare circumstance that you DO want someone to be able follow, then your XPUB has everything they need to generate all of your wallet’s addresses.
In #nostr, you DO want people to track (follow) your posts. The current solution is to use a single pubkey. A different, as-yet-undocumented solution would be to use an XPUB-like data structure as your identifier. This would allow you to sign posts with different private keys while your followers had a consistent identifier to track.
They could, but then You’d have to share your xpub to allow others to associate all your child keys with your unified ID. Not optimal
"in a world in which most Nostr users are using NIP-26 for everything, clients that do not implement NIP-26 become completely useless, as all they will see is a constant stream of random keys. They won’t be able to follow anyone or interact with anyone, as these keys will not identify any concrete person"
#[0]
This is a good read! I like your emphasis on simplicity and compatibility and you remind me a lot of Matz (the Ruby creator).
Hey are you ok my friend?