Avatar
Silberengel 1y ago

From 3d450733917dafd6bfc6f2b1fc7aa32f09efec6d Mon Sep 17 00:00:00 2001

Subject: [PATCH 0/1] Burning an npub

The npub+nsec combination brings the advantage that no user can have their passkey stolen and end up "locked out" of their own profile or app accounts by the thief changing their passkey. This is a securtiy advancement. However, the problem remains that the passkey (nsec) could be stolen or be given to a bad actor, and then the user must helplessly "share" the passkey with them. Both owner and thief can continue to sign events using this passkey. For this reason, I suggest we give users the possibility to burn an npub, by issuing a final event describing the npub as "retired".

Reply to this note

Please Login to reply.

Discussion

Avatar
Silberengel 1y ago

I've submitted a patch to the event deletion NIP (09.md), adding the possibility to burn or retire an npub, rather than merely emptying it of events through deletion.

You can see the proposal and comment on it by opening the note below or by clicking https://gitworkshop.dev/repo/nips/proposal/23791a60b65c898b2eaa500323ef918e0c9d61b6a6dc16d7da42a3cc935075d7

nostr:nevent1qqszx7g6vzm9ezvt9649qqera7gcuryavxm2dhqk6ldy9g7vjdg8t4cpp4mhxue69uhkummn9ekx7mqzyr7jprhgeregx7q2j4fgjmjgy0xfm34l63pqvwyf2acsd9q0mynuzyshtlf

Avatar
Josua Schmid 1y ago

I like the idea. A burned npub is like a lost npub. Compromiser can burn it. Fine, as long as there cannot be a migration event together with the deletion. I don‘t see a solution for migrations in nostr because time is not absolute. Referencing other events can only give relative time.

Avatar
Silberengel 1y ago

They were discussing (in a separate dev hellthread) that we could add a layer of validation to a migration by using WoT and NIP-05, or even a linked key.

nostr:nevent1qvzqqqqqqypzphtxf40yq9jr82xdd8cqtts5szqyx5tcndvaukhsvfmduetr85ceqqsy4nget7dvsdlh64mjm46px9xm88wz64qv2k6t2sfxzaf7djtnfrgp9rp8l

Avatar
Silberengel 1y ago

I encourage everyone to take this opportunity to try reading and reviewing a git proposal, so that you can see how cool this is. I downloaded a copy of the git code repository that this ngit account links to, changed one of the files, committed (saved) it locally in my copy, and then I use ngit to send the committed change to the people running the "official" repository. If they like my commit, they can pull it into their copy of the code. If they don't like my commit, they can close the proposal or ask me to make changes to it.

Don't worry about spamming the replies, as none of this is located in the actual git repository; it's just normal Nostr stuff.

39
purple.co 1y ago

+

39
purple.co 1y ago

retired or locked

Avatar
Silberengel 1y ago

Locked implies it could eventually be unlocked. Sounds less final.

Can't really lock and then unlock an npub because the nsec can't change, as far as I know.

39
purple.co 1y ago

A lot of events are signed with the key, and very hard to delete all, to keep but locked will allow history/backup, before retire.

Avatar
Silberengel 1y ago

Are you defining

"locked" as "frozen, but don't delete anything, yet"

versus

"retired" as "already locked and events now ready for deletion"?

Or are you using locked as a different word for the second thing?

39
purple.co 1y ago

I think 2 stages can be useful. Retired imply deletion, and more difficult to implement by all relays. Or, maybe, locked is like blocked.

Avatar
Bac0t 1y ago

cc : nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c

Avatar
Mike Dilger ☑️ 1y ago

It's a new 'git' stuff event that I don't support yet. It wouldn't even be displayed except I presume somebody reposted or quoted it.

39
purple.co 1y ago

Maybe one nip will define standard predefined response that can be added/imported into a client. If nostr will get 10k types of events it will be impossible to implement by all clients, but a predefined text/response can be integrated more easily and be show just in case.

Avatar
Mike Dilger ☑️ 1y ago

I have a predefined text response: UNSUPPORTED EVENT KIND

;-)

I went ahead and added about 20 new event kinds to my library, and then marked about 5 of those as feed-displayable. If the contents are feed-displayable, it will now display them but since the event kind is not understood really, It titles (in blue) the content with the event kind so you know better what it is you are looking it. This is on unstable.