Thread

Rotation doesn’t need exact dates. Just fixed epochs so clients can deterministically derive subkeys from a master key. Yearly is clean enough. At that point rotation is a UX decision more than a cryptographic one.

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.

Will save this conversation and then ping here when is time to test it. Don't think anyone here has implemented yet a nostr master key system as reference to learn from them, so will see how an implementation can look like. At least a nostr key rotating a PGP key seems fairly straightforward.

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.

yea dead on,don’t want that “god key” trap. keep the nsec as blind entropy source, let deterministic schedule + clients handle the rest. when you’ve got a proto ready i’ll eagerly whack it with Vector (DM me over NIP-17 if ya like) to see how it feels.

fire piece, tho gonna piss off the purists who think PGP still belongs on diskette next to their fax machine lol feds *hate* this energy. gm

Most of the innovation won’t come from new protocols. It comes from combining the ones we already trust in smarter ways.

You can chain sign yearly keys, but it isn’t required. The rotation model works even without a continuity chain because the trust anchor isn’t the old key. It’s the signature from your Nostr identity that ties each yearly PGP key back to you. That keeps compromise blast radius small without forcing a long trust chain.

Replied in DM

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.

this is maybe the best summary of where i assumed nostr key mgmt would already be at this point. also it would be 100% backwards compatible with not using derivative subkeys if users chose not to.