Thread

Interesting, but why deterministic epoch labels instead of time beacons? Seems like a foot gun in which one could store future keys in an app (maybe a greedy app) and get those stolen, or if an attacker gets ahold of your HSM as oracle they could pre-gen your future identities. And since the protocol always accepts the latest created_at identity, a far future one would also always override the current one. I understand there are tradeoffs, and I am not sure if liveness was a design goal, but seems to me a non-deterministic time beacon could offer benefits here, plus a clear time boundary rule too. Otherwise, I would suggest including these guardrails: 1) Explicitly recommend apps/users never pre-generate/store future epoch private keys; derive only the current epoch on the hot device; keep root strictly offline. 2) Add client-side created_at sanity checks.

Except the nsec has to be the same by design. A password of a different app is not related.

Great, don’t do it.

Except the app tends to never be random.