New NIP to lock user

[anurag-l1nt]

This PR defines a new NIP that allows users to block their keys when they suspect or are certain that their keys have been stolen.

Relays implementing this NIP will not accept events from blocked keys, and Clients will hide or visually mark events emitted by blocked keys.

This will mitigate the impact of key theft by preventing identity impersonation.

[vitorpamplona]

This is a weird one because it can be used in the attacker's favor. If I have somebody's private key, I can create events in the past and in the future and send to the relay before locking the account. I can lock the account in some relays, but keep creating events in the past and future on other relays, generating some confusion of what's locked and what's not, what's real and what's not.

That's the main reason I wrote on https://github.com/nostr-protocol/nips/pull/1056 that clients should disqualify anything from that pubkey as soon as one of these events are seen anywhere and followers should repost with a stringified version of the lock/migration event to make sure it is spread everywhere and, most importantly, never gets deleted.

[fiatjaf]

Pablo's proposal is still better. I don't think OTS had anything to do with it not getting traction. It's just that it won't be priority until a catastrophic event occurs, but the OTS requirement isn't that hard to solve, we just need some nice service doing it on our behalf. It's in my list of things to do.

[mleku]

if the cancel event includes a reasonably long link of recent event IDs it could prove precedence, but the concept of chaining events altogether hasn't seen very much use yet, except as necessary for replies, this is an example of how it could be useful, as proof of causality

[vitorpamplona]

OTS isn't hard, but it does create a dependency on a Blockchain lookup service and the need to wait for confirmations from the request to the response time. Requesting OTS events and waiting for confirmations could be better solved in a DVM.

[alexgleason]

This almost the same as https://github.com/nostr-protocol/nips/pull/377, just different semantics.

[anurag-l1nt]

I actually quite like this, but because it relies on wide adoption to be effective, I'd like to see a version that covers key rotation and maybe delegation as well. @pablof7z specced one a while back #829, but it didn't get traction (probably because of the OTS requirement). This is a huge need with nostr, so if this is an area of interest for you I encourage you to push forward on it.

I like Pablo's proposal. In fact, when I wrote this NIP, I had thought about including key replacement and some kind of OTS proof, but I ultimately preferred to keep it simpler in this version and didn't work much on those points.

[anurag-l1nt]

This is a weird one because it can be used in the attacker's favor. If I have somebody's private key, I can create events in the past and in the future and send to the relay before locking the account. I can lock the account in some relays, but keep creating events in the past and future on other relays, generating some confusion of what's locked and what's not, what's real and what's not.

Yes, that can happen. That's why I also wrote that clients should discard (hide or visually mark in some way) the events of a key that has been blocked. I like the idea of clients republishing the events on their relays. This would make propagation faster.

[anurag-l1nt]

Pablo's proposal is still better. I don't think OTS had anything to do with it not getting traction. It's just that it won't be priority until a catastrophic event occurs, but the OTS requirement isn't that hard to solve, we just need some nice service doing it on our behalf. It's in my list of things to do.

Key replacement requires action from the user before the key is compromised. Key blocking could help mitigate issues for those users who haven't taken that action.

I believe the best alternative would be a combination of both: blocking the key with the option to perform a replacement.

[anurag-l1nt]

This almost the same as #377, just different semantics.

Yes, it’s very similar. The main difference with mine is that you propose deleting all previous events, while I only suggest hiding/marking them. I'm not sure which option is more desirable, so possibly the best approach would be to let the user choose what they prefer to do.

[pablof7z]

OTS isn't hard, but it does create a dependency on a Blockchain lookup service and the need to wait for confirmations from the request to the response time. Requesting OTS events and waiting for confirmations could be better solved in a DVM.

I already wrote that DVM when I was working on the NIP-41 stuff.

https://github.com/pablof7z/dvm-references/blob/d3b2405b12e967c07bc5345f11b8d23956187e4e/apps/dvms/src/dvms/notary.ts#L4

You send an event id as the input, it resolves when the stamp has been confirmed with the event id of the NIP-03 that was published

[dluvian]

We shouldn't use kind 1000 for this because it's already used by users like snort and waterblower.

I'm using kind 398

[dluvian]

FYI I implemented this in the latest Voyage release with kind 398

[anurag-l1nt]

We shouldn't use kind 1000 for this because it's already used by users like snort and waterblower.

I'm using kind 398

Used for what? I don't know the implementation for which they are using kind: 1000

Thank you!

[dluvian]

Used for what? I don't know the implementation for which they are using kind: 1000

I have no idea but there are many kind:1000 events

@anurag-l1nt Can you replace kind:1000 with kind:398 ?

[anurag-l1nt]

Used for what? I don't know the implementation for which they are using kind: 1000

I have no idea but there are many kind:1000 events

@anurag-l1nt Can you replace kind:1000 with kind:398 ?

OK. Yes, I change it

[anurag-l1nt]

Used for what? I don't know the implementation for which they are using kind: 1000

I have no idea but there are many kind:1000 events @anurag-l1nt Can you replace kind:1000 with kind:398 ?

OK. Yes, I change it

Done @dluvian

[bezysoftware]

Should relays also not allow AUTH for locked user? Ideally relays should only serve DMs to authed clients who are part of the conversation, but when a user is locked they probably should never serve these events? Therefore AUTH should fail for a locked account

[anurag-l1nt]

Should relays also not allow AUTH for locked user? Ideally relays should only serve DMs to authed clients who are part of the conversation, but when a user is locked they probably should never serve these events? Therefore AUTH should fail for a locked account

I'm sorry for the delay in responding. You are right. Chaged in 4d58a56b027e8f3cc9a5f6714238ed51e45bee97.