From 69685588f0d60e73ac0148181472e1ceaea4f767 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sat, 21 Jan 2023 07:36:44 -0300 Subject: specify lowercase on nip01 event hex fields. --- 01.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to '01.md') diff --git a/01.md b/01.md index d040666..38ba290 100644 --- a/01.md +++ b/01.md @@ -16,8 +16,8 @@ The only object type that exists is the `event`, which has the following format ```json { - "id": <32-bytes sha256 of the the serialized event data> - "pubkey": <32-bytes hex-encoded public key of the event creator>, + "id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data> + "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>, "created_at": , "kind": , "tags": [ -- cgit v1.2.3 From 8362ff8f79d913ac1dfded9668cd31dcc8c73f22 Mon Sep 17 00:00:00 2001 From: Ben Franks Date: Wed, 25 Jan 2023 17:10:03 +0000 Subject: Update NIP-01 to clarify since and until filters The since and until filters does not clarify integer format and some relays fail to recognize filters with a float based timestamp. --- 01.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to '01.md') diff --git a/01.md b/01.md index 38ba290..e1e9444 100644 --- a/01.md +++ b/01.md @@ -66,8 +66,8 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th "kinds": , "#e": , "#p": , - "since": , - "until": , + "since": , + "until": , "limit": } ``` -- cgit v1.2.3 From a9dd1ce7710bd801bdc0d09c233d087ca2d3c10d Mon Sep 17 00:00:00 2001 From: Jimmy Song Date: Wed, 8 Feb 2023 23:21:40 +0400 Subject: Added clarification for signature to be in hex --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to '01.md') diff --git a/01.md b/01.md index e1e9444..68efc6f 100644 --- a/01.md +++ b/01.md @@ -26,7 +26,7 @@ The only object type that exists is the `event`, which has the following format ... // other kinds of tags may be included later ], "content": , - "sig": <64-bytes signature of the sha256 hash of the serialized event data, which is the same as the "id" field> + "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field> } ``` -- cgit v1.2.3 From 379252f992c2528e287bc4ce7faee5631aa3f73c Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sat, 25 Feb 2023 13:54:27 -0300 Subject: explicitly prohibit markdown on kind:1. --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to '01.md') diff --git a/01.md b/01.md index 68efc6f..12b5ba9 100644 --- a/01.md +++ b/01.md @@ -98,7 +98,7 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated. ## Basic Event Kinds - `0`: `set_metadata`: the `content` is set to a stringified JSON object `{name: , about: , picture: }` describing the user who created the event. A relay may delete past `set_metadata` events once it gets a new one for the same pubkey. - - `1`: `text_note`: the `content` is set to the text content of a note (anything the user wants to say). Non-plaintext notes should instead use kind 1000-10000 as described in [NIP-16](16.md). + - `1`: `text_note`: the `content` is set to the plaintext content of a note (anything the user wants to say). Markdown links (`[]()` stuff) are not plaintext. - `2`: `recommend_server`: the `content` is set to the URL (e.g., `wss://somerelay.com`) of a relay the event creator wants to recommend to its followers. A relay may choose to treat different message kinds differently, and it may or may not choose to have a default way to handle kinds it doesn't know about. -- cgit v1.2.3 From 5a80a906d41a2d756a01addb50f6bead0061fb29 Mon Sep 17 00:00:00 2001 From: Mike O'Bank <111360219+mikeobank@users.noreply.github.com> Date: Sat, 25 Feb 2023 07:02:48 +0100 Subject: Improve `` specification - "random" is not an accurate description - I've noticed long (sha256 hashes in hex) being rejected by some relays. So there seems a need to specify a max length. - "non empty", cause an empty string could be interpreted as `null` To be decided: - Max length number - Are `subscription_id`s case sensitive? - Will `subscription_id`s be white space trimmed? --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to '01.md') diff --git a/01.md b/01.md index 12b5ba9..d32903b 100644 --- a/01.md +++ b/01.md @@ -55,7 +55,7 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th * `["REQ", , ...]`, used to request events and subscribe to new updates. * `["CLOSE", ]`, used to stop previous subscriptions. -`` is a random string that should be used to represent a subscription. +`` is an arbitrary, non-empty string of max length 64 chars, that should be used to represent a subscription. `` is a JSON object that determines what events will be sent in that subscription, it can have the following attributes: -- cgit v1.2.3 From c74f11b7a921276849f4d0eebc3a90a6a3edf2c1 Mon Sep 17 00:00:00 2001 From: Josua Schmid Date: Fri, 3 Mar 2023 22:29:39 +0100 Subject: Update NIP-01 to clarify pubkey reference We mean to reference any public key. "the key" was a bit unspecific. --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to '01.md') diff --git a/01.md b/01.md index d32903b..0e68de5 100644 --- a/01.md +++ b/01.md @@ -22,7 +22,7 @@ The only object type that exists is the `event`, which has the following format "kind": , "tags": [ ["e", <32-bytes hex of the id of another event>, ], - ["p", <32-bytes hex of the key>, ], + ["p", <32-bytes hex of a pubkey>, ], ... // other kinds of tags may be included later ], "content": , -- cgit v1.2.3 From 88009bea8509d004672551be7346a03c373491d0 Mon Sep 17 00:00:00 2001 From: pablof7z Date: Thu, 16 Mar 2023 15:49:14 +0100 Subject: add NOTICE optional subscription_id --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to '01.md') diff --git a/01.md b/01.md index 0e68de5..eead966 100644 --- a/01.md +++ b/01.md @@ -89,7 +89,7 @@ The `limit` property of a filter is only valid for the initial query and can be Relays can send 2 types of messages, which must also be JSON arrays, according to the following patterns: * `["EVENT", , ]`, used to send events requested by clients. - * `["NOTICE", ]`, used to send human-readable error messages or other things to clients. + * `["NOTICE", , ]`, used to send human-readable error messages or other things to clients. Relays might optionally send a `subscription_id` this notice was caused by. This NIP defines no rules for how `NOTICE` messages should be sent or treated. -- cgit v1.2.3 From b24eb78e048fad09233527cf62c6adf3628ded0d Mon Sep 17 00:00:00 2001 From: Semisol <45574030+Semisol@users.noreply.github.com> Date: Thu, 16 Mar 2023 20:18:59 +0300 Subject: Revert 'add NOTICE optional subscription_id' Reverts 88009bea8509d004672551be7346a03c373491d0 --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to '01.md') diff --git a/01.md b/01.md index eead966..9f60a1d 100644 --- a/01.md +++ b/01.md @@ -89,7 +89,7 @@ The `limit` property of a filter is only valid for the initial query and can be Relays can send 2 types of messages, which must also be JSON arrays, according to the following patterns: * `["EVENT", , ]`, used to send events requested by clients. - * `["NOTICE", , ]`, used to send human-readable error messages or other things to clients. Relays might optionally send a `subscription_id` this notice was caused by. + * `["NOTICE", ]`, used to send human-readable error messages or other things to clients. This NIP defines no rules for how `NOTICE` messages should be sent or treated. -- cgit v1.2.3 From dbbf7902d9e11f3515961ff026daf961cd0d10bd Mon Sep 17 00:00:00 2001 From: Sepehr Safari Date: Wed, 15 Mar 2023 15:14:46 +0330 Subject: remove tiny duplicate text fixed "the the serialized event data" => "the serialized event data" --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to '01.md') diff --git a/01.md b/01.md index 9f60a1d..4cfdd35 100644 --- a/01.md +++ b/01.md @@ -16,7 +16,7 @@ The only object type that exists is the `event`, which has the following format ```json { - "id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data> + "id": <32-bytes lowercase hex-encoded sha256 of the serialized event data> "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>, "created_at": , "kind": , -- cgit v1.2.3 From fb5b7c739ff92cec4962990aa99c54fac9f5de81 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sun, 9 Apr 2023 08:50:24 -0300 Subject: merge NIP-15 into NIP-01. --- 01.md | 5 +++-- 15.md | 21 --------------------- README.md | 3 +-- 3 files changed, 4 insertions(+), 25 deletions(-) delete mode 100644 15.md (limited to '01.md') diff --git a/01.md b/01.md index 4cfdd35..8efb8ec 100644 --- a/01.md +++ b/01.md @@ -4,7 +4,7 @@ NIP-01 Basic protocol flow description ------------------------------- -`draft` `mandatory` `author:fiatjaf` `author:distbit` `author:scsibug` `author:kukks` `author:jb55` +`draft` `mandatory` `author:fiatjaf` `author:distbit` `author:scsibug` `author:kukks` `author:jb55` `author:semisol` This NIP defines the basic protocol that should be implemented by everybody. New NIPs may add new optional (or mandatory) fields and messages and features to the structures and flows described here. @@ -89,7 +89,8 @@ The `limit` property of a filter is only valid for the initial query and can be Relays can send 2 types of messages, which must also be JSON arrays, according to the following patterns: * `["EVENT", , ]`, used to send events requested by clients. - * `["NOTICE", ]`, used to send human-readable error messages or other things to clients. + * `["EOSE", ]`, used to indicate the _end of stored events_ and the beginning of events newly received in real-time. + * `["NOTICE", ]`, used to send human-readable error messages or other things to clients. This NIP defines no rules for how `NOTICE` messages should be sent or treated. diff --git a/15.md b/15.md deleted file mode 100644 index 081a97d..0000000 --- a/15.md +++ /dev/null @@ -1,21 +0,0 @@ -NIP-15 -====== - -End of Stored Events Notice ---------------------------- - -`final` `optional` `author:Semisol` - -Relays may support notifying clients when all stored events have been sent. - -If a relay supports this NIP, the relay SHOULD send the client a `EOSE` message in the format `["EOSE", ]` after it has sent all the events it has persisted and it indicates all the events that come after this message are newly published. - -Client Behavior ---------------- - -Clients SHOULD use the `supported_nips` field to learn if a relay supports end of stored events notices. - -Motivation ----------- - -The motivation for this proposal is to reduce uncertainty when all events have been sent by a relay to make client code possibly less complex. diff --git a/README.md b/README.md index 215e5cd..ec55ab7 100644 --- a/README.md +++ b/README.md @@ -16,7 +16,6 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh - [NIP-12: Generic Tag Queries](12.md) - [NIP-13: Proof of Work](13.md) - [NIP-14: Subject tag in text events.](14.md) -- [NIP-15: End of Stored Events Notice](15.md) - [NIP-16: Event Treatment](16.md) - [NIP-18: Reposts](18.md) - [NIP-19: bech32-encoded entities](19.md) @@ -96,7 +95,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh |--------|---------------------------------------------------------|-------------| | EVENT | used to send events requested to clients | [1](01.md) | | NOTICE | used to send human-readable messages to clients | [1](01.md) | -| EOSE | used to notify clients all stored events have been sent | [15](15.md) | +| EOSE | used to notify clients all stored events have been sent | [1](01.md) | | OK | used to notify clients if an EVENT was successful | [20](20.md) | | AUTH | used to send authentication challenges | [42](42.md) | | COUNT | used to send requested event counts to clients | [45](45.md) | -- cgit v1.2.3 From 4b44453626dccd928952392fa8c6e7807b39a8ba Mon Sep 17 00:00:00 2001 From: Yoji Shidara Date: Tue, 11 Apr 2023 13:48:58 +0900 Subject: Fix a typo; now types are EVENT, EOSE and NOTICE --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to '01.md') diff --git a/01.md b/01.md index 8efb8ec..ae13824 100644 --- a/01.md +++ b/01.md @@ -86,7 +86,7 @@ The `limit` property of a filter is only valid for the initial query and can be ### From relay to client: sending events and notices -Relays can send 2 types of messages, which must also be JSON arrays, according to the following patterns: +Relays can send 3 types of messages, which must also be JSON arrays, according to the following patterns: * `["EVENT", , ]`, used to send events requested by clients. * `["EOSE", ]`, used to indicate the _end of stored events_ and the beginning of events newly received in real-time. -- cgit v1.2.3 From c5f43a8f9047184258f0e59f3e1fcd759acca4e2 Mon Sep 17 00:00:00 2001 From: michaelhall923 Date: Fri, 21 Apr 2023 09:04:20 -0400 Subject: Update 01.md Info on "e" and "p" tags is kind of hard to find so I added a link to it in the place that I intuitively looked for it. --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to '01.md') diff --git a/01.md b/01.md index ae13824..a07a0df 100644 --- a/01.md +++ b/01.md @@ -107,5 +107,5 @@ A relay may choose to treat different message kinds differently, and it may or m ## Other Notes: - Clients should not open more than one websocket to each relay. One channel can support an unlimited number of subscriptions, so clients should do that. -- The `tags` array can store a tag identifier as the first element of each subarray, plus arbitrary information afterward (always as strings). This NIP defines `"p"` — meaning "pubkey", which points to a pubkey of someone that is referred to in the event —, and `"e"` — meaning "event", which points to the id of an event this event is quoting, replying to or referring to somehow. +- The `tags` array can store a tag identifier as the first element of each subarray, plus arbitrary information afterward (always as strings). This NIP defines `"p"` — meaning "pubkey", which points to a pubkey of someone that is referred to in the event —, and `"e"` — meaning "event", which points to the id of an event this event is quoting, replying to or referring to somehow. See [NIP-10](https://github.com/nostr-protocol/nips/blob/127d5518bfa9a4e4e7510490c0b8d95e342dfa4b/10.md) for a detailed description of "e" and "p" tags. - The `` item present on the `"e"` and `"p"` tags is an optional (could be set to `""`) URL of a relay the client could attempt to connect to fetch the tagged event or other events from a tagged profile. It MAY be ignored, but it exists to increase censorship resistance and make the spread of relay addresses more seamless across clients. -- cgit v1.2.3 From ee018ef8a4af08dcf8f4c090bb3815ee13f4c627 Mon Sep 17 00:00:00 2001 From: Josua Schmid Date: Sun, 7 May 2023 21:53:35 +0200 Subject: Rephrase Markdown special rule --- 01.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to '01.md') diff --git a/01.md b/01.md index a07a0df..3d8c745 100644 --- a/01.md +++ b/01.md @@ -99,7 +99,8 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated. ## Basic Event Kinds - `0`: `set_metadata`: the `content` is set to a stringified JSON object `{name: , about: , picture: }` describing the user who created the event. A relay may delete past `set_metadata` events once it gets a new one for the same pubkey. - - `1`: `text_note`: the `content` is set to the plaintext content of a note (anything the user wants to say). Markdown links (`[]()` stuff) are not plaintext. + - `1`: `text_note`: the `content` is set to the plaintext content of a note (anything the user wants to say).\ + Do not use Markdown! Clients should not have to guess how to interpret content like `[Example](https://example.com)`. Use different event kinds for parsable content. - `2`: `recommend_server`: the `content` is set to the URL (e.g., `wss://somerelay.com`) of a relay the event creator wants to recommend to its followers. A relay may choose to treat different message kinds differently, and it may or may not choose to have a default way to handle kinds it doesn't know about. -- cgit v1.2.3 From 89a7aa0ea0197b478e96d2a281ac4d096c44caad Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Mon, 8 May 2023 11:05:58 -0300 Subject: nip01: remove misleading markdown example. --- 01.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to '01.md') diff --git a/01.md b/01.md index 3d8c745..713e655 100644 --- a/01.md +++ b/01.md @@ -99,8 +99,7 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated. ## Basic Event Kinds - `0`: `set_metadata`: the `content` is set to a stringified JSON object `{name: , about: , picture: }` describing the user who created the event. A relay may delete past `set_metadata` events once it gets a new one for the same pubkey. - - `1`: `text_note`: the `content` is set to the plaintext content of a note (anything the user wants to say).\ - Do not use Markdown! Clients should not have to guess how to interpret content like `[Example](https://example.com)`. Use different event kinds for parsable content. + - `1`: `text_note`: the `content` is set to the plaintext content of a note (anything the user wants to say). Do not use Markdown! Clients should not have to guess how to interpret content like `[]()`. Use different event kinds for parsable content. - `2`: `recommend_server`: the `content` is set to the URL (e.g., `wss://somerelay.com`) of a relay the event creator wants to recommend to its followers. A relay may choose to treat different message kinds differently, and it may or may not choose to have a default way to handle kinds it doesn't know about. -- cgit v1.2.3 From 60aa6ae168e8d71e4fd247e49f8ba70fbe511fda Mon Sep 17 00:00:00 2001 From: "Robert C. Martin" Date: Tue, 9 May 2023 10:17:15 -0500 Subject: A few changes to some nips. (#510) --- 01.md | 1 + 47.md | 19 +++++++++++++++---- 2 files changed, 16 insertions(+), 4 deletions(-) (limited to '01.md') diff --git a/01.md b/01.md index 713e655..e36f4f5 100644 --- a/01.md +++ b/01.md @@ -109,3 +109,4 @@ A relay may choose to treat different message kinds differently, and it may or m - Clients should not open more than one websocket to each relay. One channel can support an unlimited number of subscriptions, so clients should do that. - The `tags` array can store a tag identifier as the first element of each subarray, plus arbitrary information afterward (always as strings). This NIP defines `"p"` — meaning "pubkey", which points to a pubkey of someone that is referred to in the event —, and `"e"` — meaning "event", which points to the id of an event this event is quoting, replying to or referring to somehow. See [NIP-10](https://github.com/nostr-protocol/nips/blob/127d5518bfa9a4e4e7510490c0b8d95e342dfa4b/10.md) for a detailed description of "e" and "p" tags. - The `` item present on the `"e"` and `"p"` tags is an optional (could be set to `""`) URL of a relay the client could attempt to connect to fetch the tagged event or other events from a tagged profile. It MAY be ignored, but it exists to increase censorship resistance and make the spread of relay addresses more seamless across clients. +- Clients should use the created_at field to judge the age of a metadata event and completely replace older metadata events with newer metadata events regardless of the order in which they arrive. Clients should not merge any filled fields within older metadata events into empty fields of newer metadata events. diff --git a/47.md b/47.md index aa58b5c..fe3d575 100644 --- a/47.md +++ b/47.md @@ -12,8 +12,18 @@ This NIP describes a way for clients to access a remote Lightning wallet through ## Terms -* **client**: Nostr app on any platform that wants to pay Lightning invoices -* **wallet service**: Nostr app that typically runs on an always-on computer (eg. in the cloud or on a Raspberry Pi). +* **client**: Nostr app on any platform that wants to pay Lightning invoices. +* **user**: The person using the **client**, and want's to connect their wallet app to their **client**. +* **wallet service**: Nostr app that typically runs on an always-on computer (eg. in the cloud or on a Raspberry Pi). This app has access to the APIs of the wallets it serves. + +## Theory of Operation + 1. **Users** who which to use this NIP to send lightning payments to other nostr users must first acquire a special "connection" URI from their NIP-47 compliant wallet application. The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means. + + 2. The **user** should then copy this URI into their **client(s)** by pasting, or scanning the QR, etc. The **client(s)** should save this URI and use it later whenever the **user** makes a payment. The **client** should then request an `info` (13194) event from the relay(s) specified in the URI. The **wallet service** will have sent that event to those relays earlier, and the relays will hold it as a replaceable event. + + 3. When the **user** initiates a payment their nostr **client** create a `pay_invoice` request, encrypts it using a token from the URI, and sends it (kind 23194) to the relay(s) specified in the connection URI. The **wallet service** will be listening on those relays and will decrypt the request and then contact the **user's** wallet application to send the payment. The **wallet service** will know how to talk to the wallet application because the connection URI specified relay(s) that have access to the wallet app API. + + 4. Once the payment is complete the **wallet service** will send an encrypted `response` (kind 23195) to the **user** over the relay(s) in the URI. ## Events @@ -24,7 +34,8 @@ There are three event kinds: The info event should be a replaceable event that is published by the **wallet service** on the relay to indicate which commands it supports. The content should be a plaintext string with the supported commands, space-seperated, eg. `pay_invoice get_balance`. Only the `pay_invoice` command is described in this NIP, but other commands might be defined in different NIPs. -Both the request and response events SHOULD contain one `p` tag, containing the public key of the **wallet service** if this is a request, and the public key of the **client** if this is a response. The response event SHOULD contain an `e` tag with the id of the request event it is responding to. + +Both the request and response events SHOULD contain one `p` tag, containing the public key of the **wallet service** if this is a request, and the public key of the **user** if this is a response. The response event SHOULD contain an `e` tag with the id of the request event it is responding to. The content of requests and responses is encrypted with [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md), and is a JSON-RPCish object with a semi-fixed structure: @@ -117,7 +128,7 @@ Errors: ## Example pay invoice flow 0. The user scans the QR code generated by the **wallet service** with their **client** application, they follow a `nostr+walletconnect:` deeplink or configure the connection details manually. -1. **client** sends an event to with **wallet service** service with kind `23194`. The content is a `pay_invoice` request. The private key is the secret from the connection string above. +1. **client** sends an event to the **wallet service** service with kind `23194`. The content is a `pay_invoice` request. The private key is the secret from the connection string above. 2. **wallet service** verifies that the author's key is authorized to perform the payment, decrypts the payload and sends the payment. 3. **wallet service** responds to the event by sending an event with kind `23195` and content being a response either containing an error message or a preimage. -- cgit v1.2.3