joeruelle on Nostr: Read through all of NIP-109, hope it gets implemented. Alex Gleason is right I feel, ...
Read through all of NIP-109, hope it gets implemented. Alex Gleason (nprofile…46gd) is right I feel, this is necessary to scale.
One thing I'd add is a trusted contact. Both the pubkey that wants to delete itself and the pubkey of the trusted contact (or one of) would need to send the 'delete all' event for the relay to process it. Like two people, each with a nuclear key. That would prevent accidents.
Not sure if any other NIP goes through the logistics of adding a trusted contact. Back of the napkin I'd do it something like:
1) I add the pubkey of my trusted contact to my NIP-05 Json file
2) I go to the 'Trusted Contact' field of my profile (a new field under the NIP-05 and lightning address fields) and enter it in
3) My json is checked, sees the pubkey there, trusted contact shows as verified
To change or remove:
1) I must update my NIP-05 json first, either change or remove the trusted contact pubkey
2) I go to my Nostr profile, navigate to trusted contact field and hit "update", which is the only option available. If I haven't changed the json then it returns "nothing to update". If I have changed it then it updates accordingly. This way a hacker cannot update a trusted contact that has been set unless they've also hacked your DNS.
Problem there is how to ensure relays only accept json-compliant updates... maybe that's a whole other can of worms.
Another way could be to simply enforce a delay on updates to the trusted contact, so that you have time to jointly turn the keys before the hacker removes the trusted contact. Or make it so trusted contacts are added for block periods, which can be renewed (and trusted contacts cannot be removed mid-block, so as long as you're lucky the hack doesn't happy at the end of a block).
But anyway, some way to ensure there's a trusted contact with a second nuclear key and that the hacker cannot remove the trusted contact, though I suspect much of this already exists in some NIP somewhere.
One thing I'd add is a trusted contact. Both the pubkey that wants to delete itself and the pubkey of the trusted contact (or one of) would need to send the 'delete all' event for the relay to process it. Like two people, each with a nuclear key. That would prevent accidents.
Not sure if any other NIP goes through the logistics of adding a trusted contact. Back of the napkin I'd do it something like:
1) I add the pubkey of my trusted contact to my NIP-05 Json file
2) I go to the 'Trusted Contact' field of my profile (a new field under the NIP-05 and lightning address fields) and enter it in
3) My json is checked, sees the pubkey there, trusted contact shows as verified
To change or remove:
1) I must update my NIP-05 json first, either change or remove the trusted contact pubkey
2) I go to my Nostr profile, navigate to trusted contact field and hit "update", which is the only option available. If I haven't changed the json then it returns "nothing to update". If I have changed it then it updates accordingly. This way a hacker cannot update a trusted contact that has been set unless they've also hacked your DNS.
Problem there is how to ensure relays only accept json-compliant updates... maybe that's a whole other can of worms.
Another way could be to simply enforce a delay on updates to the trusted contact, so that you have time to jointly turn the keys before the hacker removes the trusted contact. Or make it so trusted contacts are added for block periods, which can be renewed (and trusted contacts cannot be removed mid-block, so as long as you're lucky the hack doesn't happy at the end of a block).
But anyway, some way to ensure there's a trusted contact with a second nuclear key and that the hacker cannot remove the trusted contact, though I suspect much of this already exists in some NIP somewhere.