mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-22 16:35:52 -05:00
update README
This commit is contained in:
parent
b3920f76b4
commit
3b1d74e116
10
41.md
10
41.md
|
@ -76,13 +76,17 @@ When users who follow the old pubkey see a `kind:1777` event they SHOULD:
|
|||
|
||||
After validating all these checks clients SHOULD replace the old pubkey in the user's follow list with the new one.
|
||||
|
||||
### Notes
|
||||
## Notes
|
||||
|
||||
#### Rational behind the 30 days delay
|
||||
### Rational behind the 30 days delay
|
||||
This gives enough time for a user to notice a migration request published by an attacker and gives the user enough time to publish a competing migration request pointing to an earlier `kind:1776` whitelisting event.
|
||||
|
||||
#### Preventing unpublished evil `kind:1777` attack
|
||||
### Preventing unpublished evil `kind:1777` attack
|
||||
Clients should keep track of when a `kind:1777` event should take into effect, counting at least 30 days from the time of seeing the event and not trusting the event timestamp. This is to prevent an attacker creating an evil `kind:1776`, its attestation, and a `kind:1777` event with its attestation and not publishing them until the 30 days of the attestation have elapsed.
|
||||
|
||||
#### Preventing poorly-distributed evil `kind:1777` attack
|
||||
Additionally, clients SHOULD broadcast the `kind:1777` events to the relays it normally writes to. This is to prevent an attacker from creating a short-lived NIP-65 relay list where only a subset of users will see an evil `kind:1777` event but not widespread enough for the real owner to notice it.
|
||||
|
||||
### Future Work
|
||||
|
||||
Key migration can be done in multiple ways. This is an initial implementation that can work. This mechanism should be extended with other, alternative mechanisms, that can leverage different flows/tradeoffs (e.g. social recovery).
|
|
@ -50,6 +50,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
|||
- [NIP-38: User Statuses](38.md)
|
||||
- [NIP-39: External Identities in Profiles](39.md)
|
||||
- [NIP-40: Expiration Timestamp](40.md)
|
||||
- [NIP-41: Identity rotation](41.md)
|
||||
- [NIP-42: Authentication of clients to relays](42.md)
|
||||
- [NIP-45: Counting results](45.md)
|
||||
- [NIP-46: Nostr Connect](46.md)
|
||||
|
@ -93,6 +94,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
|||
| `1063` | File Metadata | [94](94.md) |
|
||||
| `1311` | Live Chat Message | [53](53.md) |
|
||||
| `1040` | OpenTimestamps | [03](03.md) |
|
||||
| `1776` | Key Migration Whitelist | [41](41.md) |
|
||||
| `1777` | Key Migration | [41](41.md) |
|
||||
| `1984` | Reporting | [56](56.md) |
|
||||
| `1985` | Label | [32](32.md) |
|
||||
| `4550` | Community Post Approval | [72](72.md) |
|
||||
|
|
Loading…
Reference in New Issue
Block a user