From 7c444e3474167f7dcdcecf28b8679b022996e958 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Fri, 3 Feb 2023 15:59:07 -0300 Subject: [PATCH 01/16] NIP-23: long-form content. --- 19.md | 11 +++++--- 23.md | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 1 + 3 files changed, 84 insertions(+), 3 deletions(-) create mode 100644 23.md diff --git a/19.md b/19.md index e63ca005..f3dd2b87 100644 --- a/19.md +++ b/19.md @@ -35,6 +35,7 @@ These are the possible bech32 prefixes with `TLV`: - `nprofile`: a nostr profile - `nevent`: a nostr event - `nrelay`: a nostr relay + - `nref`: a nostr parameterized replaceable event coordinate (NIP-33) These possible standardized `TLV` types are indicated here: @@ -42,11 +43,15 @@ These possible standardized `TLV` types are indicated here: - depends on the bech32 prefix: - for `nprofile` it will be the 32 bytes of the profile public key - for `nevent` it will be the 32 bytes of the event id - - for `nrelay`, this is the relay URL. + - for `nrelay`, this is the relay URL + - for `nref`, it is the identifier (the `"d"` tag) of the event being referenced - for `nprofile`, `nevent` and `nrelay` this may be included only once. - `1`: `relay` - - A relay in which the entity (profile or event) is more likely to be found, encoded as UTF-8. This may be included multiple times. - - not applicable to `nrelay`. + - for `nprofile`, `nevent` and `nref`, a relay in which the entity (profile or event) is more likely to be found, encoded as UTF-8. This may be included multiple times +- `2`: `author` + - for `nref`, the 32 bytes of the pubkey of the event + + ## Examples - `npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6` should decode into the public key hex `3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d` and vice-versa diff --git a/23.md b/23.md new file mode 100644 index 00000000..b8b86989 --- /dev/null +++ b/23.md @@ -0,0 +1,75 @@ +NIP-23 +====== + +Long-form Content +----------------- + +`draft` `optional` `author:fiatjaf` + +This NIP defines `kind:30023` (a parameterized replaceable event according to NIP-33) for long-form text content, generally referred to as "articles" or "blog posts". + +"Social" clients that deal primarily with `kind:1` notes should not be expected to implement this NIP. + +### Format + +The `.content` of these events should be a string text in Markdown syntax, including YAML front-matter for other metadata that may be necessary. + +### Metadata + +This NIP defines only `title` as the metadata. For the date of publication the event `.created_at` field should be used, and for "tags"/"hashtags" (i.e. topics about which the event might be of relevance) the `"t"` event tag should be used, as in NIP-12. + +### Editability + +These articles are meant to be editable, so they should make use of the replaceability feature of NIP-33 and include a `"d"` tag with an identifier for the article. Clients should take care to only publish and read these events from relays that implement that. If they don't do that they should also take care to hide old versions of the same article they may receive. + +### Linking + +The article may be linked to using the NIP-19 `nref` code, which should contain both the public key of the author and the article identifier (the `"d"` tag) and some relays. With that information it is possible to locate the article. + +### References + +Writing clients should implement support for parsing pasted NIP-19 `nref` identifiers and adding them automatically to the list of `.tags` of the event, replacing the actual content with a string like `#[tag_index]` in the same way as NIP-08 -- or, if the reference is in the form of a URL (for example, `[click here](nref...)`) then they should be replaced with just the tag number directly (for example, `[click here][0]`). + +Reader clients should parse the Markdown and replace these references with either internal links so the referenced events can be accessed directly, with NIP-21 `nostr:` links or direct links to web clients that will handle these references. + +The idea here is that having these tags is that reader clients can display a list of backreferences at the bottom when one article mentions another. + +### `kind:1` interface + +In case there is the desire for users or clients to share the written article on their "social" clients, a `kind:1` event must be used. + +Since "social" clients aren't expected to understand this NIP, these notes should contain a URL like `nostr:nref1...` specifying the `nref1` code for the article, such that it can be rendered clickable and other users can use a different client than their "social" to read the article -- and also if their client handles both kinds of posts, their client may recognize the URL and handle it internally. + +For clients that want to implement the ability for users to comment on these articles. `kind:1` notes should be used as the comments. They must be made in reply to another `kind:1` as above, such that other people on "social" clients can see the comments and get the context from the note above and load the article being commented on if they so desire. + +## Example of an event + +Article text: + +```markdown +title: Lorem Ipsum +--- + +Lorem [ipsum][4] dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. + +Read more at #[3]. +``` + +Derived event: + +```json +{ + "kind": 30023, + "created_at": 1000000000, + "title": "Lorem Ipsum\\n---\\n\\nLorem [ipsum][4] dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.\n\nRead more at #[3].", + "tags": [ + ["d", "lorem-ipsum"], + ["t", "lorem"], + ["t", "ipsum"], + ["e", "b3e392b11f5d4f28321cedd09303a748acfd0487aea5a7450b3481c60b6e4f87", "wss://relay.example.com"], + ["e", "a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919", "wss://relay.nostr.org"] + ], + "pubkey": "...", + "id": "..." +} +``` diff --git a/README.md b/README.md index 829e61ba..0115e682 100644 --- a/README.md +++ b/README.md @@ -41,6 +41,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh | 3 | Contacts | [2](02.md) | | 4 | Encrypted Direct Messages | [4](04.md) | | 5 | Event Deletion | [9](09.md) | +| 30023 | Long-form Content | [23](23.md) | | 7 | Reaction | [25](25.md) | | 40 | Channel Creation | [28](28.md) | | 41 | Channel Metadata | [28](28.md) | From 0acfd0e84badd3bc54f680e3617ab045a844919c Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sat, 4 Feb 2023 07:16:16 -0300 Subject: [PATCH 02/16] declare `nref` on NIP-33. remove need for NIP-01 bridge event. --- 23.md | 16 +++++----------- 33.md | 18 ++++++++++++++++-- 2 files changed, 21 insertions(+), 13 deletions(-) diff --git a/23.md b/23.md index b8b86989..15597887 100644 --- a/23.md +++ b/23.md @@ -24,23 +24,17 @@ These articles are meant to be editable, so they should make use of the replacea ### Linking -The article may be linked to using the NIP-19 `nref` code, which should contain both the public key of the author and the article identifier (the `"d"` tag) and some relays. With that information it is possible to locate the article. +The article may be linked to using the NIP-19 `nref` code along with the `"f"` tag (see NIP-33 and NIP-19). ### References -Writing clients should implement support for parsing pasted NIP-19 `nref` identifiers and adding them automatically to the list of `.tags` of the event, replacing the actual content with a string like `#[tag_index]` in the same way as NIP-08 -- or, if the reference is in the form of a URL (for example, `[click here](nref...)`) then they should be replaced with just the tag number directly (for example, `[click here][0]`). +Writing clients should implement support for parsing pasted NIP-19 `nref` identifiers and adding them automatically to the list of `.tags` of the event, replacing the actual content with a string like `#[tag_index]` in the same way as NIP-08 -- or, if the reference is in the form of a URL (for example, `[click here](nref1...)`) then they should be replaced with just the tag number directly as if link with that name existed at the bottom of the Markdown (for example, `[click here][0]`). -Reader clients should parse the Markdown and replace these references with either internal links so the referenced events can be accessed directly, with NIP-21 `nostr:` links or direct links to web clients that will handle these references. +Reader clients should parse the Markdown and replace these references with either internal links so the referenced events can be accessed directly, with NIP-21 `nostr:nref1...` links or direct links to web clients that will handle these references. The idea here is that having these tags is that reader clients can display a list of backreferences at the bottom when one article mentions another. -### `kind:1` interface - -In case there is the desire for users or clients to share the written article on their "social" clients, a `kind:1` event must be used. - -Since "social" clients aren't expected to understand this NIP, these notes should contain a URL like `nostr:nref1...` specifying the `nref1` code for the article, such that it can be rendered clickable and other users can use a different client than their "social" to read the article -- and also if their client handles both kinds of posts, their client may recognize the URL and handle it internally. - -For clients that want to implement the ability for users to comment on these articles. `kind:1` notes should be used as the comments. They must be made in reply to another `kind:1` as above, such that other people on "social" clients can see the comments and get the context from the note above and load the article being commented on if they so desire. +The same principles can be applied to `nevent1...`, `note1...`, `nprofile1...` or `npub1...`. ## Example of an event @@ -67,7 +61,7 @@ Derived event: ["t", "lorem"], ["t", "ipsum"], ["e", "b3e392b11f5d4f28321cedd09303a748acfd0487aea5a7450b3481c60b6e4f87", "wss://relay.example.com"], - ["e", "a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919", "wss://relay.nostr.org"] + ["f", "a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919:ipsum", "wss://relay.nostr.org"] ], "pubkey": "...", "id": "..." diff --git a/33.md b/33.md index 6b05bd06..314cc836 100644 --- a/33.md +++ b/33.md @@ -12,10 +12,10 @@ Implementation -------------- The value of a tag is defined as the first parameter of a tag after the tag name. -A *parameterized replaceable event* is defined as an event with a kind `30000 <= n < 40000`. +A *parameterized replaceable event* is defined as an event with a kind `30000 <= n < 40000`. Upon a parameterized replaceable event with a newer timestamp than the currently known latest replaceable event with the same kind and first `d` tag value being received, the old event -SHOULD be discarded and replaced with the newer event. +SHOULD be discarded and replaced with the newer event. A missing or a `d` tag with no value should be interpreted equivalent to a `d` tag with the value as an empty string. Events from the same author with any of the following `tags` replace each other: @@ -30,6 +30,20 @@ replace each other: Clients SHOULD NOT use `d` tags with multiple values and SHOULD include the `d` tag even if it has no value to allow querying using the `#d` filter. +Referencing and tagging +----------------------- + +Normally (as per NIP-01, NIP-12) the `"p"` tag is used for referencing public keys and the +`"e"` tag for referencing event ids and the `note`, `npub`, `nprofile` or `nevent` are their +equivalents for event tags (i.e. an `nprofile` is generally translated into a tag +`["p", "", ""]`). + +To support linking to parameterized replaceable events, the `nref` code is introduced on +NIP-19. It includes the public key of the event author and the `d` tag (and relays) such that +the referenced combination of public key and `d` tag can be found. + +The equivalent in `tags` to the `nref` code is the tag `"f"`, comprised of `["f", ":", ""]`. + Client Behavior --------------- From 16b50a481fa7c373ba8dfbdc92c3b880fecd235a Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sun, 5 Feb 2023 20:23:59 -0300 Subject: [PATCH 03/16] rename `nref` to `nitem` and use the `i` tag. --- 19.md | 8 ++++---- 23.md | 15 +++++++-------- 33.md | 4 ++-- 3 files changed, 13 insertions(+), 14 deletions(-) diff --git a/19.md b/19.md index f3dd2b87..caf60f97 100644 --- a/19.md +++ b/19.md @@ -35,7 +35,7 @@ These are the possible bech32 prefixes with `TLV`: - `nprofile`: a nostr profile - `nevent`: a nostr event - `nrelay`: a nostr relay - - `nref`: a nostr parameterized replaceable event coordinate (NIP-33) + - `nitem`: a nostr parameterized replaceable event coordinate (NIP-33) These possible standardized `TLV` types are indicated here: @@ -44,12 +44,12 @@ These possible standardized `TLV` types are indicated here: - for `nprofile` it will be the 32 bytes of the profile public key - for `nevent` it will be the 32 bytes of the event id - for `nrelay`, this is the relay URL - - for `nref`, it is the identifier (the `"d"` tag) of the event being referenced + - for `nitem`, it is the identifier (the `"d"` tag) of the event being referenced - for `nprofile`, `nevent` and `nrelay` this may be included only once. - `1`: `relay` - - for `nprofile`, `nevent` and `nref`, a relay in which the entity (profile or event) is more likely to be found, encoded as UTF-8. This may be included multiple times + - for `nprofile`, `nevent` and `nitem`, a relay in which the entity (profile or event) is more likely to be found, encoded as UTF-8. This may be included multiple times - `2`: `author` - - for `nref`, the 32 bytes of the pubkey of the event + - for `nitem`, the 32 bytes of the pubkey of the event ## Examples diff --git a/23.md b/23.md index 15597887..d1353aff 100644 --- a/23.md +++ b/23.md @@ -24,13 +24,13 @@ These articles are meant to be editable, so they should make use of the replacea ### Linking -The article may be linked to using the NIP-19 `nref` code along with the `"f"` tag (see NIP-33 and NIP-19). +The article may be linked to using the NIP-19 `nitem` code along with the `"i"` tag (see NIP-33 and NIP-19). ### References -Writing clients should implement support for parsing pasted NIP-19 `nref` identifiers and adding them automatically to the list of `.tags` of the event, replacing the actual content with a string like `#[tag_index]` in the same way as NIP-08 -- or, if the reference is in the form of a URL (for example, `[click here](nref1...)`) then they should be replaced with just the tag number directly as if link with that name existed at the bottom of the Markdown (for example, `[click here][0]`). +Writing clients should implement support for parsing pasted NIP-19 `nitem` identifiers and adding them automatically to the list of `.tags` of the event, replacing the actual content with a string like `#[tag_index]` in the same way as NIP-08 -- or, if the reference is in the form of a URL (for example, `[click here](nitem1...)`) then they should be replaced with just the tag number directly as if link with that name existed at the bottom of the Markdown (for example, `[click here][0]`). -Reader clients should parse the Markdown and replace these references with either internal links so the referenced events can be accessed directly, with NIP-21 `nostr:nref1...` links or direct links to web clients that will handle these references. +Reader clients should parse the Markdown and replace these references with either internal links so the referenced events can be accessed directly, with NIP-21 `nostr:nitem1...` links or direct links to web clients that will handle these references. The idea here is that having these tags is that reader clients can display a list of backreferences at the bottom when one article mentions another. @@ -44,9 +44,9 @@ Article text: title: Lorem Ipsum --- -Lorem [ipsum][4] dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. +Lorem [ipsum][3] dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. -Read more at #[3]. +Read more at #[2]. ``` Derived event: @@ -58,10 +58,9 @@ Derived event: "title": "Lorem Ipsum\\n---\\n\\nLorem [ipsum][4] dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.\n\nRead more at #[3].", "tags": [ ["d", "lorem-ipsum"], - ["t", "lorem"], - ["t", "ipsum"], + ["t", "plceholder"], ["e", "b3e392b11f5d4f28321cedd09303a748acfd0487aea5a7450b3481c60b6e4f87", "wss://relay.example.com"], - ["f", "a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919:ipsum", "wss://relay.nostr.org"] + ["i", "30023:a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919:ipsum", "wss://relay.nostr.org"] ], "pubkey": "...", "id": "..." diff --git a/33.md b/33.md index 314cc836..5b8ad66c 100644 --- a/33.md +++ b/33.md @@ -38,11 +38,11 @@ Normally (as per NIP-01, NIP-12) the `"p"` tag is used for referencing public ke equivalents for event tags (i.e. an `nprofile` is generally translated into a tag `["p", "", ""]`). -To support linking to parameterized replaceable events, the `nref` code is introduced on +To support linking to parameterized replaceable events, the `nitem` code is introduced on NIP-19. It includes the public key of the event author and the `d` tag (and relays) such that the referenced combination of public key and `d` tag can be found. -The equivalent in `tags` to the `nref` code is the tag `"f"`, comprised of `["f", ":", ""]`. +The equivalent in `tags` to the `nitem` code is the tag `"i"`, comprised of `["i", "::", ""]`. Client Behavior --------------- From ea48646a0f2773c9b55bf8ff851eae98b200b3d3 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sun, 5 Feb 2023 21:18:38 -0300 Subject: [PATCH 04/16] get rid of YAML frontmatter. --- 23.md | 34 +++++++++++++++------------------- 1 file changed, 15 insertions(+), 19 deletions(-) diff --git a/23.md b/23.md index d1353aff..54009661 100644 --- a/23.md +++ b/23.md @@ -12,11 +12,18 @@ This NIP defines `kind:30023` (a parameterized replaceable event according to NI ### Format -The `.content` of these events should be a string text in Markdown syntax, including YAML front-matter for other metadata that may be necessary. +The `.content` of these events should be a string text in Markdown syntax. ### Metadata -This NIP defines only `title` as the metadata. For the date of publication the event `.created_at` field should be used, and for "tags"/"hashtags" (i.e. topics about which the event might be of relevance) the `"t"` event tag should be used, as in NIP-12. +For the date of the last update the `.created_at` field should be used, for "tags"/"hashtags" (i.e. topics about which the event might be of relevance) the `"t"` event tag should be used, as per NIP-12. + +Other metadata fields can be added as tags to the event as necessary. Here we standardize 4 that may be useful, although they remain strictly optional: + +- `"title"`, for the article title +- `"image"`, for an image to be shown along with the title +- `"summary"`, for the article summary +- `"published_at"`, for the timestamp in unix seconds (stringified) of the first time the article was published ### Editability @@ -36,29 +43,18 @@ The idea here is that having these tags is that reader clients can display a lis The same principles can be applied to `nevent1...`, `note1...`, `nprofile1...` or `npub1...`. -## Example of an event - -Article text: - -```markdown -title: Lorem Ipsum ---- - -Lorem [ipsum][3] dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. - -Read more at #[2]. -``` - -Derived event: +## Example Event ```json { "kind": 30023, - "created_at": 1000000000, - "title": "Lorem Ipsum\\n---\\n\\nLorem [ipsum][4] dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.\n\nRead more at #[3].", + "created_at": 1675642635, + "title": "Lorem [ipsum][4] dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.\n\nRead more at #[3].", "tags": [ ["d", "lorem-ipsum"], - ["t", "plceholder"], + ["title", "Lorem Ipsum"], + ["published_at", "1296962229"], + ["t", "placeholder"], ["e", "b3e392b11f5d4f28321cedd09303a748acfd0487aea5a7450b3481c60b6e4f87", "wss://relay.example.com"], ["i", "30023:a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919:ipsum", "wss://relay.nostr.org"] ], From 5a5ef4a82d4e9f289ee15939deda3caf87ebde73 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Mon, 6 Feb 2023 08:11:11 -0300 Subject: [PATCH 05/16] encode `kind` into `nitem` --- 19.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/19.md b/19.md index caf60f97..2caf8bd1 100644 --- a/19.md +++ b/19.md @@ -45,11 +45,13 @@ These possible standardized `TLV` types are indicated here: - for `nevent` it will be the 32 bytes of the event id - for `nrelay`, this is the relay URL - for `nitem`, it is the identifier (the `"d"` tag) of the event being referenced - - for `nprofile`, `nevent` and `nrelay` this may be included only once. - `1`: `relay` - - for `nprofile`, `nevent` and `nitem`, a relay in which the entity (profile or event) is more likely to be found, encoded as UTF-8. This may be included multiple times + - for `nprofile`, `nevent` and `nitem`, a relay in which the entity (profile or event) is more likely to be found, encoded as ascii + - this may be included multiple times - `2`: `author` - for `nitem`, the 32 bytes of the pubkey of the event +- `3`: `kind` + - for `nitem`, the 32-bit unsigned integer of the kind, big-endian ## Examples From 694f2f056ef2dbee2846e092572168efbd9cc66c Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Mon, 6 Feb 2023 15:09:32 -0300 Subject: [PATCH 06/16] Update 23.md Co-authored-by: mplorentz --- 23.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/23.md b/23.md index 54009661..a3117b8a 100644 --- a/23.md +++ b/23.md @@ -21,7 +21,7 @@ For the date of the last update the `.created_at` field should be used, for "tag Other metadata fields can be added as tags to the event as necessary. Here we standardize 4 that may be useful, although they remain strictly optional: - `"title"`, for the article title -- `"image"`, for an image to be shown along with the title +- `"image"`, for a URL pointing to an image to be shown along with the title - `"summary"`, for the article summary - `"published_at"`, for the timestamp in unix seconds (stringified) of the first time the article was published From e939751f04fdcf9a04113e692493ee3a4ebc7ba5 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Mon, 6 Feb 2023 15:10:50 -0300 Subject: [PATCH 07/16] Update 23.md Co-authored-by: mplorentz --- 23.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/23.md b/23.md index a3117b8a..cbb726be 100644 --- a/23.md +++ b/23.md @@ -35,7 +35,7 @@ The article may be linked to using the NIP-19 `nitem` code along with the `"i"` ### References -Writing clients should implement support for parsing pasted NIP-19 `nitem` identifiers and adding them automatically to the list of `.tags` of the event, replacing the actual content with a string like `#[tag_index]` in the same way as NIP-08 -- or, if the reference is in the form of a URL (for example, `[click here](nitem1...)`) then they should be replaced with just the tag number directly as if link with that name existed at the bottom of the Markdown (for example, `[click here][0]`). +Clients that support publishing NIP-23 events should implement support for parsing pasted NIP-19 `nitem` identifiers and adding them automatically to the list of `.tags` of the event, replacing the actual content with a string like `#[tag_index]` in the same way as NIP-08 -- or, if the reference is in the form of a URL (for example, `[click here](nitem1...)`) then they should be replaced with just the tag number directly as if link with that name existed at the bottom of the Markdown (for example, `[click here][0]`). Reader clients should parse the Markdown and replace these references with either internal links so the referenced events can be accessed directly, with NIP-21 `nostr:nitem1...` links or direct links to web clients that will handle these references. From e91f8f22216a6a7059d5cb8670bb7a93693caa04 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Thu, 9 Feb 2023 06:59:31 -0300 Subject: [PATCH 08/16] fix title->content typo. --- 23.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/23.md b/23.md index cbb726be..0c9923d9 100644 --- a/23.md +++ b/23.md @@ -49,7 +49,7 @@ The same principles can be applied to `nevent1...`, `note1...`, `nprofile1...` o { "kind": 30023, "created_at": 1675642635, - "title": "Lorem [ipsum][4] dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.\n\nRead more at #[3].", + "content": "Lorem [ipsum][4] dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.\n\nRead more at #[3].", "tags": [ ["d", "lorem-ipsum"], ["title", "Lorem Ipsum"], From 17ffd3ee4efa33c3f6abb4304d1c4dd998efc523 Mon Sep 17 00:00:00 2001 From: William Casarin Date: Mon, 13 Feb 2023 03:36:04 -0800 Subject: [PATCH 09/16] NIP-57: Lightning Zaps (#224) --- 57.md | 146 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 3 ++ 2 files changed, 149 insertions(+) create mode 100644 57.md diff --git a/57.md b/57.md new file mode 100644 index 00000000..78a3fd63 --- /dev/null +++ b/57.md @@ -0,0 +1,146 @@ +NIP-57 +====== + +Lightning Zaps +-------------- + +`draft` `optional` `author:jb55` `author:kieran` + +This NIP defines a new note type called a lightning zap of kind `9735`. These represent paid lightning invoice receipts sent by a lightning node called the `zapper`. We also define another note type of kind `9734` which are `zap request` notes, which will be described in this document. + +Having lightning receipts on nostr allows clients to display lightning payments from entities on the network. These can be used for fun or for spam deterrence. + + +## Definitions + +`zapper` - the lightning node or service that sends zap notes (kind `9735`) + +`zap request` - a note of kind `9734` created by the person zapping + +`zap invoice` - the bolt11 invoice fetched from a custom lnurl endpoint which contains a `zap request` note + + +## Protocol flow + +### Client side + +1. Calculate the lnurl pay request url for a user from the lud06 or lud16 field on their profile + +2. Fetch the lnurl pay request static endpoint (`https://host.com/.well-known/lnurlp/user`) and gather the `allowsNostr` and `nostrPubkey` fields. If `allowsNostr` exists and it is `true`, and if `nostrPubkey` exists and is a valid BIP 340 public key, associate this information with the user. The `nostrPubkey` is the `zapper`'s pubkey, and it is used to authorize zaps sent to that user. + +3. Clients may choose to display a lightning zap button on each post or on the users profile, if the user's lnurl pay request endpoint supports nostr, the client SHOULD generate a `zap invoice` instead of a normal lnurl invoice. + +4. To generate a `zap invoice`, call the `callback` url with `amount` set to the milli-satoshi amount value. A `nostr` querystring value MUST be set as well. It is a uri-encoded `zap request` note signed by the user's key. The `zap request` note contains an `e` tag of the note it is zapping, and a `p` tag of the target user's pubkey. The `e` tag is optional which allows profile tipping. The `zap request` note must also have a `relays` tag, which is gathered from the user's configured relays. The `content` MAY be an additional comment from the user which can be displayed when listing zaps on posts and profiles. + +5. Pay this invoice or pass it to an app that can pay the invoice. Once it's paid, a `zap note` will be created by the `zapper`. + +### LNURL Server side + +The lnurl server will need some additional pieces of information so that clients can know that zap invoices are supported: + +1. Add a `nostrPubkey` to the lnurl-pay static endpoint `/.well-known/lnurlp/user`, where `nostrPubkey` is the nostr pubkey of the `zapper`, the entity that creates zap notes. Clients will use this to authorize zaps. + +2. Add an `allowsNostr` field and set it to true. + +3. In the lnurl-pay callback URL, watch for a `nostr` querystring, where the contents of the note is a uri-encoded `zap request` JSON. + +4. If present, the zap request note must be validated: + + a. It MUST have a valid nostr signature + + b. It MUST have tags + + c. It MUST have at least one p-tag + + d. It MUST have either 0 or 1 e-tag + + e. There should be a `relays` tag with the relays to send the `zap` note to. + +5. If valid, fetch a description hash invoice where the description is this note and this note only. No additional lnurl metadata is included in the description. + +At this point, the lightning node is ready to send the zap note once payment is received. + +## The zap note + +Zap notes are created by a lightning node reacting to paid invoices. Zap notes are only created when the invoice description (committed to the description hash) contains a `zap request` note. + +Example zap note: + +```json +{ + "id": "67b48a14fb66c60c8f9070bdeb37afdfcc3d08ad01989460448e4081eddda446", + "pubkey": "9630f464cca6a5147aa8a35f0bcdd3ce485324e732fd39e09233b1d848238f31", + "created_at": 1674164545, + "kind": 9735, + "tags": [ + [ + "p", + "32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245" + ], + [ + "e", + "3624762a1274dd9636e0c552b53086d70bc88c165bc4dc0f9e836a1eaf86c3b8" + ], + [ + "bolt11", + "lnbc10u1p3unwfusp5t9r3yymhpfqculx78u027lxspgxcr2n2987mx2j55nnfs95nxnzqpp5jmrh92pfld78spqs78v9euf2385t83uvpwk9ldrlvf6ch7tpascqhp5zvkrmemgth3tufcvflmzjzfvjt023nazlhljz2n9hattj4f8jq8qxqyjw5qcqpjrzjqtc4fc44feggv7065fqe5m4ytjarg3repr5j9el35xhmtfexc42yczarjuqqfzqqqqqqqqlgqqqqqqgq9q9qxpqysgq079nkq507a5tw7xgttmj4u990j7wfggtrasah5gd4ywfr2pjcn29383tphp4t48gquelz9z78p4cq7ml3nrrphw5w6eckhjwmhezhnqpy6gyf0" + ], + [ + "description", + "{\"pubkey\":\"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245\",\"content\":\"\",\"id\":\"d9cc14d50fcb8c27539aacf776882942c1a11ea4472f8cdec1dea82fab66279d\",\"created_at\":1674164539,\"sig\":\"77127f636577e9029276be060332ea565deaf89ff215a494ccff16ae3f757065e2bc59b2e8c113dd407917a010b3abd36c8d7ad84c0e3ab7dab3a0b0caa9835d\",\"kind\":9734,\"tags\":[[\"e\",\"3624762a1274dd9636e0c552b53086d70bc88c165bc4dc0f9e836a1eaf86c3b8\"],[\"p\",\"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245\"],[\"relays\",\"wss://relay.damus.io\",\"wss://nostr-relay.wlvs.space\",\"wss://nostr.fmt.wiz.biz\",\"wss://relay.nostr.bg\",\"wss://nostr.oxtr.dev\",\"wss://nostr.v0l.io\",\"wss://brb.io\",\"wss://nostr.bitcoiner.social\",\"ws://monad.jb55.com:8080\",\"wss://relay.snort.social\"]]}" + ], + [ + "preimage", + "5d006d2cf1e73c7148e7519a4c68adc81642ce0e25a432b2434c99f97344c15f" + ] + ], + "content": "", + "sig": "b0a3c5c984ceb777ac455b2f659505df51585d5fd97a0ec1fdb5f3347d392080d4b420240434a3afd909207195dac1e2f7e3df26ba862a45afd8bfe101c2b1cc" + } +``` + +* The zap note MUST have a `bolt11` tag containing the description hash bolt11 invoice. + +* The zap note MUST contain a `description` tag which is the invoice description. + +* `SHA256(description)` MUST match the description hash in the bolt11 invoice. + +* The zap note MAY contain a `preimage` to match against the payment hash of the bolt11 invoice. This isn't really a payment proof, there is no real way to prove that the invoice is real or has been paid. You are trusting the author of the zap note for the legitimacy of the payment. + +The zap note is not a proof of payment, all it proves is that some nostr user fetched an invoice. The existence of the zap note implies the invoice as paid, but it could be a lie given a rogue implementation. + + +### Creating a zap note + +When receiving a payment, the following steps are executed: + +1. Get the description for the invoice. This needs to be saved somewhere during the generation of the description hash invoice. It is saved automatically for you with CLN, which is the reference implementation used here. + +2. Parse the bolt11 description as a JSON nostr note. You SHOULD check the signature of the parsed note to ensure that it is valid. This is the `zap request` note created by the entity who is zapping. + +4. The note MUST have only one `p` tag + +5. The note MUST have 0 or 1 `e` tag + +6. Create a nostr note of kind `9735` that includes the `p` tag AND optional `e` tag. The content SHOULD be empty. The created_at date SHOULD be set to the invoice paid_at date for idempotency. + +7. Send the note to the `relays` declared in the `zap request` note from the invoice description. + +A reference implementation for the zapper is here: [zapper][zapper] + +[zapper]: https://github.com/jb55/cln-nostr-zapper + + +## Client Behavior + +Clients MAY fetch zap notes on posts and profiles: + +`{"kinds": [9735], "#e": [...]}` + +To authorize these notes, clients MUST fetch the `nostrPubkey` from the users configured lightning address or lnurl and ensure that the zaps to their posts were created by this pubkey. If clients don't do this, anyone could forge unauthorized zaps. + +Once authorized, clients MAY tally zaps on posts, and list them on profiles. If the zap request note contains a non-empty `content`, it may display a zap comment. Generally clients should show users the `zap request` note, and use the `zap note` to show "zap authorized by ..." but this is optional. + +## Future Work + +Zaps can be extended to be more private by encrypting zap request notes to the target user, but for simplicity it has been left out of this initial draft. diff --git a/README.md b/README.md index 54bb5d44..d4e3c047 100644 --- a/README.md +++ b/README.md @@ -30,6 +30,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh - [NIP-40: Expiration Timestamp](40.md) - [NIP-42: Authentication of clients to relays](42.md) - [NIP-50: Keywords filter](50.md) +- [NIP-57: Lightning Zaps](57.md) - [NIP-56: Reporting](56.md) - [NIP-65: Relay List Metadata](65.md) @@ -51,6 +52,8 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh | 44 | Channel Mute User | [28](28.md) | | 45-49 | Public Chat Reserved | [28](28.md) | | 1984 | Reporting | [56](56.md) | +| 9734 | Zap Request | [57](57.md) | +| 9735 | Zap | [57](57.md) | | 10002 | Relay List Metadata | [65](65.md) | | 22242 | Client Authentication | [42](42.md) | | 1000-9999 | Regular Events | [16](16.md) | From b4493aa56abdea4b05780651e7af06ea13bbfafa Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Mon, 13 Feb 2023 08:47:23 -0300 Subject: [PATCH 10/16] rename coordinates: nitem->naddr, "i"->"a" --- 19.md | 10 +++++----- 23.md | 8 ++++---- 33.md | 4 ++-- README.md | 1 + 4 files changed, 12 insertions(+), 11 deletions(-) diff --git a/19.md b/19.md index 2caf8bd1..ab3b578d 100644 --- a/19.md +++ b/19.md @@ -35,7 +35,7 @@ These are the possible bech32 prefixes with `TLV`: - `nprofile`: a nostr profile - `nevent`: a nostr event - `nrelay`: a nostr relay - - `nitem`: a nostr parameterized replaceable event coordinate (NIP-33) + - `naddr`: a nostr parameterized replaceable event coordinate (NIP-33) These possible standardized `TLV` types are indicated here: @@ -44,14 +44,14 @@ These possible standardized `TLV` types are indicated here: - for `nprofile` it will be the 32 bytes of the profile public key - for `nevent` it will be the 32 bytes of the event id - for `nrelay`, this is the relay URL - - for `nitem`, it is the identifier (the `"d"` tag) of the event being referenced + - for `naddr`, it is the identifier (the `"d"` tag) of the event being referenced - `1`: `relay` - - for `nprofile`, `nevent` and `nitem`, a relay in which the entity (profile or event) is more likely to be found, encoded as ascii + - for `nprofile`, `nevent` and `naddr`, a relay in which the entity (profile or event) is more likely to be found, encoded as ascii - this may be included multiple times - `2`: `author` - - for `nitem`, the 32 bytes of the pubkey of the event + - for `naddr`, the 32 bytes of the pubkey of the event - `3`: `kind` - - for `nitem`, the 32-bit unsigned integer of the kind, big-endian + - for `naddr`, the 32-bit unsigned integer of the kind, big-endian ## Examples diff --git a/23.md b/23.md index 0c9923d9..0648a354 100644 --- a/23.md +++ b/23.md @@ -31,13 +31,13 @@ These articles are meant to be editable, so they should make use of the replacea ### Linking -The article may be linked to using the NIP-19 `nitem` code along with the `"i"` tag (see NIP-33 and NIP-19). +The article may be linked to using the NIP-19 `naddr` code along with the `"a"` tag (see NIP-33 and NIP-19). ### References -Clients that support publishing NIP-23 events should implement support for parsing pasted NIP-19 `nitem` identifiers and adding them automatically to the list of `.tags` of the event, replacing the actual content with a string like `#[tag_index]` in the same way as NIP-08 -- or, if the reference is in the form of a URL (for example, `[click here](nitem1...)`) then they should be replaced with just the tag number directly as if link with that name existed at the bottom of the Markdown (for example, `[click here][0]`). +Clients that support publishing NIP-23 events should implement support for parsing pasted NIP-19 `naddr` identifiers and adding them automatically to the list of `.tags` of the event, replacing the actual content with a string like `#[tag_index]` in the same way as NIP-08 -- or, if the reference is in the form of a URL (for example, `[click here](naddr1...)`) then they should be replaced with just the tag number directly as if link with that name existed at the bottom of the Markdown (for example, `[click here][0]`). -Reader clients should parse the Markdown and replace these references with either internal links so the referenced events can be accessed directly, with NIP-21 `nostr:nitem1...` links or direct links to web clients that will handle these references. +Reader clients should parse the Markdown and replace these references with either internal links so the referenced events can be accessed directly, with NIP-21 `nostr:naddr1...` links or direct links to web clients that will handle these references. The idea here is that having these tags is that reader clients can display a list of backreferences at the bottom when one article mentions another. @@ -56,7 +56,7 @@ The same principles can be applied to `nevent1...`, `note1...`, `nprofile1...` o ["published_at", "1296962229"], ["t", "placeholder"], ["e", "b3e392b11f5d4f28321cedd09303a748acfd0487aea5a7450b3481c60b6e4f87", "wss://relay.example.com"], - ["i", "30023:a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919:ipsum", "wss://relay.nostr.org"] + ["a", "30023:a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919:ipsum", "wss://relay.nostr.org"] ], "pubkey": "...", "id": "..." diff --git a/33.md b/33.md index 5b8ad66c..409ce4f7 100644 --- a/33.md +++ b/33.md @@ -38,11 +38,11 @@ Normally (as per NIP-01, NIP-12) the `"p"` tag is used for referencing public ke equivalents for event tags (i.e. an `nprofile` is generally translated into a tag `["p", "", ""]`). -To support linking to parameterized replaceable events, the `nitem` code is introduced on +To support linking to parameterized replaceable events, the `naddr` code is introduced on NIP-19. It includes the public key of the event author and the `d` tag (and relays) such that the referenced combination of public key and `d` tag can be found. -The equivalent in `tags` to the `nitem` code is the tag `"i"`, comprised of `["i", "::", ""]`. +The equivalent in `tags` to the `naddr` code is the tag `"a"`, comprised of `["a", "::", ""]`. Client Behavior --------------- diff --git a/README.md b/README.md index 42cbc0c9..c88d9490 100644 --- a/README.md +++ b/README.md @@ -92,6 +92,7 @@ When experimenting with kinds, keep in mind the classification introduced by [NI | ---------- | ----------------------- | ----------------- | ------------------------ | | e | event id (hex) | relay URL, marker | [1](01.md), [10](10.md) | | p | pubkey (hex) | relay URL | [1](01.md) | +| a | coordinates to an event | relay URL | [33](33.md), [23](23.md) | | r | a reference (URL, etc) | | [12](12.md) | | t | hashtag | | [12](12.md) | | g | geohash | | [12](12.md) | From b00888cec79b495f8c01d5abdbf2e1ed373896ab Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Mon, 13 Feb 2023 09:00:09 -0300 Subject: [PATCH 11/16] add nip23 to list. --- README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index c88d9490..7bef8f36 100644 --- a/README.md +++ b/README.md @@ -11,7 +11,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh - [NIP-07: `window.nostr` capability for web browsers](07.md) - [NIP-08: Handling Mentions](08.md) - [NIP-09: Event Deletion](09.md) -- [NIP-10: Conventions for clients' use of `e` and `p` tags in text events.](10.md) +- [NIP-10: Conventions for clients' use of `e` and `p` tags in text events](10.md) - [NIP-11: Relay Information Document](11.md) - [NIP-12: Generic Tag Queries](12.md) - [NIP-13: Proof of Work](13.md) @@ -21,7 +21,8 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh - [NIP-19: bech32-encoded entities](19.md) - [NIP-20: Command Results](20.md) - [NIP-21: `nostr:` URL scheme](21.md) -- [NIP-22: Event created_at Limits](22.md) +- [NIP-22: Event `created_at` Limits](22.md) +- [NIP-23: Long-form Content](23.md) - [NIP-25: Reactions](25.md) - [NIP-26: Delegated Event Signing](26.md) - [NIP-28: Public Chat](28.md) From c80cb09e8097c78640756f72d6ba79286a193dee Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Mon, 13 Feb 2023 14:06:21 -0300 Subject: [PATCH 12/16] simplify description. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 7bef8f36..8f316561 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # NIPs -NIPs stand for **Nostr Implementation Possibilities**. They exist to document what MUST, what SHOULD and what MAY be implemented by [Nostr](https://github.com/fiatjaf/nostr)-compatible _relay_ and _client_ software. +NIPs stand for **Nostr Implementation Possibilities**. They exist to document what may be implemented by [Nostr](https://github.com/fiatjaf/nostr)-compatible _relay_ and _client_ software. - [NIP-01: Basic protocol flow description](01.md) - [NIP-02: Contact List and Petnames](02.md) From 04e7f0cef80802ab7cd1fac7604170dec309ee8c Mon Sep 17 00:00:00 2001 From: Chemaclass Date: Tue, 14 Feb 2023 14:27:06 +0100 Subject: [PATCH 13/16] Fix readme sorting NIP-56/57 --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 8f316561..e45c531b 100644 --- a/README.md +++ b/README.md @@ -31,8 +31,8 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh - [NIP-40: Expiration Timestamp](40.md) - [NIP-42: Authentication of clients to relays](42.md) - [NIP-50: Keywords filter](50.md) -- [NIP-57: Lightning Zaps](57.md) - [NIP-56: Reporting](56.md) +- [NIP-57: Lightning Zaps](57.md) - [NIP-65: Relay List Metadata](65.md) ## Event Kinds From 23b863ad65694f041bbe921168d96cd274b998d3 Mon Sep 17 00:00:00 2001 From: Adam B <13562139+catenocrypt@users.noreply.github.com> Date: Mon, 13 Feb 2023 12:34:12 +0100 Subject: [PATCH 14/16] Minor change to make delegation token/string naming consistent --- 26.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/26.md b/26.md index 955a0430..11468c07 100644 --- a/26.md +++ b/26.md @@ -19,7 +19,7 @@ This NIP introduces a new tag: `delegation` which is formatted as follows: "delegation", , , - <64-byte Schnorr signature of the sha256 hash of the delegation token> + ] ``` From 2a2c665e2719ff2e37e4aadc81a8002ebcc5c1f2 Mon Sep 17 00:00:00 2001 From: SondreB Date: Tue, 14 Feb 2023 23:39:08 +0100 Subject: [PATCH 15/16] Update the key examples with a key pair --- 19.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/19.md b/19.md index ab3b578d..45081b0e 100644 --- a/19.md +++ b/19.md @@ -56,8 +56,8 @@ These possible standardized `TLV` types are indicated here: ## Examples -- `npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6` should decode into the public key hex `3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d` and vice-versa -- `nsec180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsgyumg0` should decode into the private key hex `3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d` and vice-versa +- `npub10elfcs4fr0l0r8af98jlmgdh9c8tcxjvz9qkw038js35mp4dma8qzvjptg` should decode into the public key hex `7e7e9c42a91bfef19fa929e5fda1b72e0ebc1a4c1141673e2794234d86addf4e` and vice-versa +- `nsec1vl029mgpspedva04g90vltkh6fvh240zqtv9k0t9af8935ke9laqsnlfe5` should decode into the private key hex `67dea2ed018072d675f5415ecfaed7d2597555e202d85b3d65ea4e58d2d92ffa` and vice-versa - `nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gpp4mhxue69uhhytnc9e3k7mgpz4mhxue69uhkg6nzv9ejuumpv34kytnrdaksjlyr9p` should decode into a profile with the following TLV items: - pubkey: `3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d` - relay: `wss://r.x.com` From 6849f3bdf4739c4fe52199504092cea7247fc615 Mon Sep 17 00:00:00 2001 From: Semisol <45574030+Semisol@users.noreply.github.com> Date: Tue, 14 Feb 2023 09:38:19 +0300 Subject: [PATCH 16/16] NIP-57: Add amount tag to zap request --- 57.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/57.md b/57.md index 78a3fd63..f6fa4ccf 100644 --- a/57.md +++ b/57.md @@ -30,7 +30,7 @@ Having lightning receipts on nostr allows clients to display lightning payments 3. Clients may choose to display a lightning zap button on each post or on the users profile, if the user's lnurl pay request endpoint supports nostr, the client SHOULD generate a `zap invoice` instead of a normal lnurl invoice. -4. To generate a `zap invoice`, call the `callback` url with `amount` set to the milli-satoshi amount value. A `nostr` querystring value MUST be set as well. It is a uri-encoded `zap request` note signed by the user's key. The `zap request` note contains an `e` tag of the note it is zapping, and a `p` tag of the target user's pubkey. The `e` tag is optional which allows profile tipping. The `zap request` note must also have a `relays` tag, which is gathered from the user's configured relays. The `content` MAY be an additional comment from the user which can be displayed when listing zaps on posts and profiles. +4. To generate a `zap invoice`, call the `callback` url with `amount` set to the milli-satoshi amount value. A `nostr` querystring value MUST be set as well. It is a uri-encoded `zap request` note signed by the user's key. The `zap request` note contains an `e` tag of the note it is zapping, and a `p` tag of the target user's pubkey. The `e` tag is optional which allows profile tipping. The `zap request` note must also have a `relays` tag, which is gathered from the user's configured relays. The `zap request` note SHOULD contain an `amount` tag, which is the milli-satoshi value of the zap which clients SHOULD verify being equal to the amount of the invoice. The `content` MAY be an additional comment from the user which can be displayed when listing zaps on posts and profiles. 5. Pay this invoice or pass it to an app that can pay the invoice. Once it's paid, a `zap note` will be created by the `zapper`. @@ -56,6 +56,8 @@ The lnurl server will need some additional pieces of information so that clients e. There should be a `relays` tag with the relays to send the `zap` note to. + f. If there is an `amount` tag, it MUST be equal to the `amount` query parameter. + 5. If valid, fetch a description hash invoice where the description is this note and this note only. No additional lnurl metadata is included in the description. At this point, the lightning node is ready to send the zap note once payment is received.