update README

This commit is contained in:
Pablo Fernandez 2023-10-19 11:04:46 +03:00
parent b3920f76b4
commit 3b1d74e116
2 changed files with 10 additions and 3 deletions

10
41.md
View File

@ -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).

View File

@ -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) |