New NIP to lock user #1411
New NIP to lock user #1411
Conversation
There was a problem hiding this comment.
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.
100.md
Outdated
| The operation of the Relays and C | ||
| lients in the event of receiving an event using [NIP-59](./59.md) will be the same as described in the previous sections, except that the signer of the `seal` event (`kind:13`) will be used to validate whether the event should be accepted (in the case of Relays) or hidden/marked (in the case of Clients). |
There was a problem hiding this comment.
This is impossible for relays to enforce if they don't have the key to decrypt the wrapper.
There was a problem hiding this comment.
Yes, you're right. My mistake. I will remove this part.
There was a problem hiding this comment.
Yes, you're right. My mistake. I will remove this part.
Done in 45b863d
|
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 #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. |
|
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. |
|
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 |
|
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. |
|
This almost the same as #377, just different semantics. |
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. |
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. |
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. |
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. |
There was a problem hiding this comment.
I prefer this over #377. The latter reuses kind 5 which makes it harder to request all my friends who nuked themselves as I have to set authors and #p in the subscription filter and then filter the responses to make sure that p tag == pubkey. With this nip I only have to set authors in the filter which is much more efficient.
I already wrote that DVM when I was working on the NIP-41 stuff. 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 |
Co-authored-by: dluvian <[email protected]>
|
We shouldn't use I'm using |
|
FYI I implemented this in the latest Voyage release with |
Used for what? I don't know the implementation for which they are using Thank you! |
I have no idea but there are many @anurag-l1nt Can you replace |
OK. Yes, I change it |
Done @dluvian |
|
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 4d58a56. |
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.