Well, I did it some time ago. Nobody cared, just as with the others.
I’m not claiming this is the right way, but after studying Nostr for a while, I concluded that key rotation cannot be handled automatically or authoritatively in a decentralized system. Contact list migration and Web of Trust persistence introduce significant risks, and no universal authority can conclusively determine whether a new key belongs to the same identity after key loss or compromise.
My latest attempt was Checkpoints. The goal was to standardize a minimal, interoperable way to publish identity continuity claims and optional supporting evidence. Clients can then discover and users evaluate these claims using cryptographic and social corroboration.
Identity continuity in Nostr is ultimately observer-dependent, so Checkpoints standardize claims and evidence, not truth. The aim is to avoid ad hoc, application-specific approaches without defining an automatic or deterministic migration rule. The already classic kind 1 saying 'My new key is X' done right, or at least and attempt of it
https://github.com/nostr-protocol/nips/pull/2278
Announced it during #soveng 6, never released the app since nobody cared
nostr:nevent1qvzqqqqqqypzqs9eep0ll6hurjkl3sc2fewgses07mjfwxsdcu3at2m8fd0xrdz3qy0hwumn8ghj7um9v9exx6pwdehhxarjv9exx6rfwejhxtnrdakj7qghwaehxw309aek2ctjvd5zumn0wvh8gmmyv9uj7qpqexm2kghhpk7lazhrag9q38crd77j3w55nrl6tj0y0nfce2e2exts3s3v34
Gzuuus
npub1gz…ea5ds
2026-09-07 15:50:45 UTC
in reply to nevent1q…waaa
Author Public Key
npub1gzuushllat7pet0ccv9yuhygvc8ldeyhrgxuwg744dn5khnpk3gs3ea5dsSeen on
wss://nostr.winePublished at
2026-09-07 15:50:45 UTCEvent JSON
{
"id": "5af684bc70f752edd7abba970b09af9372326c031b32f4966c2605f0e9e97fc4",
"pubkey": "40b9c85fffeafc1cadf8c30a4e5c88660ff6e4971a0dc723d5ab674b5e61b451",
"created_at": 1788796245,
"kind": 1,
"tags": [
[
"t",
"soveng"
],
[
"q",
"c9b6ab22f70dbdfe8ae3ea0a089f036fbd28ba9498ffa5c9e47cd38cab2ac997",
"wss://search.nostrarchives.com/",
"40b9c85fffeafc1cadf8c30a4e5c88660ff6e4971a0dc723d5ab674b5e61b451"
],
[
"e",
"0bb4daf107c109410d85a15391dd4961e47fa97cfc7d35f83c1a1df0bb44d531",
"wss://nostr.mom/",
"root",
"50d94fc2d8580c682b071a542f8b1e31a200b0508bab95a33bef0855df281d63"
],
[
"p",
"50d94fc2d8580c682b071a542f8b1e31a200b0508bab95a33bef0855df281d63"
]
],
"content": "Well, I did it some time ago. Nobody cared, just as with the others.\n\nI’m not claiming this is the right way, but after studying Nostr for a while, I concluded that key rotation cannot be handled automatically or authoritatively in a decentralized system. Contact list migration and Web of Trust persistence introduce significant risks, and no universal authority can conclusively determine whether a new key belongs to the same identity after key loss or compromise.\n\nMy latest attempt was Checkpoints. The goal was to standardize a minimal, interoperable way to publish identity continuity claims and optional supporting evidence. Clients can then discover and users evaluate these claims using cryptographic and social corroboration.\n\nIdentity continuity in Nostr is ultimately observer-dependent, so Checkpoints standardize claims and evidence, not truth. The aim is to avoid ad hoc, application-specific approaches without defining an automatic or deterministic migration rule. The already classic kind 1 saying 'My new key is X' done right, or at least and attempt of it\n\nhttps://github.com/nostr-protocol/nips/pull/2278\nAnnounced it during #soveng 6, never released the app since nobody cared\nnostr:nevent1qvzqqqqqqypzqs9eep0ll6hurjkl3sc2fewgses07mjfwxsdcu3at2m8fd0xrdz3qy0hwumn8ghj7um9v9exx6pwdehhxarjv9exx6rfwejhxtnrdakj7qghwaehxw309aek2ctjvd5zumn0wvh8gmmyv9uj7qpqexm2kghhpk7lazhrag9q38crd77j3w55nrl6tj0y0nfce2e2exts3s3v34",
"sig": "1dcdcffabbada5686c835024f15c17833b620fd1bcf9a7a3d0ab6ccd84c20bd35b282efdaf6b5ffc930084f4fa646703c24a3cc8314c07b3e710c4d5f101404f"
}