With as microscopic as my understanding is, this feels like a legit solution. Is the epoch key difficult to access for the substandard intelligence like me, or is the client handling all of that?
Cold Root Identity v0.1.0
Cold Root Identity is a simple model for survivable Nostr identities. No protocol changes, no new relay behavior, and no delegation logic.
The idea is straightforward:
- A root key stays offline as the authority
- Epoch keys are derived deterministically for actual daily use
- A signed lineage event proves each new epoch key is legitimate
- Clients treat the newest valid epoch as the user’s active identity
- Old posts stay under old keys; new posts use the fresh one
This gives users safe key rotation without burning their entire account. A compromise only affects a single window instead of the whole identity.
The Python reference implementation, test vectors, and spec are here:
https://github.com/GHOST-UntraceableDigitalDissident/cold-root-identity
If you’re a client dev, this is everything needed to implement rotation cleanly today.
Discussion
The epoch key is generated from the root key offline. The client never sees the root and has no visibility into the derivation process. All the client needs is the lineage event you publish that proves “this new pubkey descends from my root.”
Once the client sees that lineage event, it just switches over automatically. Users shouldn’t need to understand HKDF or manage subkeys manually. Clients can handle rotation entirely.
Right now the reference code is just a simple Python prototype that generates and rotates keys offline. (see below) It’s proof of concept. The end state is a small app or built in client feature that handles all of this behind the scenes with one click while your root stays cold.
