Yes, this is about giving the npub owner more controll.
Like, what if a browser extension is breached or they put their nsec in something dodgy?
Discussion
The problem is the attacker could simply issue this event first and then it would be even harder for the actual owner to do anything.
That would still freeze the account. Hard to see how that's bad.
there might need to be an additional note that this isn't an ephemeral event and instead acts as a kind of revocation
there also needs to be some kind of measure to stop this being easy to accidentally trigger
That's why I made it a separate kind (55), rather than just a new sort of deletion event with a "p" tag (5)
Should maybe be an admin function.
admin functions don't really need to be part of the protocol they would be better in NUDs for sure (aside from better structured versions of the NIPs in NUDs
What do you mean?
i mean that if it's relay management business it doesn't belong in the protocol proper
yes, i would say what we need even more is a single kind number for "relay administration events" so that anyone can use this safely knowing it's not gonna be misunderstood by (most) relays
I've sort of gotten lost in the conversation. Some of it is over my head, now.
Are we looking at ways to double-check the valid ownership of an nsec key to confirm a retirement event or are you guys suggesting something completely different?
Is this about improving NIP-05, so that could be the confirmation and proof-of-move?
yeah, nip-05 improvements could help with this also by adding a third field that marks a transition event, to mitigate the possibility of the key transition event not getting everywhere your events also are
also it might make sense to augment the fields of nip-05 so that they are dated and signed, but that would be a messy upgrade
So, we'd need to add a change to 05.md and then reference that section in 09.md.
#yestr
but this is an example of why we need NUDs so we can stop memorising name number codes and use human language references
What is a NUD?
oh, you didn't see that!
it's something nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft has been working towards with wikifredia - to move the nostr spec to a nostr hosted format, roughly speaking
Nostr Unofficial (specification) Documents
Ah, good. Yeah, makes more sense on a wiki than in git.
how would an attacker get any response out of the relay unless the relay doesn't refuse to delete events for an npub with a signature proving it comes from the npub?
i guess... strfry does by default then?
Def a prob, which makes adding a “fwd npub” to the burn event even more problematic
… BUT (back to sovereign WoT) having prior “is trusted” events published (attesting that the “burned” npub “trusts” some other npubs) as well as some “backup” data MAY help users to migrate between npubs (even post compromise?)
Or maybe we should all really have a master or delegation key with with we can co-sign a lower key, like someone was saying in the other thread.
Then we could use that to sign the burn.
Makes key management complicated, tho.
that was me
and i don't think it's complicated if you think "authority" and "identity" keys one signs to authorise the other, and you advertise that state in your nip-05, in your kind 0 and so on...
the authority keys are only then used for identity related events like those mentioned, nip-05 upgrade to update the keys (and sign the whole thing properly) as part of the nip-05 standard (small nostr client in the nip-05 webserver) and you can then have multiple keys referenced in the kind 0 and change them periodically
all you need to do is also show the derivation paths beside the pubkeys and it's very simple for your keychain to know where it is at
it's really not that complicated but nostr devs are mostly web devs not server devs and certainly not experienced with encoding and cryptography
maybe i should put together a draft protocol for how i think it would be done most simply and robustly instead of typing it over and over again in notes
It's a hard problem. The only simple thing I can think of is leveraging nip05, assuming you still have control over your nip05 you can use that to point to the new official npub. That wouldn't mean wot should pay close attention to nip05, ie, if/when it changes domains or etc. you would want to keep nip05 steady and grow trust with that.
Oh, that's clever. That is really clever.
s/wouldn't/would/g
Nip05 is not secure. Any malicious server can add your pubkey to their well-known. Post-compromise, the same bad actor could immediately update the Nip05 field of your kind0….
Right, I'm saying nip05 is the only real external validation nostr has. For this to work youd need either the open timestamp attestation stuff on profile updates and/or the web of trust to keep track of nip05 domain changes. If the domain changes you loose the trust score. Something like that.. I know it's prob not setup for this right now. For me, I use a nip05 that I manage personally, this may not work as well for nip05 provider services that login with npub, hehe.
It's kinda like keybase or a pgp key server.. some external source of, "hey this is me now" outside of nostr.
shouldn't the nip-05 only be relevant to the npub shown in the kind 0 that contains the URL spec where to look for the nip-05?
anything else on that domain that doesn't have that npub is surely irrelevant if there isn't a corresponding event signed by the same npub?
Right, so the flow would be, you get your key compromised, you post some kind of "hey this key is compromised and here's the new one", and the new key's profile has the same nip05 address but with the new pubkey.
been wanting this forever
but it shouldn't delete the old events, instead they should show a little icon or something to indicate the new npub and group the old npubs with the new npubs for filters and search results....
so there might be some more things to think about yet
Ya I mean, if my key was compromised tomorrow this is what I would do. I will always have control over cloudfodder@rogue.earth. the only thing is, maybe nobody pays close attention to nip05s, but they could. For example, I used to try to find people that way, when jack deleted his completely I was like wth it used to be @cash.app). But then they became almost as useless as a badge because everyone just wanted a cool badge and the nip05 providers don't go and try to prove it's 'you' in any way other than probably with your nostr key. (that's broken because it makes nip05 useless imho).
External validation is the only real way I see to do this kind of stuff..whenever you validate some software via gpg you'll notice this problem, like, which key do I validate with? The answer is you check a few different sources and if the key fingerprint matches you trust it more.
yeah, and there is proper revocation certificates that can't be faked too, that's another one, and as i mentioned to semisol, a real HD keychain, ideally one that builds from a hardware wallet so you can gen a new ID from the seed and probably can even use xpubs then to identify linked keys, but not change them unless the revocation is published
I think better solution … for post or pre compromise npub migration … is for npubs to have set an “emergency contact” flag on one (or more) of their “is trusted” published events. (SovWot NIP is not yet written… but could include this flag for “is trusted” events)
delete events should only be obeyed from the npub of the event being deleted or a relay administrator
not sure why this isn't obvious in this discussion (it's already enforced that way in #replicatr )
I think he means that the person who stole the nsec could front-run the real npub owner.
This was my thought