Thread

Replies (18)

Rather than pissed, I'm happy to see a relevant proposal. Now waiting to address the elephant in the room which are rotational nostr key pairs using a master nostr key. Good write-up. At which time of the year should the key be rotated? Does it need exactness in the sense of being in the same day next year? Sorry if this misses the point but I'm looking at this from an implementation perspective. If usable, will implement on geogram for signing emails effortlessly.
clean compromise. yearly epoch feels human-scale, no calendar nitpicks needed. popping a toast that goes β€œyo, tomorrow’s new-key day,tap to migrate, or ride the old one another year” should be enough. if geogram ends up shipping it, hmu,would love to see folks signing e-mails with a Nostr Master Key Pair because *Privacy by Principle* should also hit SMTP.
You can build a signing chain, but it collapses the separation. If the nsec signs each new PGP key, the Nostr key becomes a permanent root authority and a single compromise breaks the entire lifecycle. The whole point of coordinating two systems is to avoid that failure mode. With deterministic epochs, clients can verify rotation without deputizing nsec as a god key. Once you have a stable root, rotation is just schedule + client support. Everything else is implementation detail.
THIS IS AWESOME!! The important thing here is the idea of how to use cryptographic systems in a coordinated way. This opens the door to much more cypherpunk creativity. The crucial point of the design is the strategic coordination of cryptographic systems to solve identity and ownership problems that a single protocol (such as traditional PGP) could not handle alone. Congrats!
They’re hot only because clients force them to be. There’s nothing in the protocol that says the nsec has to live on a daily use device. That’s just UX inertia. The protocol just says: A user has a keypair. Everything else is implementation detail. If Nostr ever adds native key hierarchies, you’d get exactly what you’re describing: offline root and deterministic hot keys. What I’d like to see is epoch rotation on top of that. Treat the nsec as an offline root that never touches a live client, and use it only to deterministically derive the β€˜hot’ operational keys you actually use for a given epoch (year, quarter, whatever). Clients then follow the derived key, not the root, and can auto roll forward when a new epoch key appears in the same family. The root stays cold, the hot keys rotate on a schedule, and a compromise only burns that epoch instead of your entire identity history. A modernized key hierarchy model: Root nsec (offline, cold) -> deterministic derivation -> epoch subkeys (hot, operational) -> clients follow epochs -> rotation becomes normal, safe, automatic This is the same key lifecycle model used everywhere else encryption has matured.