As I reflect further on compromised private keys in the context of Nostr, would this be a solution?
Design the protocol to allow use of child private keys that can be rotated when needed (created from an always offline parent private key)
Create a database where users can submit compromised child private keys
Clients check that database and sensor content posted by those keys after the time which they were submitted to the database
Thoughts?
(Happy to discuss / work on this concept further if anyone is interested; and I suppose the above database could be extended beyond just Nostr private keys)
SQRL is a protocol that does the whole decentralized identity thing, but almost no one uses it because most websites are centralized anyway. It looks to me like its a perfect match for nostr. It's well thought out and handles compromised identities with rekeying using a rescue code.
Seems like everyone is reinventing the wheel these days (unknowingly), but it looks to me like the solution is already there, its just needs to be made nostr friendly/compatible.
I was thinking about this and without reinventing the wheel perhaps we can use, as you stated in point #1, child private keys via BIP32.
Because the creation is deterministic, we can invalidate a key simply posting with the next one, avoiding to trust a separate db/system.
But this require some more things:
metatada should include the xpub (necessary to check the public keys sequence)
relays should remember the last valid pub key and reject new notes with old keys
clients have to remember the last valid pub key and reject new notes with old keys
clients have to aggregate content using the xpub as reference
Because a relay can vanish in any moment we have to think how to manage the history rebuild too; because, now if I'm not wrong, one can create and sign an event in the past.
Perhaps timestamping (es. via https://opentimestamps.org) could give some benefit, but also add too.
There is NIP that specifies key delegation: publishing a note that gives a certain client app permission to sign notes for you. That permission can then be revoked at any time in case the app is compromised.
Regarding the storage and usage of the private key:
Hardware wallet that signs events and delegations > Native containes apps where private key is hot > browser extension that contains private key and signs events > pasting private key on webapp
For reference NIP-26
Proposed and used by minds.com
Hardware wallet that signs events and delegations
Standard HW, as we know them today, are ok only to sign a delegation, because it is hard to use them with the high interactions frequency typical of Nostr.
Someone is doing some tests with the SeedSigner.
openssl rand -hex 32