From 3b1d74e116230e7f37effd108536943557633472 Mon Sep 17 00:00:00 2001 From: Pablo Fernandez Date: Thu, 19 Oct 2023 11:04:46 +0300 Subject: [PATCH] update README --- 41.md | 10 +++++++--- README.md | 3 +++ 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/41.md b/41.md index 7ab54c79..5c6d8017 100644 --- a/41.md +++ b/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). \ No newline at end of file diff --git a/README.md b/README.md index e9f08bdb..9d7f4fb8 100644 --- a/README.md +++ b/README.md @@ -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) |