From faa1135102ab7534225d8e980e94fcc1472d050f Mon Sep 17 00:00:00 2001 From: ice-orestes <171555308+ice-orestes@users.noreply.github.com> Date: Mon, 9 Sep 2024 16:23:07 +0100 Subject: [PATCH] fix nip-41 links to PR #1032 instead --- 0b.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/0b.md b/0b.md index 0da70e49..c1472f8f 100644 --- a/0b.md +++ b/0b.md @@ -12,18 +12,18 @@ This NIP defines a simple way for an Identity Sub-Key management system, includi The state of art now has two methods for enabling sub-key management: - [NIP-26](https://github.com/nostr-protocol/nips/blob/master/26.md): Multiple key delegation and no revocation (just time bound) -- [NIP-41](https://github.com/nostr-protocol/nips/blob/master/41.md): More complete single key delegation and revocation (complex) +- [NIP-41](https://github.com/nostr-protocol/nips/pull/1032): More complete single key delegation and revocation (complex) Each of these methods has their own pros and cons, but there's a very common use case that is not covered by any of these methods completely, which is having a master identity that is secure (possibly in cold storage), that can whitelist and blacklist multiple public keys (one for each device or app, for example), that can be used individually (less common but interesting for media management companies) and can publish on-behalf of one or several master identities. -Using [NIP-26](https://github.com/nostr-protocol/nips/blob/master/26.md) for this purpose doesn't allow for blacklisting (revocation), or alternatively requires time bound delegation, with new delegation signing at every expiry. On the other hand [NIP-41](https://github.com/nostr-protocol/nips/blob/master/41.md) is a more complete and complex identity management solution, but only allows for one active sub-key at any point in time, and that sub-key's only purpose is bound to the main identity. +Using [NIP-26](https://github.com/nostr-protocol/nips/blob/master/26.md) for this purpose doesn't allow for blacklisting (revocation), or alternatively requires time bound delegation, with new delegation signing at every expiry. On the other hand [NIP-41](https://github.com/nostr-protocol/nips/pull/1032) is a more complete and complex identity management solution, but only allows for one active sub-key at any point in time, and that sub-key's only purpose is bound to the main identity. ### References This proposal came together with inputs from many other proposals and discussions, but these are the main ones: [NIP-26: Delegated Event Signing](https://github.com/nostr-protocol/nips/blob/master/26.md)
-[NIP-41: Identity Management](https://github.com/nostr-protocol/nips/blob/master/41.md)
+[NIP-41: Identity Management](https://github.com/nostr-protocol/nips/pull/1032)
[NIP-06: Basic Key Derivation from Mnemonic Seed Phrase](https://github.com/nostr-protocol/nips/blob/master/06.md)
[NIP-51: Lists](https://github.com/nostr-protocol/nips/blob/master/51.md) @@ -50,7 +50,7 @@ This NIP introduces a replaceable event with `kind 10100`, which is used to keep `.content` fields is unused and can be ignored if present. -This list is owned by the master account, and can only be updated by an event signed by the master account itself, so never using a `b` on-behalf tag (see below), neither by [NIP-41](https://github.com/nostr-protocol/nips/blob/master/41.md) `p` tag in `kind 0`, nor using a [NIP-26](https://github.com/nostr-protocol/nips/blob/master/26.md) `delegation` tag. +This list is owned by the master account, and can only be updated by an event signed by the master account itself, so never using a `b` on-behalf tag (see below), neither by [NIP-41](https://github.com/nostr-protocol/nips/pull/1032) `p` tag in `kind 0`, nor using a [NIP-26](https://github.com/nostr-protocol/nips/blob/master/26.md) `delegation` tag. This list is ever growing, so each update has to include all previous attestations unchanged, and add one or more attestations to the list, otherwise they should be considered invalid and ignored by clients and relays.