From 1c728516dfdc7508ce27eda222bde78466e3457d Mon Sep 17 00:00:00 2001 From: VictorieeMan <59509525+VictorieeMan@users.noreply.github.com> Date: Sat, 7 Jan 2023 11:11:19 +0100 Subject: [PATCH 01/84] NIP-05: Fixed some typos line 9: Added a hyphen line 53: Fixed the typo by a context appropriate reformulation. line 67: Removed an "are" line 79: Added a comma Great project, looking forward to more nostr :) --- 05.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/05.md b/05.md index a67f530e..56b9156b 100644 --- a/05.md +++ b/05.md @@ -6,7 +6,7 @@ Mapping Nostr keys to DNS-based internet identifiers `final` `optional` `author:fiatjaf` `author:mikedilger` -On events of kind `0` (`set_metadata`) one can specify the key `"nip05"` with an [internet identifier](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (an email-like address) as the value. Although there is a link to a very liberal "internet identifier" specification above, NIP-05 assumes the `` part will be restricted to the characters `a-z0-9-_.`, case insensitive. +On events of kind `0` (`set_metadata`) one can specify the key `"nip05"` with an [internet identifier](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (an email-like address) as the value. Although there is a link to a very liberal "internet identifier" specification above, NIP-05 assumes the `` part will be restricted to the characters `a-z0-9-_.`, case-insensitive. Upon seeing that, the client splits the identifier into `` and `` and use these values to make a GET request to `https:///.well-known/nostr.json?name=`. @@ -50,7 +50,7 @@ or with the **optional** `"relays"` attribute: If the pubkey matches the one given in `"names"` (as in the example above) that means the association is right and the `"nip05"` identifier is valid and can be displayed. -The optional `"relays"` attribute may contain an object with public keys as properties and arrays of relay URLs as values. When present, that can be used to help clients learn in which relays a that user may be found. Web servers which serve `/.well-known/nostr.json` files dynamically based on the query string SHOULD also serve the relays data for any name they serve in the same reply when that is available. +The optional `"relays"` attribute may contain an object with public keys as properties and arrays of relay URLs as values. When present, that can be used to help clients learn in which relays the specific user may be found. Web servers which serve `/.well-known/nostr.json` files dynamically based on the query string SHOULD also serve the relays data for any name they serve in the same reply when that is available. ## Finding users from their NIP-05 identifier @@ -64,7 +64,7 @@ For example, if after finding that `bob@bob.com` has the public key `abc...def`, ### Public keys must be in hex format -Keys must be returned in hex format. Keys in NIP-19 `npub` format are are only meant to be used for display in client UIs, not in this NIP. +Keys must be returned in hex format. Keys in NIP-19 `npub` format are only meant to be used for display in client UIs, not in this NIP. ### User Discovery implementation suggestion @@ -76,7 +76,7 @@ Clients may treat the identifier `_@domain` as the "root" identifier, and choose ### Reasoning for the `/.well-known/nostr.json?name=` format -By adding the `` as a query string instead of as part of the path the protocol can support both dynamic servers that can generate JSON on-demand and static servers with a JSON file in it that may contain multiple names. +By adding the `` as a query string instead of as part of the path, the protocol can support both dynamic servers that can generate JSON on-demand and static servers with a JSON file in it that may contain multiple names. ### Allowing access from JavaScript apps From e2f088286fcd324bb4754dcdf5ff10f4dc823b5b Mon Sep 17 00:00:00 2001 From: Semisol <45574030+Semisol@users.noreply.github.com> Date: Thu, 30 Mar 2023 00:35:13 +0300 Subject: [PATCH 02/84] NIP-47 Wallet Connect --- 47.md | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 47.md diff --git a/47.md b/47.md new file mode 100644 index 00000000..326100de --- /dev/null +++ b/47.md @@ -0,0 +1,112 @@ +NIP-47 +====== + +Nostr Wallet Connect +-------------------- + +`draft` `optional` `author:kiwiidb` `author:bumi` `author:semisol` `author:vitorpamplona` + +## Rationale + +Paying zaps should be possible without the user needing to open a different app to only pay a Lightning invoice. +This NIP describes a way for users to control a remote Lightning node or a custodial Lightning wallet. When self-hosting, this setup does not require the user to run their own server, thereby bypassing certain hurdles that are commonly encountered when trying to connect to a Lightning node remotely. + +## 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). + +## Events + +There are two event kinds: +- `NIP-47 request`: 23194 +- `NIP-47 response`: 23195 + +Both the request and response events SHOULD only 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 content is encrypted with [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md), and is a JSON object. The content depends on the kind. + +Request: +```jsonc +{ + "cmd": "pay_invoice", // command, string + "data": { // data, object + "invoice": "lnbc50n1..." // command-related data + } +} +``` + +Response: +```jsonc +{ + "status": "ok", // status, "ok" | "error" + "event": "0123456789abcdef...", // event the command is in response to, string + "data": { // response data + "preimage": "0123456789abcdef..." // command-related data + } +} +``` + +The data field SHOULD contain a `message` field with a human readable error message if the status is `error`. + +## Nostr Wallet Connect URI +**client** discovers **wallet service** by scanning a QR code, handling a deeplink or pasting in a URI. + +The **wallet service** generates this connection URI with protocol `nostr+walletconnect:` and base path it's hex-encoded `pubkey` with the following query string parameters: + +- `relay` Required. URL of the relay where the **wallet service** is connected and will be listening for events. May be more than one. +- `secret` Required. 32-byte randomly generated hex encoded string. The **client** should use this to sign events when communicating with the **wallet service**. + - Authorization does not require passing keys back and forth. + - The user can have different keys for different applications. Keys can be revoked and created at will and have arbitrary constraints (eg. budgets). + - The key is harder to leak since it is not shown to the user and backed up. + - It improves privacy because the user's main key would not be linked to their payments. + +The **client** should then store this connection and use it when the user wants to perform actions like paying an invoice. Optionally it can display metadata about the connected **wallet service** from it's profile (name, image, url). + +### Example connection string +```sh +nostrwalletconnect:b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558e9d4?relay=wss%3A%2F%2Frelay.damus.io&secret=71a8c14c1407c113601079c4302dab36460f0ccd0ad506f1f2dc73b5100e4f3c +``` + +## Commands + +### `pay_invoice` + +Description: Requests payment of an invoice. + +Request: +```jsonc +{ + "invoice": "lnbc50n1..." // BOLT11 invoice, string +} +``` + +Response: +```jsonc +{ + "preimage": "0123456789abcdef..." // preimage after payment, string +} +``` + +### `balance` + +Description: Requests the balance of the wallet. + +Request: an empty JSON object. + +Response: +```jsonc +{ + "balance": 100000 // balance in msat, int +} +``` + +## Example pay invoice flow + +0. The user scans the QR code generated by the **wallet service** with their **client** application, they follow a `nostrwalletconnect:` 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. +2. **nostr-wallet-connect-service** verifies that the author's key is authorized to perform the payment, decrypts the payload and sends the payment. +3. **nostr-wallet-connect-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. + +## Using a dedicated relay +This NIP does not specify any requirements on the type of relays used. However, if the user is using a custodial service it might make sense to use a relay that is hosted by the custodial service. The relay may then enforce authentication to prevent metadata leaks. Not depending on a 3rd party relay would also improve reliability in this case. From 961f28285a739000277f489573f5b4c22053f27c Mon Sep 17 00:00:00 2001 From: Semisol <45574030+Semisol@users.noreply.github.com> Date: Thu, 30 Mar 2023 01:23:04 +0300 Subject: [PATCH 03/84] NIP-47: Fix up some things --- 47.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/47.md b/47.md index 326100de..96bf906b 100644 --- a/47.md +++ b/47.md @@ -65,7 +65,7 @@ The **client** should then store this connection and use it when the user wants ### Example connection string ```sh -nostrwalletconnect:b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558e9d4?relay=wss%3A%2F%2Frelay.damus.io&secret=71a8c14c1407c113601079c4302dab36460f0ccd0ad506f1f2dc73b5100e4f3c +nostr+walletconnect:b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558e9d4?relay=wss%3A%2F%2Frelay.damus.io&secret=71a8c14c1407c113601079c4302dab36460f0ccd0ad506f1f2dc73b5100e4f3c ``` ## Commands @@ -103,10 +103,10 @@ Response: ## Example pay invoice flow -0. The user scans the QR code generated by the **wallet service** with their **client** application, they follow a `nostrwalletconnect:` deeplink or configure the connection details manually. +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. -2. **nostr-wallet-connect-service** verifies that the author's key is authorized to perform the payment, decrypts the payload and sends the payment. -3. **nostr-wallet-connect-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. +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. ## Using a dedicated relay This NIP does not specify any requirements on the type of relays used. However, if the user is using a custodial service it might make sense to use a relay that is hosted by the custodial service. The relay may then enforce authentication to prevent metadata leaks. Not depending on a 3rd party relay would also improve reliability in this case. From c232c9a46a279883f7d8e07db9f2ae6a79a784c6 Mon Sep 17 00:00:00 2001 From: Semisol <45574030+Semisol@users.noreply.github.com> Date: Mon, 3 Apr 2023 22:18:11 +0300 Subject: [PATCH 04/84] NIP-47: feedbacj --- 47.md | 69 ++++++++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 52 insertions(+), 17 deletions(-) diff --git a/47.md b/47.md index 96bf906b..fd85e133 100644 --- a/47.md +++ b/47.md @@ -8,8 +8,7 @@ Nostr Wallet Connect ## Rationale -Paying zaps should be possible without the user needing to open a different app to only pay a Lightning invoice. -This NIP describes a way for users to control a remote Lightning node or a custodial Lightning wallet. When self-hosting, this setup does not require the user to run their own server, thereby bypassing certain hurdles that are commonly encountered when trying to connect to a Lightning node remotely. +This NIP describes a way for clients to access a remote Lightning wallet through a standardized protocol. Custodians may implement this, or the user may run a bridge that bridges their wallet/node and the Nostr Wallet Connect protocol. ## Terms @@ -47,7 +46,17 @@ Response: } ``` -The data field SHOULD contain a `message` field with a human readable error message if the status is `error`. +The data field SHOULD contain a `message` field with a human readable error message and a `code` field with the error code if the status is `error`. + +### Error codes +- `RATE_LIMITED`: The client is sending commands too fast. It should retry in a few seconds. +- `NOT_IMPLEMENTED`: The command is not known or is intentionally not implemented. +- `INSUFFICIENT_BALANCE`: The wallet does not have enough funds to cover a fee reserve or the payment amount. +- `QUOTA_EXCEEDED`: The wallet has exceeded +- `RESTRICTED`: This public key is not allowed to do this operation. +- `UNAUTHORIZED`: This public key has no wallet connected. +- `INTERNAL`: An internal error. +- `OTHER`: Other error. ## Nostr Wallet Connect URI **client** discovers **wallet service** by scanning a QR code, handling a deeplink or pasting in a URI. @@ -61,7 +70,7 @@ The **wallet service** generates this connection URI with protocol `nostr+wallet - The key is harder to leak since it is not shown to the user and backed up. - It improves privacy because the user's main key would not be linked to their payments. -The **client** should then store this connection and use it when the user wants to perform actions like paying an invoice. Optionally it can display metadata about the connected **wallet service** from it's profile (name, image, url). +The **client** should then store this connection and use it when the user wants to perform actions like paying an invoice. Due to this NIP using ephemeral events, it is recommended to pick relays that do not close connections on inactivity to not drop events. ### Example connection string ```sh @@ -70,6 +79,45 @@ nostr+walletconnect:b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558 ## Commands +### `get_info` + +Description: Get information about the wallet and service. + +Request: Empty object. + +Response: +```jsonc +{ + "balance": 100000, // balance in msat, int + // this should be capped at the quota allowed for this client + // to not report unspendable balance. + "implemented_commands": ["get_info", "pay_invoice"] // commands supported, string array + // extensions can be specified via command+extension: + // get_info+node_info +} +``` + +### `create_invoice` + +Description: Requests creation of an invoice. + +Request: +```jsonc +{ + "amount": 1000, // amount in msat, int + // must be a whole number of sats unless + // create_invoice+msat_amount is implemented. + "description": "memo" // a description, string, optional +} +``` + +Response: +```jsonc +{ + "invoice": "lnbc50n1..." // BOLT11 invoice, string +} +``` + ### `pay_invoice` Description: Requests payment of an invoice. @@ -88,19 +136,6 @@ Response: } ``` -### `balance` - -Description: Requests the balance of the wallet. - -Request: an empty JSON object. - -Response: -```jsonc -{ - "balance": 100000 // balance in msat, int -} -``` - ## 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. From de095e47580e63d91faf541e6a0c84ae5c0ca8fd Mon Sep 17 00:00:00 2001 From: kiwiidb <33457577+kiwiidb@users.noreply.github.com> Date: Thu, 27 Apr 2023 16:21:15 +0200 Subject: [PATCH 05/84] NIP-47: Implement feedback Co-authored-by: Semisol --- 47.md | 79 ++++++++++++++++++++--------------------------------------- 1 file changed, 27 insertions(+), 52 deletions(-) diff --git a/47.md b/47.md index fd85e133..083dabe2 100644 --- a/47.md +++ b/47.md @@ -17,19 +17,22 @@ This NIP describes a way for clients to access a remote Lightning wallet through ## Events -There are two event kinds: +There are three event kinds: +- `NIP-47 info event`: 13194 - `NIP-47 request`: 23194 - `NIP-47 response`: 23195 -Both the request and response events SHOULD only 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 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. -The content is encrypted with [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md), and is a JSON object. The content depends on the kind. +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: Request: ```jsonc { - "cmd": "pay_invoice", // command, string - "data": { // data, object + "method": "pay_invoice", // method, string + "params": { // params, object "invoice": "lnbc50n1..." // command-related data } } @@ -38,21 +41,26 @@ Request: Response: ```jsonc { - "status": "ok", // status, "ok" | "error" - "event": "0123456789abcdef...", // event the command is in response to, string - "data": { // response data + "result_type": "pay_invoice", //indicates the structure of the result field + "error": { //object, non-null in case of error + "code": "UNAUTHORIZED", //string error code, see below + "message": "human readable error message" + }, + "result": { // result, object. null in case of error. "preimage": "0123456789abcdef..." // command-related data } } ``` -The data field SHOULD contain a `message` field with a human readable error message and a `code` field with the error code if the status is `error`. +The `result_type` field MUST contain the name of the method that this event is responding to. +The `error` field MUST contain a `message` field with a human readable error message and a `code` field with the error code if the command was not succesful. +If the command was succesful, the `error` field must be null. ### Error codes - `RATE_LIMITED`: The client is sending commands too fast. It should retry in a few seconds. - `NOT_IMPLEMENTED`: The command is not known or is intentionally not implemented. - `INSUFFICIENT_BALANCE`: The wallet does not have enough funds to cover a fee reserve or the payment amount. -- `QUOTA_EXCEEDED`: The wallet has exceeded +- `QUOTA_EXCEEDED`: The wallet has exceeded its spending quota. - `RESTRICTED`: This public key is not allowed to do this operation. - `UNAUTHORIZED`: This public key has no wallet connected. - `INTERNAL`: An internal error. @@ -64,7 +72,7 @@ The data field SHOULD contain a `message` field with a human readable error mess The **wallet service** generates this connection URI with protocol `nostr+walletconnect:` and base path it's hex-encoded `pubkey` with the following query string parameters: - `relay` Required. URL of the relay where the **wallet service** is connected and will be listening for events. May be more than one. -- `secret` Required. 32-byte randomly generated hex encoded string. The **client** should use this to sign events when communicating with the **wallet service**. +- `secret` Required. 32-byte randomly generated hex encoded string. The **client** MUST use this to sign events and encrypt payloads when communicating with the **wallet service**. - Authorization does not require passing keys back and forth. - The user can have different keys for different applications. Keys can be revoked and created at will and have arbitrary constraints (eg. budgets). - The key is harder to leak since it is not shown to the user and backed up. @@ -79,45 +87,6 @@ nostr+walletconnect:b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558 ## Commands -### `get_info` - -Description: Get information about the wallet and service. - -Request: Empty object. - -Response: -```jsonc -{ - "balance": 100000, // balance in msat, int - // this should be capped at the quota allowed for this client - // to not report unspendable balance. - "implemented_commands": ["get_info", "pay_invoice"] // commands supported, string array - // extensions can be specified via command+extension: - // get_info+node_info -} -``` - -### `create_invoice` - -Description: Requests creation of an invoice. - -Request: -```jsonc -{ - "amount": 1000, // amount in msat, int - // must be a whole number of sats unless - // create_invoice+msat_amount is implemented. - "description": "memo" // a description, string, optional -} -``` - -Response: -```jsonc -{ - "invoice": "lnbc50n1..." // BOLT11 invoice, string -} -``` - ### `pay_invoice` Description: Requests payment of an invoice. @@ -125,14 +94,20 @@ Description: Requests payment of an invoice. Request: ```jsonc { - "invoice": "lnbc50n1..." // BOLT11 invoice, string + "method": "pay_invoice", + "params": { + "invoice": "lnbc50n1..." // bolt11 invoice + } } ``` Response: ```jsonc { - "preimage": "0123456789abcdef..." // preimage after payment, string + "result_type": "pay_invoice", + "result": { + "preimage": "0123456789abcdef..." // preimage of the payment + } } ``` From 5a8c463641b3dbaf927f7e0479ff046f0f6fb646 Mon Sep 17 00:00:00 2001 From: Semisol <45574030+Semisol@users.noreply.github.com> Date: Thu, 27 Apr 2023 17:24:20 +0300 Subject: [PATCH 06/84] NIP-47: Add error for payment failed --- 47.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/47.md b/47.md index 083dabe2..aa58b5c4 100644 --- a/47.md +++ b/47.md @@ -111,6 +111,9 @@ Response: } ``` +Errors: +- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar. + ## 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. From e91ce3409e1ce8267fc07a21784d2538621267c3 Mon Sep 17 00:00:00 2001 From: Alex Gleason Date: Sat, 29 Apr 2023 13:16:58 -0500 Subject: [PATCH 07/84] NIP-30: Custom Emoji --- 30.md | 56 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 1 + 2 files changed, 57 insertions(+) create mode 100644 30.md diff --git a/30.md b/30.md new file mode 100644 index 00000000..04689d0f --- /dev/null +++ b/30.md @@ -0,0 +1,56 @@ +NIP-30 +====== + +Custom Emoji +------------ + +`draft` `optional` `author:alexgleason` + +Custom emoji may be added to **kind 0** and **kind 1** events by including one or more `"emoji"` tags, in the form: + +``` +["emoji", , ] +``` + +Where: + +- `` is a name given for the emoji, which MUST be comprised of only alphanumeric characters. +- `` is a URL to the corresponding image file of the emoji. + +For each emoji tag, clients should parse emoji shortcodes (aka "emojify") like `:shortcode:` in the event to display custom emoji. + +Clients may allow users to add custom emoji to an event by including `:shortcode:` identifier in the event, and adding the relevant `"emoji"` tags. + +### Kind 0 events + +In kind 0 events, the `name` and `about` fields should be emojified. + +```json +{ + "kind": 0, + "content": "{\"name\":\"Alex Gleason :soapbox:\"}", + "tags": [ + ["emoji", "soapbox", "https://gleasonator.com/emoji/Gleasonator/soapbox.png"] + ], + "pubkey": "79c2cae114ea28a981e7559b4fe7854a473521a8d22a66bbab9fa248eb820ff6", + "created_at": 1682790000 +} +``` + +### Kind 1 events + +In kind 1 events, the `content` should be emojified. + +```json +{ + "kind": 1, + "content": "Hello :gleasonator: 😂 :ablobcatrainbow: :disputed: yolo", + "tags": [ + ["emoji", "ablobcatrainbow", "https://gleasonator.com/emoji/blobcat/ablobcatrainbow.png"], + ["emoji", "disputed", "https://gleasonator.com/emoji/Fun/disputed.png"], + ["emoji", "gleasonator", "https://gleasonator.com/emoji/Gleasonator/gleasonator.png"] + ], + "pubkey": "79c2cae114ea28a981e7559b4fe7854a473521a8d22a66bbab9fa248eb820ff6", + "created_at": 1682630000 +} +``` \ No newline at end of file diff --git a/README.md b/README.md index e7c89144..92be9a5a 100644 --- a/README.md +++ b/README.md @@ -45,6 +45,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/fia - [NIP-26: Delegated Event Signing](26.md) - [NIP-27: Text Note References](27.md) - [NIP-28: Public Chat](28.md) +- [NIP-30: Custom Emoji](30.md) - [NIP-33: Parameterized Replaceable Events](33.md) - [NIP-36: Sensitive Content](36.md) - [NIP-39: External Identities in Profiles](39.md) From 7f75d0db33435fe9fcb6c04f18d0e610b17cebb4 Mon Sep 17 00:00:00 2001 From: mplorentz Date: Mon, 1 May 2023 14:15:06 -0400 Subject: [PATCH 08/84] Change NIP-21 URL->URI I think the `nostr:...` scheme is not actually a Uniform Resource Locator, because it doesn't tell you where the data is located. For instance if I see the string `nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9` I understand that this identifies a Nostr keypair but I don't know where to find data for that keypair. The scheme does fall under the definition of a Uniform Resource Identifier, or maybe even the stricter class Uniform Resource Name. But nobody talks about URNs, so maybe best to just use the less-specific term "URI" here. --- 21.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/21.md b/21.md index bfbb3ae5..6246eb49 100644 --- a/21.md +++ b/21.md @@ -1,12 +1,12 @@ NIP-21 ====== -`nostr:` URL scheme +`nostr:` URI scheme ------------------- `draft` `optional` `author:fiatjaf` -This NIP standardizes the usage of a common URL scheme for maximum interoperability and openness in the network. +This NIP standardizes the usage of a common URI scheme for maximum interoperability and openness in the network. The scheme is `nostr:`. From d7c189d70bd1f9489a388920bc325576bd9cf8e4 Mon Sep 17 00:00:00 2001 From: "Robert C. Martin" Date: Tue, 2 May 2023 09:41:59 -0500 Subject: [PATCH 09/84] NIP11 example using curl. (#490) --- 11.md | 88 +++++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 58 insertions(+), 30 deletions(-) diff --git a/11.md b/11.md index a3773642..89518354 100644 --- a/11.md +++ b/11.md @@ -69,18 +69,18 @@ are rejected or fail immediately. ```json { ... - "limitation": { - "max_message_length": 16384, - "max_subscriptions": 20, - "max_filters": 100, - "max_limit": 5000, - "max_subid_length": 100, - "min_prefix": 4, - "max_event_tags": 100, - "max_content_length": 8196, - "min_pow_difficulty": 30, - "auth_required": true, - "payment_required": true, + limitation: { + max_message_length: 16384, + max_subscriptions: 20, + max_filters: 100, + max_limit: 5000, + max_subid_length: 100, + min_prefix: 4, + max_event_tags: 100, + max_content_length: 8196, + min_pow_difficulty: 30, + auth_required: true, + payment_required: true, } ... } @@ -141,11 +141,11 @@ all, and preferably an error will be provided when those are received. ```json { ... - "retention": [ - { "kinds": [0, 1, [5, 7], [40, 49]], "time": 3600 }, - { "kinds": [[40000, 49999]], "time": 100 }, - { "kinds": [[30000, 39999]], "count": 1000 }, - { "time": 3600, "count": 10000 } + retention: [ + { kinds: [0, 1, [5, 7], [40, 49]], time: 3600 }, + { kinds: [[40000, 49999], time: 100 }, + { kinds: [[30000, 39999], count: 1000 }, + { time: 3600, count: 10000 } ] ... } @@ -154,7 +154,7 @@ all, and preferably an error will be provided when those are received. `retention` is a list of specifications: each will apply to either all kinds, or a subset of kinds. Ranges may be specified for the kind field as a tuple of inclusive start and end values. Events of indicated kind (or all) are then limited to a `count` -and/or time period. +and or time period. It is possible to effectively blacklist Nostr-based protocols that rely on a specific `kind` number, by giving a retention time of zero for those `kind` values. @@ -175,8 +175,8 @@ It is not possible to describe the limitations of each country's laws and policies which themselves are typically vague and constantly shifting. Therefore, this field allows the relay operator to indicate which -countries' laws might end up being enforced on them, and then -indirectly on their users' content. +country's' laws might end up being enforced on them, and then +indirectly on their users's content. Users should be able to avoid relays in countries they don't like, and/or select relays in more favourable zones. Exposing this @@ -185,7 +185,7 @@ flexibility is up to the client software. ```json { ... - "relay_countries": [ "CA", "US" ], + relay_countries: [ 'CA', 'US' ], ... } ``` @@ -208,9 +208,9 @@ To support this goal, relays MAY specify some of the following values. ```json { ... - "language_tags": [ "en", "en-419" ], - "tags": [ "sfw-only", "bitcoin-only", "anime" ], - "posting_policy": "https://example.com/posting-policy.html", + language_tags: [ 'en', 'en-419' ], + tags: [ 'sfw-only', 'bitcoin-only', 'anime' ], + posting_policy: 'https://example.com/posting-policy.html', ... } ``` @@ -220,7 +220,7 @@ To support this goal, relays MAY specify some of the following values. the major languages spoken on the relay. - `tags` is a list of limitations on the topics to be discussed. - For example `sfw-only` indicates that only "Safe For Work" content + For example `sfw-only` indicates hat only "Safe For Work" content is encouraged on this relay. This relies on assumptions of what the "work" "community" feels "safe" talking about. In time, a common set of tags may emerge that allow users to find relays that suit @@ -245,12 +245,40 @@ Relays that require payments may want to expose their fee schedules. ```json { ... - "payments_url": "https://my-relay/payments", - "fees": { - "admission": [{ "amount": 1000000, "unit": "msats" }], - "subscription": [{ "amount": 5000000, "unit": "msats", "period": 2592000 }], - "publication": [{ "kinds": [4], "amount": 100, "unit": "msats" }], + payments_url: "https://my-relay/payments", + fees: { + "admission": [{ amount: 1000000, unit: 'msats' }], + "subscription": [{ amount: 5000000, unit: 'msats', period: 2592000 }], + "publication": [{ kinds: [4], amount: 100, unit: 'msats' }], }, ... } ``` + +### Examples ### +As of 2 May 2023 the following `curl` command provided these results. + + >curl -H "Accept: application/nostr+json" https://eden.nostr.land + + {"name":"eden.nostr.land", + "description":"Eden Nostr Land - Toronto 1-01", + "pubkey":"00000000827ffaa94bfea288c3dfce4422c794fbb96625b6b31e9049f729d700", + "contact":"me@ricardocabral.io", + "supported_nips":[1,2,4,9,11,12,15,16,20,22,26,28,33,40], + "supported_nip_extensions":["11a"], + "software":"git+https://github.com/Cameri/nostream.git", + "version":"1.22.6", + "limitation":{"max_message_length":1048576, + "max_subscriptions":10, + "max_filters":2500, + "max_limit":5000, + "max_subid_length":256, + "min_prefix":4, + "max_event_tags":2500, + "max_content_length":65536, + "min_pow_difficulty":0, + "auth_required":false, + "payment_required":true}, + "payments_url":"https://eden.nostr.land/invoices", + "fees":{"admission":[{"amount":5000000,"unit":"msats"}], + "publication":[]}} From bc9d469c203a25a706727219fa7d37dacaf6040d Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Fri, 5 May 2023 08:50:50 -0300 Subject: [PATCH 10/84] add nip-47 to index. --- README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/README.md b/README.md index e7c89144..a4a63a4a 100644 --- a/README.md +++ b/README.md @@ -52,6 +52,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/fia - [NIP-42: Authentication of clients to relays](42.md) - [NIP-45: Counting results](45.md) - [NIP-46: Nostr Connect](46.md) +- [NIP-47: Wallet Connect](47.md) - [NIP-50: Keywords filter](50.md) - [NIP-51: Lists](51.md) - [NIP-56: Reporting](56.md) @@ -86,7 +87,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/fia | `10000` | Mute List | [51](51.md) | | `10001` | Pin List | [51](51.md) | | `10002` | Relay List Metadata | [65](65.md) | +| `13194` | Wallet Info | [47](47.md) | | `22242` | Client Authentication | [42](42.md) | +| `23194` | Wallet Request | [47](47.md) | +| `23195` | Wallet Response | [47](47.md) | | `24133` | Nostr Connect | [46](46.md) | | `30000` | Categorized People List | [51](51.md) | | `30001` | Categorized Bookmark List | [51](51.md) | From b8aec7dad561a8b27e22a91638dd04f2851a0c5c Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Fri, 5 May 2023 09:18:02 -0300 Subject: [PATCH 11/84] nip-31: dealing with custom unknown events. --- 31.md | 13 +++++++++++++ README.md | 1 + 2 files changed, 14 insertions(+) create mode 100644 31.md diff --git a/31.md b/31.md new file mode 100644 index 00000000..675c2496 --- /dev/null +++ b/31.md @@ -0,0 +1,13 @@ +NIP-31 +====== + +Dealing with unknown event kinds +-------------------------------- + +`draft` `optional` `author:pablof7z` `author:fiatjaf` + +When creating a new custom event kind that is part of a custom protocol and isn't meant to be read as text (like `kind:1`), clients should use the `tags` field to store all their custom data related to their protocol, and use the `content` field to write a short human-readable plaintext summary of what that event is about. + +The intent is that social clients, used to display only `kind:1` notes, can still show something in case a custom event pops up in their timelines. + +These clients that only know `kind:1` are not expected to ask relays for events of different kinds, but users could still reference these weird events on their notes, and without proper context these could be nonsensical notes. Having the fallback text makes that situation much better -- even if only for making the user aware that they should try to view that custom event elsewhere. diff --git a/README.md b/README.md index a4a63a4a..f3ae5016 100644 --- a/README.md +++ b/README.md @@ -45,6 +45,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/fia - [NIP-26: Delegated Event Signing](26.md) - [NIP-27: Text Note References](27.md) - [NIP-28: Public Chat](28.md) +- [NIP-31: Dealing with Unknown Events](31.md) - [NIP-33: Parameterized Replaceable Events](33.md) - [NIP-36: Sensitive Content](36.md) - [NIP-39: External Identities in Profiles](39.md) From d5484a33bcaf717ef1ef54a0f9be1b76c4f70afa Mon Sep 17 00:00:00 2001 From: Jon Staab Date: Sat, 6 May 2023 11:35:21 -0700 Subject: [PATCH 12/84] Clarify how NIP 45 works with multiple COUNT filters. (#504) --- 45.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/45.md b/45.md index 87e80002..a5253913 100644 --- a/45.md +++ b/45.md @@ -6,21 +6,21 @@ Event Counts `draft` `optional` `author:staab` -Relays may support the `COUNT` verb, which provides a mechanism for obtaining event counts. +Relays may support the verb `COUNT`, which provides a mechanism for obtaining event counts. ## Motivation -Some queries a client may want to execute against connected relays are prohibitively expensive, for example, in order to retrieve follower counts for a given pubkey, a client must query all kind-3 events referring to a given pubkey and count them. The result may be cached, either by a client or by a separate indexing server as an alternative, but both options erode the decentralization of the network by creating a second-layer protocol on top of Nostr. +Some queries a client may want to execute against connected relays are prohibitively expensive, for example, in order to retrieve follower counts for a given pubkey, a client must query all kind-3 events referring to a given pubkey only to count them. The result may be cached, either by a client or by a separate indexing server as an alternative, but both options erode the decentralization of the network by creating a second-layer protocol on top of Nostr. ## Filters and return values -This NIP defines a verb called `COUNT`, which accepts a subscription id and filters as specified in [NIP 01](01.md). +This NIP defines the verb `COUNT`, which accepts a subscription id and filters as specified in [NIP 01](01.md) for the verb `REQ`. Multiple filters are OR'd together and aggregated into a single count result. ``` ["COUNT", , ...] ``` -Counts are returned using a `COUNT` response in the form `{count: }`. Relays may use probabilistic counts to reduce compute requirements. +Counts are returned using a `COUNT` response in the form `{"count": }`. Relays may use probabilistic counts to reduce compute requirements. ``` ["COUNT", , {"count": }] From 1678c53dcd3a2cefcf953722d501c03920ce6092 Mon Sep 17 00:00:00 2001 From: ekzyis Date: Sat, 6 May 2023 23:31:22 +0200 Subject: [PATCH 13/84] Update old link to fiatjaf/nostr --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index a4a63a4a..94e945c5 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,7 @@ # NIPs 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. +They exist to document what may be implemented by [Nostr](https://github.com/nostr-protocol/nostr)-compatible _relay_ and _client_ software. --- From 29f26e72b5fd4e918c8d0d9f9d9ae384f7052a0a Mon Sep 17 00:00:00 2001 From: Kieran Date: Mon, 24 Apr 2023 10:32:03 +0100 Subject: [PATCH 14/84] NIP-98 --- 98.md | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 98.md diff --git a/98.md b/98.md new file mode 100644 index 00000000..48d079e9 --- /dev/null +++ b/98.md @@ -0,0 +1,64 @@ +NIP-98 +====== + +HTTP Auth +------------------------- + +`draft` `optional` `author:kieran` `author:melvincarvalho` + +This NIP defines and ephemerial event used to authenticate requests to HTTP servers using nostr events. + +This is useful for HTTP services which are build for Nostr and deal with Nostr user accounts. + +## Nostr event + +A `kind 27235` (In reference to [RFC 7235](https://www.rfc-editor.org/rfc/rfc7235)) event is used. + +The `content` SHOULD be empty. + +The following tags are defined as REQUIRED. + +* `url` - absolute URL +* `method` - HTTP Request Method + +Example event: +```json +{ + "id": "fe964e758903360f28d8424d092da8494ed207cba823110be3a57dfe4b578734", + "pubkey": "63fe6318dc58583cfe16810f86dd09e18bfd76aabc24a0081ce2856f330504ed", + "content": "", + "kind": 27235, + "created_at": 1682327852, + "tags": [ + [ + "url", + "https://api.snort.social/api/v1/n5sp/list" + ], + [ + "method", + "GET" + ] + ], + "sig": "5ed9d8ec958bc854f997bdc24ac337d005af372324747efe4a00e24f4c30437ff4dd8308684bed467d9d6be3e5a517bb43b1732cc7d33949a3aaf86705c22184" +} +``` + +Servers MUST perform the following checks in order to validate the event: +1. The `kind` MUST be `27235`. +2. The `created_at` MUST be within a reasonable time window (suggestion 60 seconds). +3. The `url` tag MUST be exactly the same as the absolute request URL (including query parameters). +4. The `method` tag MUST be the same HTTP method used for the requested resource. + +All other checks which server MAY do are OPTIONAL, and implementation specific. + +## Request Flow + +Using the `Authorization` header, the `kind 27235` event MUST be `base64` encoded and use the Authorization scheme `Nostr` + +Example HTTP Authorization header: +``` +Authorization: Nostr eyJpZCI6ImZlOTY0ZTc1ODkwMzM2MGYyOGQ4NDI0ZDA5MmRhODQ5NGVkMjA3Y2JhODIzMTEwYmUzYTU3ZGZlNGI1Nzg3MzQiLCJwdWJrZXkiOiI2M2ZlNjMxOGRjNTg1ODNjZmUxNjgxMGY4NmRkMDllMThiZmQ3NmFhYmMyNGEwMDgxY2UyODU2ZjMzMDUwNGVkIiwiY29udGVudCI6IiIsImtpbmQiOjI3MjM1LCJjcmVhdGVkX2F0IjoxNjgyMzI3ODUyLCJ0YWdzIjpbWyJ1cmwiLCJodHRwczovL2FwaS5zbm9ydC5zb2NpYWwvYXBpL3YxL241c3AvbGlzdCJdLFsibWV0aG9kIiwiR0VUIl1dLCJzaWciOiI1ZWQ5ZDhlYzk1OGJjODU0Zjk5N2JkYzI0YWMzMzdkMDA1YWYzNzIzMjQ3NDdlZmU0YTAwZTI0ZjRjMzA0MzdmZjRkZDgzMDg2ODRiZWQ0NjdkOWQ2YmUzZTVhNTE3YmI0M2IxNzMyY2M3ZDMzOTQ5YTNhYWY4NjcwNWMyMjE4NCJ9 +``` + +## References +- C# ASP.NET `AuthenticationHandler` [NostrAuth.cs](https://gist.github.com/v0l/74346ae530896115bfe2504c8cd018d3) \ No newline at end of file From 2d31ddd38a133584a2eea58fdbe106452999cce3 Mon Sep 17 00:00:00 2001 From: Kieran Date: Mon, 24 Apr 2023 10:56:04 +0100 Subject: [PATCH 15/84] add note about payload hash --- 98.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/98.md b/98.md index 48d079e9..3a8ffdf2 100644 --- a/98.md +++ b/98.md @@ -18,8 +18,8 @@ The `content` SHOULD be empty. The following tags are defined as REQUIRED. -* `url` - absolute URL -* `method` - HTTP Request Method +* `u` - absolute URL +* `method` - HTTP Request Method Example event: ```json @@ -31,7 +31,7 @@ Example event: "created_at": 1682327852, "tags": [ [ - "url", + "u", "https://api.snort.social/api/v1/n5sp/list" ], [ @@ -49,6 +49,10 @@ Servers MUST perform the following checks in order to validate the event: 3. The `url` tag MUST be exactly the same as the absolute request URL (including query parameters). 4. The `method` tag MUST be the same HTTP method used for the requested resource. +When the request contains a body (as in POST/PUT/PATCH methods) clients SHOULD include a SHA256 hash of the request body in a `payload` tag as hex (`["payload", ""]`), servers MAY check this to validate that the requested payload is authorized. + +If one of the checks was to fail the server SHOULD respond with a 401 Unauthorized response code. + All other checks which server MAY do are OPTIONAL, and implementation specific. ## Request Flow From 30620c8e542b398f58f69426736a01d9aaa79452 Mon Sep 17 00:00:00 2001 From: Kieran Date: Mon, 24 Apr 2023 11:22:47 +0100 Subject: [PATCH 16/84] Update readme --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 94e945c5..9714fc98 100644 --- a/README.md +++ b/README.md @@ -61,6 +61,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos - [NIP-65: Relay List Metadata](65.md) - [NIP-78: Application-specific data](78.md) - [NIP-94: File Metadata](94.md) +- [NIP-98: HTTP Auth](98.md) ## Event Kinds @@ -92,6 +93,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `23194` | Wallet Request | [47](47.md) | | `23195` | Wallet Response | [47](47.md) | | `24133` | Nostr Connect | [46](46.md) | +| `27235` | HTTP Auth | [98](98.md) | | `30000` | Categorized People List | [51](51.md) | | `30001` | Categorized Bookmark List | [51](51.md) | | `30008` | Profile Badges | [58](58.md) | From f75d91551cea5af89a572c123615db1cf9033caf Mon Sep 17 00:00:00 2001 From: Kieran Date: Mon, 24 Apr 2023 11:24:47 +0100 Subject: [PATCH 17/84] typo --- 98.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/98.md b/98.md index 3a8ffdf2..e3732169 100644 --- a/98.md +++ b/98.md @@ -6,7 +6,7 @@ HTTP Auth `draft` `optional` `author:kieran` `author:melvincarvalho` -This NIP defines and ephemerial event used to authenticate requests to HTTP servers using nostr events. +This NIP defines an ephemerial event used to authorize requests to HTTP servers using nostr events. This is useful for HTTP services which are build for Nostr and deal with Nostr user accounts. From de1aec64d21415c2f96fce6694de294c282ce128 Mon Sep 17 00:00:00 2001 From: Kieran Date: Mon, 8 May 2023 12:21:30 +0100 Subject: [PATCH 18/84] change references title --- 98.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/98.md b/98.md index e3732169..1ccd2611 100644 --- a/98.md +++ b/98.md @@ -64,5 +64,5 @@ Example HTTP Authorization header: Authorization: Nostr eyJpZCI6ImZlOTY0ZTc1ODkwMzM2MGYyOGQ4NDI0ZDA5MmRhODQ5NGVkMjA3Y2JhODIzMTEwYmUzYTU3ZGZlNGI1Nzg3MzQiLCJwdWJrZXkiOiI2M2ZlNjMxOGRjNTg1ODNjZmUxNjgxMGY4NmRkMDllMThiZmQ3NmFhYmMyNGEwMDgxY2UyODU2ZjMzMDUwNGVkIiwiY29udGVudCI6IiIsImtpbmQiOjI3MjM1LCJjcmVhdGVkX2F0IjoxNjgyMzI3ODUyLCJ0YWdzIjpbWyJ1cmwiLCJodHRwczovL2FwaS5zbm9ydC5zb2NpYWwvYXBpL3YxL241c3AvbGlzdCJdLFsibWV0aG9kIiwiR0VUIl1dLCJzaWciOiI1ZWQ5ZDhlYzk1OGJjODU0Zjk5N2JkYzI0YWMzMzdkMDA1YWYzNzIzMjQ3NDdlZmU0YTAwZTI0ZjRjMzA0MzdmZjRkZDgzMDg2ODRiZWQ0NjdkOWQ2YmUzZTVhNTE3YmI0M2IxNzMyY2M3ZDMzOTQ5YTNhYWY4NjcwNWMyMjE4NCJ9 ``` -## References +## Reference Implementations - C# ASP.NET `AuthenticationHandler` [NostrAuth.cs](https://gist.github.com/v0l/74346ae530896115bfe2504c8cd018d3) \ No newline at end of file From ee018ef8a4af08dcf8f4c090bb3815ee13f4c627 Mon Sep 17 00:00:00 2001 From: Josua Schmid Date: Sun, 7 May 2023 21:53:35 +0200 Subject: [PATCH 19/84] Rephrase Markdown special rule --- 01.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/01.md b/01.md index a07a0dff..3d8c7450 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. From 89a7aa0ea0197b478e96d2a281ac4d096c44caad Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Mon, 8 May 2023 11:05:58 -0300 Subject: [PATCH 20/84] nip01: remove misleading markdown example. --- 01.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/01.md b/01.md index 3d8c7450..713e6550 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. From d70aa87f076f8609950fc96e4e66d86c711c66ac Mon Sep 17 00:00:00 2001 From: Asai Toshiya Date: Tue, 9 May 2023 22:09:45 +0900 Subject: [PATCH 21/84] Restore some lost changes c7711aa and 3cec80d. --- 11.md | 60 +++++++++++++++++++++++++++++------------------------------ 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/11.md b/11.md index 89518354..b0d6003f 100644 --- a/11.md +++ b/11.md @@ -69,18 +69,18 @@ are rejected or fail immediately. ```json { ... - limitation: { - max_message_length: 16384, - max_subscriptions: 20, - max_filters: 100, - max_limit: 5000, - max_subid_length: 100, - min_prefix: 4, - max_event_tags: 100, - max_content_length: 8196, - min_pow_difficulty: 30, - auth_required: true, - payment_required: true, + "limitation": { + "max_message_length": 16384, + "max_subscriptions": 20, + "max_filters": 100, + "max_limit": 5000, + "max_subid_length": 100, + "min_prefix": 4, + "max_event_tags": 100, + "max_content_length": 8196, + "min_pow_difficulty": 30, + "auth_required": true, + "payment_required": true, } ... } @@ -141,11 +141,11 @@ all, and preferably an error will be provided when those are received. ```json { ... - retention: [ - { kinds: [0, 1, [5, 7], [40, 49]], time: 3600 }, - { kinds: [[40000, 49999], time: 100 }, - { kinds: [[30000, 39999], count: 1000 }, - { time: 3600, count: 10000 } + "retention": [ + { "kinds": [0, 1, [5, 7], [40, 49]], "time": 3600 }, + { "kinds": [[40000, 49999]], "time": 100 }, + { "kinds": [[30000, 39999]], "count": 1000 }, + { "time": 3600, "count": 10000 } ] ... } @@ -154,7 +154,7 @@ all, and preferably an error will be provided when those are received. `retention` is a list of specifications: each will apply to either all kinds, or a subset of kinds. Ranges may be specified for the kind field as a tuple of inclusive start and end values. Events of indicated kind (or all) are then limited to a `count` -and or time period. +and/or time period. It is possible to effectively blacklist Nostr-based protocols that rely on a specific `kind` number, by giving a retention time of zero for those `kind` values. @@ -175,8 +175,8 @@ It is not possible to describe the limitations of each country's laws and policies which themselves are typically vague and constantly shifting. Therefore, this field allows the relay operator to indicate which -country's' laws might end up being enforced on them, and then -indirectly on their users's content. +countries' laws might end up being enforced on them, and then +indirectly on their users' content. Users should be able to avoid relays in countries they don't like, and/or select relays in more favourable zones. Exposing this @@ -185,7 +185,7 @@ flexibility is up to the client software. ```json { ... - relay_countries: [ 'CA', 'US' ], + "relay_countries": [ "CA", "US" ], ... } ``` @@ -208,9 +208,9 @@ To support this goal, relays MAY specify some of the following values. ```json { ... - language_tags: [ 'en', 'en-419' ], - tags: [ 'sfw-only', 'bitcoin-only', 'anime' ], - posting_policy: 'https://example.com/posting-policy.html', + "language_tags": [ "en", "en-419" ], + "tags": [ "sfw-only", "bitcoin-only", "anime" ], + "posting_policy": "https://example.com/posting-policy.html", ... } ``` @@ -220,7 +220,7 @@ To support this goal, relays MAY specify some of the following values. the major languages spoken on the relay. - `tags` is a list of limitations on the topics to be discussed. - For example `sfw-only` indicates hat only "Safe For Work" content + For example `sfw-only` indicates that only "Safe For Work" content is encouraged on this relay. This relies on assumptions of what the "work" "community" feels "safe" talking about. In time, a common set of tags may emerge that allow users to find relays that suit @@ -245,11 +245,11 @@ Relays that require payments may want to expose their fee schedules. ```json { ... - payments_url: "https://my-relay/payments", - fees: { - "admission": [{ amount: 1000000, unit: 'msats' }], - "subscription": [{ amount: 5000000, unit: 'msats', period: 2592000 }], - "publication": [{ kinds: [4], amount: 100, unit: 'msats' }], + "payments_url": "https://my-relay/payments", + "fees": { + "admission": [{ "amount": 1000000, "unit": "msats" }], + "subscription": [{ "amount": 5000000, "unit": "msats", "period": 2592000 }], + "publication": [{ "kinds": [4], "amount": 100, "unit": "msats" }], }, ... } From 60aa6ae168e8d71e4fd247e49f8ba70fbe511fda Mon Sep 17 00:00:00 2001 From: "Robert C. Martin" Date: Tue, 9 May 2023 10:17:15 -0500 Subject: [PATCH 22/84] A few changes to some nips. (#510) --- 01.md | 1 + 47.md | 19 +++++++++++++++---- 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/01.md b/01.md index 713e6550..e36f4f5d 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 aa58b5c4..fe3d5756 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. From 4208652dc7a39c63c39559b13c656ec30400fcba Mon Sep 17 00:00:00 2001 From: William Casarin Date: Tue, 9 May 2023 15:02:14 -0700 Subject: [PATCH 23/84] nip47: add lud16 parameter to connection string This adds an optional but recommended lud16 parameter to nostr wallet connection strings. This enables seamless onboarding of new users, allowing clients to automatically configure the receive address for zaps. --- 47.md | 1 + 1 file changed, 1 insertion(+) diff --git a/47.md b/47.md index fe3d5756..c884b978 100644 --- a/47.md +++ b/47.md @@ -88,6 +88,7 @@ The **wallet service** generates this connection URI with protocol `nostr+wallet - The user can have different keys for different applications. Keys can be revoked and created at will and have arbitrary constraints (eg. budgets). - The key is harder to leak since it is not shown to the user and backed up. - It improves privacy because the user's main key would not be linked to their payments. +- `lud16` Recommended. A lightning address that clients can use to automatically setup the `lud16` field on the user's profile if they have none configured. The **client** should then store this connection and use it when the user wants to perform actions like paying an invoice. Due to this NIP using ephemeral events, it is recommended to pick relays that do not close connections on inactivity to not drop events. From 4cbb672d1cf6e0af2b4c09c9b33e97f7964ce36e Mon Sep 17 00:00:00 2001 From: earonesty Date: Sat, 13 May 2023 07:39:01 -0700 Subject: [PATCH 24/84] Fix docs from kind0 to kind33 https://github.com/nostr-protocol/nips/issues/376 --- 28.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/28.md b/28.md index 169ae4f4..9f9302f1 100644 --- a/28.md +++ b/28.md @@ -37,7 +37,7 @@ In the channel creation `content` field, Client SHOULD include basic channel met Update a channel's public metadata. -Clients and relays SHOULD handle kind 41 events similar to kind 0 `metadata` events. +Clients and relays SHOULD handle kind 41 events similar to kind 33 replaceable events, where the information is used to update the metadata, without modifying the event id for the channel. Clients SHOULD ignore kind 41s from pubkeys other than the kind 40 pubkey. From 26194822005836a8ce690009fc636e0fe71802e6 Mon Sep 17 00:00:00 2001 From: earonesty Date: Sat, 13 May 2023 07:42:40 -0700 Subject: [PATCH 25/84] More explicit --- 28.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/28.md b/28.md index 9f9302f1..62ab398f 100644 --- a/28.md +++ b/28.md @@ -37,7 +37,7 @@ In the channel creation `content` field, Client SHOULD include basic channel met Update a channel's public metadata. -Clients and relays SHOULD handle kind 41 events similar to kind 33 replaceable events, where the information is used to update the metadata, without modifying the event id for the channel. +Clients and relays SHOULD handle kind 41 events similar to kind 33 replaceable events, where the information is used to update the metadata, without modifying the event id for the channel. Only the most recent kind 41 is needed to be stored. Clients SHOULD ignore kind 41s from pubkeys other than the kind 40 pubkey. From 64ac0710dea1af432051ef70698979bff106b9c2 Mon Sep 17 00:00:00 2001 From: jiftechnify Date: Sun, 14 May 2023 11:55:07 +0900 Subject: [PATCH 26/84] zap note -> zap receipt --- 57.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/57.md b/57.md index 17042ea4..538d7275 100644 --- a/57.md +++ b/57.md @@ -20,7 +20,7 @@ Having lightning receipts on nostr allows clients to display lightning payments 6. If the request is valid, the server should fetch a description hash invoice where the description is this note and this note only. No additional lnurl metadata is included in the description. This will be returned in the response according to [LUD06](https://github.com/lnurl/luds/blob/luds/06.md). 7. On receiving the invoice, the client MAY pay it or pass it to an app that can pay the invoice. 8. Once the invoice is paid, the recipient's lnurl server MUST generate a `zap receipt` as described in Appendix E, and publish it to the `relays` specified in the `zap request`. -9. Clients MAY fetch zap notes on posts and profiles, but MUST authorize their validity as described in Appendix F. 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. +9. Clients MAY fetch `zap receipt`s on posts and profiles, but MUST authorize their validity as described in Appendix F. 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 receipt` to show "zap authorized by ..." but this is optional. ## Reference and examples @@ -108,7 +108,7 @@ When a client sends a zap request event to a server's lnurl-pay callback URL, th 2. It MUST have tags 3. It MUST have only one `p` tag 4. It MUST have 0 or 1 `e` tags -5. There should be a `relays` tag with the relays to send the `zap` note to. +5. There should be a `relays` tag with the relays to send the `zap receipt` to. 6. If there is an `amount` tag, it MUST be equal to the `amount` query parameter. 7. If there is an `a` tag, it MUST be a valid NIP-33 event coordinate From 9076b8486da293f56e725ec593fcfb09a7bc2edf Mon Sep 17 00:00:00 2001 From: jiftechnify Date: Sun, 14 May 2023 12:04:47 +0900 Subject: [PATCH 27/84] fix inconsistent quoting of zap request / receipt --- 57.md | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/57.md b/57.md index 538d7275..54141358 100644 --- a/57.md +++ b/57.md @@ -6,21 +6,21 @@ Lightning Zaps `draft` `optional` `author:jb55` `author:kieran` -This NIP defines two new event types for recording lightning payments between users. `9734` is a `zap request`, representing a payer's request to a recipient's lightning wallet for an invoice. `9735` is a `zap receipt`, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a zap request has been paid. +This NIP defines two new event types for recording lightning payments between users. `9734` is a `zap request`, representing a payer's request to a recipient's lightning wallet for an invoice. `9735` is a `zap receipt`, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a `zap request` has been paid. 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. ## Protocol flow 1. Client calculates a recipient's lnurl pay request url from the `zap` tag on the event being zapped (see Appendix G), or by decoding their lud06 or lud16 field on their profile according to the [lnurl specifications](https://github.com/lnurl/luds). The client MUST send a GET request to this url and parse the response. If `allowsNostr` exists and it is `true`, and if `nostrPubkey` exists and is a valid BIP 340 public key in hex, the client should associate this information with the user, along with the response's `callback`, `minSendable`, and `maxSendable` values. -2. Clients may choose to display a lightning zap button on each post or on a user's profile. If the user's lnurl pay request endpoint supports nostr, the client SHOULD use this NIP to request a zap receipt rather than a normal lnurl invoice. +2. Clients may choose to display a lightning zap button on each post or on a user's profile. If the user's lnurl pay request endpoint supports nostr, the client SHOULD use this NIP to request a `zap receipt` rather than a normal lnurl invoice. 3. When a user (the "sender") indicates they want to send a zap to another user (the "recipient"), the client should create a `zap request` event as described in Appendix A of this NIP and sign it. 4. Instead of publishing the `zap request`, the `9734` event should instead be sent to the `callback` url received from the lnurl pay endpoint for the recipient using a GET request. See Appendix B for details and an example. -5. The recipient's lnurl server will receive this request and validate it. See Appendix C for details on how to properly configure an lnurl server to support zaps, and Appendix D for details on how to validate the `nostr` query parameter. -6. If the request is valid, the server should fetch a description hash invoice where the description is this note and this note only. No additional lnurl metadata is included in the description. This will be returned in the response according to [LUD06](https://github.com/lnurl/luds/blob/luds/06.md). +5. The recipient's lnurl server will receive this `zap request` and validate it. See Appendix C for details on how to properly configure an lnurl server to support zaps, and Appendix D for details on how to validate the `nostr` query parameter. +6. If the `zap request` is valid, the server should fetch a description hash invoice where the description is this `zap request` note and this note only. No additional lnurl metadata is included in the description. This will be returned in the response according to [LUD06](https://github.com/lnurl/luds/blob/luds/06.md). 7. On receiving the invoice, the client MAY pay it or pass it to an app that can pay the invoice. 8. Once the invoice is paid, the recipient's lnurl server MUST generate a `zap receipt` as described in Appendix E, and publish it to the `relays` specified in the `zap request`. -9. Clients MAY fetch `zap receipt`s on posts and profiles, but MUST authorize their validity as described in Appendix F. 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 receipt` to show "zap authorized by ..." but this is optional. +9. Clients MAY fetch `zap receipt`s on posts and profiles, but MUST authorize their validity as described in Appendix F. 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 receipt` to show "zap authorized by ..." but this is optional. ## Reference and examples @@ -60,10 +60,10 @@ Example: ### Appendix B: Zap Request HTTP Request -A signed zap request event is not published, but is instead sent using a HTTP GET request to the recipient's `callback` url, which was provided by the recipient's lnurl pay endpoint. This request should have the following query parameters defined: +A signed `zap request` event is not published, but is instead sent using a HTTP GET request to the recipient's `callback` url, which was provided by the recipient's lnurl pay endpoint. This request should have the following query parameters defined: - `amount` is the amount in _millisats_ the sender intends to pay -- `nostr` is the `9734` zap request event, JSON encoded then URI encoded +- `nostr` is the `9734` `zap request` event, JSON encoded then URI encoded - `lnurl` is the lnurl pay url of the recipient, encoded using bech32 with the prefix `lnurl` This request should return a JSON response with a `pr` key, which is the invoice the sender must pay to finalize his zap. Here is an example flow: @@ -97,12 +97,12 @@ const {pr: invoice} = await fetchJson(`${callback}?amount=${amount}&nostr=${even 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/`, where `nostrPubkey` is the nostr pubkey your server will use to sign `zap receipt` events. Clients will use this to validate zap receipts. +1. Add a `nostrPubkey` to the lnurl-pay static endpoint `/.well-known/lnurlp/`, where `nostrPubkey` is the nostr pubkey your server will use to sign `zap receipt` events. Clients will use this to validate `zap receipt`s. 2. Add an `allowsNostr` field and set it to true. ### Appendix D: LNURL Server Zap Request Validation -When a client sends a zap request event to a server's lnurl-pay callback URL, there will be a `nostr` query parameter where the contents of the event are URI- and JSON-encoded. If present, the zap request event must be validated in the following ways: +When a client sends a `zap request` event to a server's lnurl-pay callback URL, there will be a `nostr` query parameter where the contents of the event are URI- and JSON-encoded. If present, the `zap request` event must be validated in the following ways: 1. It MUST have a valid nostr signature 2. It MUST have tags @@ -116,29 +116,29 @@ The event MUST then be stored for use later, when the invoice is paid. ### Appendix E: Zap Receipt Event -A `zap receipt` is created by a lightning node when an invoice generated by a `zap request` is paid. Zap receipts are only created when the invoice description (committed to the description hash) contains a zap request note. +A `zap receipt` is created by a lightning node when an invoice generated by a `zap request` is paid. `Zap receipt`s are only created when the invoice description (committed to the description hash) contains a `zap request` 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 event. This SHOULD be validated based on the requirements in Appendix D, either when it is received, or before the invoice is paid. -3. Create a nostr event of kind `9735` as described below, and publish it to the `relays` declared in the zap request. +3. Create a nostr event of kind `9735` as described below, and publish it to the `relays` declared in the `zap request`. -The following should be true of the zap receipt event: +The following should be true of the `zap receipt` event: - The content SHOULD be empty. - The `created_at` date SHOULD be set to the invoice `paid_at` date for idempotency. -- `tags` MUST include the `p` tag AND optional `e` tag from the zap request. -- The zap receipt MUST have a `bolt11` tag containing the description hash bolt11 invoice. -- The zap receipt MUST contain a `description` tag which is the JSON-encoded invoice description. +- `tags` MUST include the `p` tag AND optional `e` tag from the `zap request`. +- The `zap receipt` MUST have a `bolt11` tag containing the description hash bolt11 invoice. +- The `zap receipt` MUST contain a `description` tag which is the JSON-encoded invoice description. - `SHA256(description)` MUST match the description hash in the bolt11 invoice. -- The zap receipt MAY contain a `preimage` tag 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 receipt for the legitimacy of the payment. +- The `zap receipt` MAY contain a `preimage` tag 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 receipt` for the legitimacy of the payment. -The zap receipt is not a proof of payment, all it proves is that some nostr user fetched an invoice. The existence of the zap receipt implies the invoice as paid, but it could be a lie given a rogue implementation. +The `zap receipt` is not a proof of payment, all it proves is that some nostr user fetched an invoice. The existence of the `zap receipt` implies the invoice as paid, but it could be a lie given a rogue implementation. A reference implementation for a zap-enabled lnurl server can be found [here](https://github.com/jb55/cln-nostr-zapper). -Example zap receipt: +Example `zap receipt`: ```json { @@ -160,7 +160,7 @@ Example zap receipt: ### Appendix F: Validating Zap Receipts -A client can retrieve `zap receipts` on events and pubkeys using a NIP-01 filter, for example `{"kinds": [9735], "#e": [...]}`. Zaps MUST be validated using the following steps: +A client can retrieve `zap receipt`s on events and pubkeys using a NIP-01 filter, for example `{"kinds": [9735], "#e": [...]}`. Zaps MUST be validated using the following steps: - The `zap receipt` event's `pubkey` MUST be the same as the recipient's lnurl provider's `nostrPubkey` (retrieved in step 1 of the protocol flow). - The `invoiceAmount` contained in the `bolt11` tag of the `zap receipt` MUST equal the `amount` tag of the `zap request` (if present). @@ -180,4 +180,4 @@ When an event includes a `zap` tag, clients SHOULD calculate the lnurl pay reque ## 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. +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. From 89e3c01b1438cedfb8d1ebbed3e320b8a6f3a582 Mon Sep 17 00:00:00 2001 From: jiftechnify Date: Sun, 14 May 2023 13:16:10 +0900 Subject: [PATCH 28/84] fix description of nostr query param --- 57.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/57.md b/57.md index 54141358..cb1f126c 100644 --- a/57.md +++ b/57.md @@ -102,7 +102,7 @@ The lnurl server will need some additional pieces of information so that clients ### Appendix D: LNURL Server Zap Request Validation -When a client sends a `zap request` event to a server's lnurl-pay callback URL, there will be a `nostr` query parameter where the contents of the event are URI- and JSON-encoded. If present, the `zap request` event must be validated in the following ways: +When a client sends a `zap request` event to a server's lnurl-pay callback URL, there will be a `nostr` query parameter whose value is that event which is URI- and JSON-encoded. If present, the `zap request` event must be validated in the following ways: 1. It MUST have a valid nostr signature 2. It MUST have tags From 4ea0e8e9f276c03e298f466fb3074342f0ec01c3 Mon Sep 17 00:00:00 2001 From: Neil Date: Mon, 15 May 2023 09:30:27 -0700 Subject: [PATCH 29/84] Add new signing extension to NIP-07 --- 07.md | 1 + 1 file changed, 1 insertion(+) diff --git a/07.md b/07.md index 3b7a1d29..2a31f716 100644 --- a/07.md +++ b/07.md @@ -30,3 +30,4 @@ async window.nostr.nip04.decrypt(pubkey, ciphertext): string // takes ciphertext - [Blockcore](https://www.blockcore.net/wallet) (Chrome and derivatives) - [nos2x-fox](https://diegogurpegui.com/nos2x-fox/) (Firefox) - [Flamingo](https://www.getflamingo.org/) (Chrome and derivatives) +- [AKA Profiles](https://github.com/neilck/aka-extension) (Chrome, stores multiple keys) From d9caf9d7b4ca5c3341b1262d5460a2e23630da5c Mon Sep 17 00:00:00 2001 From: jimbojw Date: Mon, 15 May 2023 08:15:53 -0400 Subject: [PATCH 30/84] fix: Updating links in NIP-15 to point to intended other NIPs. --- 15.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/15.md b/15.md index 617c0115..f8df3284 100644 --- a/15.md +++ b/15.md @@ -38,8 +38,8 @@ A merchant can publish these events: | `0 ` | `set_meta` | The merchant description (similar with any `nostr` public key). | [NIP01 ](https://github.com/nostr-protocol/nips/blob/master/01.md) | | `30017` | `set_stall` | Create or update a stall. | [NIP33](https://github.com/nostr-protocol/nips/blob/master/33.md) (Parameterized Replaceable Event) | | `30018` | `set_product` | Create or update a product. | [NIP33](https://github.com/nostr-protocol/nips/blob/master/33.md) (Parameterized Replaceable Event) | -| `4 ` | `direct_message` | Communicate with the customer. The messages can be plain-text or JSON. | [NIP09](https://github.com/nostr-protocol/nips/blob/master/09.md) | -| `5 ` | `delete` | Delete a product or a stall. | [NIP05](https://github.com/nostr-protocol/nips/blob/master/05.md) | +| `4 ` | `direct_message` | Communicate with the customer. The messages can be plain-text or JSON. | [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md) | +| `5 ` | `delete` | Delete a product or a stall. | [NIP09](https://github.com/nostr-protocol/nips/blob/master/09.md) | ### Event `30017`: Create or update a stall. From 835ec2614164c593e686e829aae6cbac64997ae8 Mon Sep 17 00:00:00 2001 From: Asai Toshiya Date: Tue, 16 May 2023 22:40:41 +0900 Subject: [PATCH 31/84] Add emoji tag to list --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index b99f1d35..963fd791 100644 --- a/README.md +++ b/README.md @@ -157,6 +157,7 @@ When experimenting with kinds, keep in mind the classification introduced by [NI | `delegation` | pubkey, conditions, delegation token | -- | [26](26.md) | | `description` | badge description | -- | [58](58.md) | | `description` | invoice description | -- | [57](57.md) | +| `emoji` | shortcode | image URL | [30](30.md) | | `expiration` | unix timestamp (string) | -- | [40](40.md) | | `image` | image URL | dimensions in pixels | [23](23.md), [58](58.md) | | `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) | From ccbdfb95c198c385595c18edac09d9c830fd9406 Mon Sep 17 00:00:00 2001 From: jiftechnify Date: Tue, 16 May 2023 21:50:04 +0900 Subject: [PATCH 32/84] allow underscores in an emoji shortcode --- 30.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/30.md b/30.md index 04689d0f..ffc5aeb3 100644 --- a/30.md +++ b/30.md @@ -14,7 +14,7 @@ Custom emoji may be added to **kind 0** and **kind 1** events by including one o Where: -- `` is a name given for the emoji, which MUST be comprised of only alphanumeric characters. +- `` is a name given for the emoji, which MUST be comprised of only alphanumeric characters and underscores. - `` is a URL to the corresponding image file of the emoji. For each emoji tag, clients should parse emoji shortcodes (aka "emojify") like `:shortcode:` in the event to display custom emoji. @@ -53,4 +53,4 @@ In kind 1 events, the `content` should be emojified. "pubkey": "79c2cae114ea28a981e7559b4fe7854a473521a8d22a66bbab9fa248eb820ff6", "created_at": 1682630000 } -``` \ No newline at end of file +``` From 1c916953c1a3a47edeac32ea015c32c450194423 Mon Sep 17 00:00:00 2001 From: heipacker Date: Sat, 20 May 2023 12:26:46 +0800 Subject: [PATCH 33/84] new: add new signer. Android, IOS, Extension --- 07.md | 1 + 1 file changed, 1 insertion(+) diff --git a/07.md b/07.md index 2a31f716..71123663 100644 --- a/07.md +++ b/07.md @@ -31,3 +31,4 @@ async window.nostr.nip04.decrypt(pubkey, ciphertext): string // takes ciphertext - [nos2x-fox](https://diegogurpegui.com/nos2x-fox/) (Firefox) - [Flamingo](https://www.getflamingo.org/) (Chrome and derivatives) - [AKA Profiles](https://github.com/neilck/aka-extension) (Chrome, stores multiple keys) +- [TokenPocket](https://www.tokenpocket.pro/) (Android, IOS, Chrome and derivatives) From 04959313559731c90cfa74413b7b8996795ee601 Mon Sep 17 00:00:00 2001 From: Alejandro Gomez Date: Tue, 23 May 2023 08:51:08 +0200 Subject: [PATCH 34/84] NIP-23: suggest kind 30024 for drafts --- 23.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/23.md b/23.md index 151a31b5..42912281 100644 --- a/23.md +++ b/23.md @@ -6,7 +6,7 @@ Long-form Content `draft` `optional` `author:fiatjaf` -This NIP defines `kind:30023` (a parameterized replaceable event according to [NIP-33](33.md)) for long-form text content, generally referred to as "articles" or "blog posts". +This NIP defines `kind:30023` (a parameterized replaceable event according to [NIP-33](33.md)) for long-form text content, generally referred to as "articles" or "blog posts". `kind:30024` has the same structure as `kind:30023` and is used to save long form drafts. "Social" clients that deal primarily with `kind:1` notes should not be expected to implement this NIP. From a56d1c2877e5c40640350fe0b21748642258baaf Mon Sep 17 00:00:00 2001 From: Asai Toshiya Date: Fri, 26 May 2023 17:28:10 +0900 Subject: [PATCH 35/84] =?UTF-8?q?Add=20description=20for=20d=C2=A0tag=20va?= =?UTF-8?q?lue?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 33.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/33.md b/33.md index 10681fac..c93c36e7 100644 --- a/33.md +++ b/33.md @@ -10,7 +10,7 @@ This NIP adds a new event range that allows for replacement of events that have Implementation -------------- -The value of a tag is defined as the first parameter of a tag after the tag name. +The value of a tag can be any string and 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`. Upon a parameterized replaceable event with a newer timestamp than the currently known latest From 4f04de2afda831ef339ad225e4e08a5b1d075e3c Mon Sep 17 00:00:00 2001 From: Akiomi Kamakura Date: Sat, 27 May 2023 08:44:19 +0900 Subject: [PATCH 36/84] Update 07.md --- 07.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/07.md b/07.md index 71123663..a0b5bdc1 100644 --- a/07.md +++ b/07.md @@ -26,7 +26,7 @@ async window.nostr.nip04.decrypt(pubkey, ciphertext): string // takes ciphertext - [horse](https://github.com/fiatjaf/horse) (Chrome and derivatives) - [nos2x](https://github.com/fiatjaf/nos2x) (Chrome and derivatives) -- [Alby](https://getalby.com) (Chrome and derivatives, Firefox, Safari) +- [Alby](https://getalby.com) (Chrome and derivatives, Firefox) - [Blockcore](https://www.blockcore.net/wallet) (Chrome and derivatives) - [nos2x-fox](https://diegogurpegui.com/nos2x-fox/) (Firefox) - [Flamingo](https://www.getflamingo.org/) (Chrome and derivatives) From b12c93c452814ffa5f06aef95b60775bc86eaf58 Mon Sep 17 00:00:00 2001 From: Jose Mateo Date: Sun, 28 May 2023 05:58:48 -0400 Subject: [PATCH 37/84] Fix nip-57 typo --- 57.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/57.md b/57.md index cb1f126c..438a0f87 100644 --- a/57.md +++ b/57.md @@ -168,7 +168,7 @@ A client can retrieve `zap receipt`s on events and pubkeys using a NIP-01 filter ### Appendix G: `zap` tag on zapped event -When an event includes a `zap` tag, clients SHOULD calculate the lnurl pay request based on it's value instead of the profile's field. An optional third argument on the tag specifies the type of value, either `lud06` or `lud16`. +When an event includes a `zap` tag, clients SHOULD calculate the lnurl pay request based on its value instead of the profile's field. An optional third argument on the tag specifies the type of value, either `lud06` or `lud16`. ```json { From 3a38583c068369f55249429ebefe6b09f3a243d5 Mon Sep 17 00:00:00 2001 From: Asai Toshiya Date: Wed, 31 May 2023 12:35:51 +0900 Subject: [PATCH 38/84] Fix link to NIP-10 --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/01.md b/01.md index e36f4f5d..33a10e70 100644 --- a/01.md +++ b/01.md @@ -107,6 +107,6 @@ 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. See [NIP-10](https://github.com/nostr-protocol/nips/blob/127d5518bfa9a4e4e7510490c0b8d95e342dfa4b/10.md) for a detailed description of "e" and "p" tags. +- 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](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. From cabbaadb69ecf28c2a91ced63359e1bd15b14ea9 Mon Sep 17 00:00:00 2001 From: haorendashu <385321165@qq.com> Date: Mon, 29 May 2023 15:47:09 +0800 Subject: [PATCH 39/84] Update 07.md Implementation --- 07.md | 1 + 1 file changed, 1 insertion(+) diff --git a/07.md b/07.md index a0b5bdc1..ee4e3722 100644 --- a/07.md +++ b/07.md @@ -32,3 +32,4 @@ async window.nostr.nip04.decrypt(pubkey, ciphertext): string // takes ciphertext - [Flamingo](https://www.getflamingo.org/) (Chrome and derivatives) - [AKA Profiles](https://github.com/neilck/aka-extension) (Chrome, stores multiple keys) - [TokenPocket](https://www.tokenpocket.pro/) (Android, IOS, Chrome and derivatives) +- [Nostrmo](https://github.com/haorendashu/nostrmo_faq#download) (Android, IOS) From fe9ed69dc3aec54ae437ca09a6d61aa2ce175577 Mon Sep 17 00:00:00 2001 From: Doug Hoyte Date: Fri, 19 May 2023 00:54:44 -0400 Subject: [PATCH 40/84] Specify replacement behaviour when replaceable events have the same timestamp - This is so that relays can converge on a deterministic sets of events, no matter the order they were received - Otherwise, clients or relays that sync their sets of events could continually retransmit events they think are missing on the other side, wasting bandwidth --- 16.md | 2 ++ 33.md | 2 ++ 2 files changed, 4 insertions(+) diff --git a/16.md b/16.md index 4d9481d4..8ef4af4d 100644 --- a/16.md +++ b/16.md @@ -20,6 +20,8 @@ Upon a replaceable event with a newer timestamp than the currently known latest effectively replacing what gets returned when querying for `author:kind` tuples. +If two events have the same timestamp, the event with the lowest id (first in lexical order) SHOULD be retained, and the other discarded. + Ephemeral Events ---------------- An *ephemeral event* is defined as an event with a kind `20000 <= n < 30000`. diff --git a/33.md b/33.md index c93c36e7..5128bece 100644 --- a/33.md +++ b/33.md @@ -18,6 +18,8 @@ replaceable event with the same kind, author and first `d` tag value being recei SHOULD be discarded, effectively replacing what gets returned when querying for `author:kind:d-tag` tuples. +If two events have the same timestamp, the event with the lowest id (first in lexical order) SHOULD be retained, and the other discarded. + 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: From 867c8bb334b0d9bb22a6af5c16ce6d186852af5a Mon Sep 17 00:00:00 2001 From: Pablo Fernandez Date: Wed, 7 Jun 2023 21:56:17 +0200 Subject: [PATCH 41/84] NIP-89: Recommended Application Handlers (#530) --- 89.md | 116 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 116 insertions(+) create mode 100644 89.md diff --git a/89.md b/89.md new file mode 100644 index 00000000..5eee3b8e --- /dev/null +++ b/89.md @@ -0,0 +1,116 @@ +NIP-89 +====== + +Recommended Application Handlers +-------------------------------- + +`draft` `optional` `author:pablof7z` + +This NIP describes `kind:31989` and `kind:31990`: a way to discover applications that can handle unknown event-kinds. + +## Rationale +Nostr's discoverability and transparent event interaction is one of its most interesting/novel mechanics. +This NIP provides a simple way for clients to discover applications that handle events of a specific kind to ensure smooth cross-client and cross-kind interactions. + +### Parties involved +There are three actors to this workflow: + +* application that handles a specific event kind (note that an application doesn't necessarily need to be a distinct entity and it could just be the same pubkey as user A) + * Publishes `kind:31990`, detailing how apps should redirect to it +* user A, who recommends an app that handles a specific event kind + * Publishes `kind:31989` +* user B, who seeks a recommendation for an app that handles a specific event kind + * Queries for `kind:31989` and, based on results, queries for `kind:31990` + +# Events + +## Recommendation event +```json +{ + "kind": 31989, + "pubkey": , + "tags": [ + [ "d", ], + [ "a", "31990:app1-pubkey:", "wss://relay1", "ios" ], + [ "a", "31990:app2-pubkey:", "wss://relay2", "web" ] + ] +} +``` + +The `d` tag in `kind:31989` is the supported event kind this event is recommending. + +Multiple `a` tags can appear on the same `kind:31989`. + +The second value of the tag SHOULD be a relay hint. +The third value of the tag SHOULD be the platform where this recommendation might apply. + +## Handler information +```json +{ + "kind": 31990, + "pubkey": , + "content": "", + "tags": [ + [ "d", ], + [ "k", ], + [ "web", "https://..../a/", "nevent" ], + [ "web", "https://..../p/", "nprofile" ], + [ "web", "https://..../e/" ], + [ "ios", ".../" ] + ] +} +``` + +* `content` is an optional `set_metadata`-like stringified JSON object, as described in NIP-01. This content is useful when the pubkey creating the `kind:31990` is not an application. If `content` is empty, the `kind:0` of the pubkey should be used to display application information (e.g. name, picture, web, LUD16, etc.) + +* `k` tags' value is the event kind that is supported by this `kind:31990`. +Using a `k` tag(s) (instead of having the kind onf the NIP-33 `d` tag) provides: + * Multiple `k` tags can exist in the same event if the application supports more than one event kind and their handler URLs are the same. + * The same pubkey can have multiple events with different apps that handle the same event kind. + +* `bech32` in a URL MUST be replaced by clients with the NIP-19-encoded entity that should be loaded by the application. + +Multiple tags might be registered by the app, following NIP-19 nomenclature as the second value of the array. + +A tag without a second value in the array SHOULD be considered a generic handler for any NIP-19 entity that is not handled by a different tag. + +# User flow +A user A who uses a non-`kind:1`-centric nostr app could choose to announce/recommend a certain kind-handler application. + +When user B sees an unknown event kind, e.g. in a social-media centric nostr client, the client would allow user B to interact with the unknown-kind event (e.g. tapping on it). + +The client MIGHT query for the user's and the user's follows handler. + +# Example + +## User A recommends a `kind:31337`-handler +User A might be a user of Zapstr, a `kind:31337`-centric client (tracks). Using Zapstr, user A publishes an event recommending Zapstr as a `kind:31337`-handler. + +```json +{ + "kind": 31989, + "tags": [ + [ "d", "31337" ], + [ "a", "31990:1743058db7078661b94aaf4286429d97ee5257d14a86d6bfa54cb0482b876fb0:abcd", , "web" ] + ] +} +``` + +## User B interacts with a `kind:31337`-handler +User B might see in their timeline an event referring to a `kind:31337` event +(e.g. a `kind:1` tagging a `kind:31337`). + +User B's client, not knowing how to handle a `kind:31337` might display the event +using its `alt` tag (as described in NIP-31). When the user clicks on the event, +the application queries for a handler for this `kind`: + +`["REQ", , '[{ "kinds": [31989], "#d": ["31337"], 'authors': [, ] }]']` + +User B, who follows User A, sees that `kind:31989` event and fetches the `a`-tagged event for the app and handler information. + +User B's client sees the application's `kind:31990` which includes the information to redirect the user to the relevant URL with the desired entity replaced in the URL. + +## Alternative query bypassing `kind:31989` +Alternatively, users might choose to query directly for `kind:31990` for an event kind. Clients SHOULD be careful doing this and use spam-prevention mechanisms to avoid directing users to malicious handlers. + +`["REQ", , '[{ "kinds": [31990], "#k": [], 'authors': [...] }]']` \ No newline at end of file From c78856d281658ba5c795b5295418692aa2827d2e Mon Sep 17 00:00:00 2001 From: pablof7z Date: Wed, 7 Jun 2023 23:19:56 +0200 Subject: [PATCH 42/84] update readme with NIP-89 --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index 963fd791..fbe43f9e 100644 --- a/README.md +++ b/README.md @@ -61,6 +61,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos - [NIP-58: Badges](58.md) - [NIP-65: Relay List Metadata](65.md) - [NIP-78: Application-specific data](78.md) +- [NIP-89: Recommended Application Handlers](89.md) - [NIP-94: File Metadata](94.md) ## Event Kinds @@ -101,6 +102,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `30018` | Create or update a product | [15](15.md) | | `30023` | Long-form Content | [23](23.md) | | `30078` | Application-specific Data | [78](78.md) | +| `31989` | Handler recommendation | [89](89.md) | +| `31990` | Handler information | [89](89.md) | ### Event Kind Ranges From 0d962cbe74018c64cd040c6c756ed94b648eef4b Mon Sep 17 00:00:00 2001 From: Asai Toshiya Date: Thu, 8 Jun 2023 12:15:37 +0900 Subject: [PATCH 43/84] Minor JSON fix --- 09.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/09.md b/09.md index 89781fbf..a73e0ab1 100644 --- a/09.md +++ b/09.md @@ -20,7 +20,7 @@ For example: "pubkey": <32-bytes hex-encoded public key of the event creator>, "tags": [ ["e", "dcd59..464a2"], - ["e", "968c5..ad7a4"], + ["e", "968c5..ad7a4"] ], "content": "these posts were published by accident", ...other fields From 89b308d5402d7b4c4e8daabdaa9f28a45cc2a829 Mon Sep 17 00:00:00 2001 From: Suhail Saqan Date: Thu, 8 Jun 2023 11:48:03 -0500 Subject: [PATCH 44/84] add image to nip11 --- 11.md | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/11.md b/11.md index b0d6003f..3ad6896c 100644 --- a/11.md +++ b/11.md @@ -255,6 +255,18 @@ Relays that require payments may want to expose their fee schedules. } ``` +### Image ### + +A URL pointing to an image to be used to represent the relay. + +```json +{ +... + "image": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg", +... +} +``` + ### Examples ### As of 2 May 2023 the following `curl` command provided these results. @@ -281,4 +293,5 @@ As of 2 May 2023 the following `curl` command provided these results. "payment_required":true}, "payments_url":"https://eden.nostr.land/invoices", "fees":{"admission":[{"amount":5000000,"unit":"msats"}], - "publication":[]}} + "publication":[]}}, + "image": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg" From 964bc5b5ce946ab66aae945084549f26ffdef70f Mon Sep 17 00:00:00 2001 From: pablof7z Date: Thu, 8 Jun 2023 22:27:00 +0200 Subject: [PATCH 45/84] update NIP to use alt tag --- 31.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/31.md b/31.md index 675c2496..e77ae341 100644 --- a/31.md +++ b/31.md @@ -6,8 +6,10 @@ Dealing with unknown event kinds `draft` `optional` `author:pablof7z` `author:fiatjaf` -When creating a new custom event kind that is part of a custom protocol and isn't meant to be read as text (like `kind:1`), clients should use the `tags` field to store all their custom data related to their protocol, and use the `content` field to write a short human-readable plaintext summary of what that event is about. +When creating a new custom event kind that is part of a custom protocol and isn't meant to be read as text (like `kind:1`), clients should use an `alt` tag to write a short human-readable plaintext summary of what that event is about. -The intent is that social clients, used to display only `kind:1` notes, can still show something in case a custom event pops up in their timelines. +The intent is that social clients, used to display only `kind:1` notes, can still show something in case a custom event pops up in their timelines. The content of the `alt` tag should provide enough context for a user that doesn't know anything about this event kind to understand what it is. These clients that only know `kind:1` are not expected to ask relays for events of different kinds, but users could still reference these weird events on their notes, and without proper context these could be nonsensical notes. Having the fallback text makes that situation much better -- even if only for making the user aware that they should try to view that custom event elsewhere. + +`kind:1`-centric clients can make interacting with these event kinds more functional by supporting [NIP-89](https://github.com/nostr-protocol/nips/blob/master/89.md). From d435ffc39cacf485662cea5c98aaa4af5af3b447 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Fri, 9 Jun 2023 14:13:42 -0300 Subject: [PATCH 46/84] clarify kind:1 plaintextness. --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/01.md b/01.md index 33a10e70..717e58af 100644 --- a/01.md +++ b/01.md @@ -99,7 +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 `[]()`. 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). Content that must be parsed, such as Markdown and HTML, should not be used. - `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. From 3e03b4b67f3421c8b7604426a7217422cdd013ff Mon Sep 17 00:00:00 2001 From: Seth For Privacy Date: Fri, 9 Jun 2023 11:19:23 -0400 Subject: [PATCH 47/84] Add context for limiting `before` timestamp --- 26.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/26.md b/26.md index b8fa9028..91176991 100644 --- a/26.md +++ b/26.md @@ -52,7 +52,9 @@ For example, the following condition strings are valid: - `kind=0&kind=1&created_at>1675721813` - `kind=1&created_at>1674777689&created_at<1675721813` -For the vast majority of use-cases, it is advisable that query strings should include a `created_at` ***after*** condition reflecting the current time, to prevent the delegatee from publishing historic notes on the delegator's behalf. +For the vast majority of use-cases, it is advisable that: +1. Query strings should include a `created_at` ***after*** condition reflecting the current time, to prevent the delegatee from publishing historic notes on the delegator's behalf. +2. Query strings should include a `created_at` ***before*** condition that is not empty and is not some extremely distant time in the future. If delegations are not limited in time scope, they expose similar security risks to simply using the root key for authentication. #### Example @@ -105,4 +107,4 @@ Clients should display the delegated note as if it was published directly by the Relays should answer requests such as `["REQ", "", {"authors": ["A"]}]` by querying both the `pubkey` and delegation tags `[1]` value. -Relays SHOULD allow the delegator (8e0d3d3e) to delete the events published by the delegatee (477318cf). \ No newline at end of file +Relays SHOULD allow the delegator (8e0d3d3e) to delete the events published by the delegatee (477318cf). From 2e842b496a740f89ad80bf8257c37535d538ba54 Mon Sep 17 00:00:00 2001 From: Asai Toshiya Date: Sat, 10 Jun 2023 17:52:25 +0900 Subject: [PATCH 48/84] Add description for clients to kind 1 --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/01.md b/01.md index 717e58af..2700dab1 100644 --- a/01.md +++ b/01.md @@ -99,7 +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). Content that must be parsed, such as Markdown and HTML, should not be used. + - `1`: `text_note`: the `content` is set to the **plaintext** content of a note (anything the user wants to say). Content that must be parsed, such as Markdown and HTML, should not be used. Clients should also not parse content as those. - `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. From fb5f5a1a974655eca7603b8b0f81b96922813eb2 Mon Sep 17 00:00:00 2001 From: Asai Toshiya Date: Mon, 12 Jun 2023 12:45:52 +0900 Subject: [PATCH 49/84] Fix typo "NIP: 26" to "NIP-26" --- 26.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/26.md b/26.md index 91176991..59cf807f 100644 --- a/26.md +++ b/26.md @@ -1,4 +1,4 @@ -NIP: 26 +NIP-26 ======= Delegated Event Signing From 2b34e9f4177216ea42ea32daafb3384521d94f32 Mon Sep 17 00:00:00 2001 From: Memory-of-Snow Date: Mon, 12 Jun 2023 17:46:01 +0900 Subject: [PATCH 50/84] Add a ',' between the 'id' and 'pubkey' elements in the JSON event in 01.md. --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/01.md b/01.md index 2700dab1..9164a98d 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 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": , From a9f2c6a2f128e9dda70716ace7ba72c7a3c88c3f Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Mon, 15 May 2023 05:53:50 -0700 Subject: [PATCH 51/84] Add NIP-32 for labeling things in nostr --- 32.md | 129 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 1 + 2 files changed, 130 insertions(+) create mode 100644 32.md diff --git a/32.md b/32.md new file mode 100644 index 00000000..7bb51069 --- /dev/null +++ b/32.md @@ -0,0 +1,129 @@ +NIP-32 +====== + +Labeling +--------- + +`draft` `optional` `author:staab` `author:gruruya` + +A label is a `kind 1985` note that is used to label other entities. This supports a number of use cases: + +- Distributed moderation and content recommendations +- Reviews and ratings +- Definition of edges in a graph structure + +This NIP does not supersede NIP-56, which supports reporting content for the purpose of +direct moderation, in order to comply with laws or app store requirements. "Moderation" +as defined by this NIP is only relative to user preferences and should be interpreted +with the social graph in view to provide a better user experience. + +Label Target +---- + +The label event MUST include one or more tags representing the object or objects being +labeled: `e`, `p`, `r`, or `t` tags. This allows for labeling of events, people, relays, +or topics respectively. + +Label Tag +---- + +This NIP introduces a new tag `l` which denotes a label. A label MAY be an unqualified string indicating the type of content based on convention, a qualified string referring to a tag type within nostr, or a qualified string referring to a nomenclature external to nostr. Some examples: + +- `review` - the publisher is leaving a review about the given entity. +- `#t/footstr` - the publisher thinks the given entity should have the `footstr` topic applied. +- `#p/` - the publisher things the given entity should be tagged with with `` +- `MeSH/D005528` - ["Foot"](https://meshb.nlm.nih.gov/record/ui?ui=D005528) from NIH's Medical Subject Headings vocabulary +- `GeoNames/3173435` - [Milan, Italy](https://www.geonames.org/3173435/milan.html) using the GeoNames coding system +- `ISO-3166-2/IT-MI` - Milano, Italy using ISO 3166-2. + +As much as possible, fully-qualified labels should be used. + +Other Tags +----- + +The label event MAY include a `quality` tag with a value of 0 to 1. This allows for an +absolute, granular scale that can be represented in any way (5 stars, color scale, etc). + +The label event MAY include a `confidence` tag with a value of 0 to 1. This indicates the certainty which the author has about their rating. + +Example events +-------------- + +A report that an event contains nudity. + +```json +{ + "kind": 1985, + "tags": [ + ["e", ] + ["l", "nudity"], + ], + "content": "", + ... +} +``` + +A suggestion that multiple pubkeys be associated with the `permies` topic. + +```json +{ + "kind": 1985, + "tags": [ + ["l", "#t/permies"], + ["p", ], + ["p", ], + ], + "content": "", + ... +} +``` + +A review of a relay, as relates to certain topics, including additional dimensions. The author +is indicating here that `relay_url` is related to the bitcoin topic, but they're not very sure +that's the case. + +```json +{ + "kind": 1985, + "tags": [ + ["l", "#t/bitcoin"], + ["r", ], + ["quality", 0.7], + ["confidence", 0.2], + ], + "content": "I think this relay is mostly just bitcoiners.", + ... +} +``` + +A plain review of a relay. + +```json +{ + "kind": 1985, + "tags": [ + ["l", "review"], + ["r", ], + ["quality", 0.1], + ], + "content": "This relay is full of mean people.", + ... +} +``` + +A more abstract use case: defining an edge in a graph structure, in this case identifying +a lightning channel that is open between two pubkeys. This just demonstrates the flexibility +this spec provides for overlaying structured metadata on top of nostr. + +```json +{ + "kind": 1985, + "tags": [ + ["l", "lightning/channel"], + ["p", ], + ["p", ], + ], + "content": "", + ... +} +``` diff --git a/README.md b/README.md index a940ba60..b3b15502 100644 --- a/README.md +++ b/README.md @@ -47,6 +47,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos - [NIP-28: Public Chat](28.md) - [NIP-30: Custom Emoji](30.md) - [NIP-31: Dealing with Unknown Events](31.md) +- [NIP-32: Labeling](32.md) - [NIP-33: Parameterized Replaceable Events](33.md) - [NIP-36: Sensitive Content](36.md) - [NIP-39: External Identities in Profiles](39.md) From 621340e26783511b311826c4555d40b5db902b58 Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Mon, 15 May 2023 06:47:31 -0700 Subject: [PATCH 52/84] Add example to NIP-32 to support tagging multiple entities with multiple labels --- 32.md | 30 ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/32.md b/32.md index 7bb51069..253a5045 100644 --- a/32.md +++ b/32.md @@ -55,8 +55,26 @@ A report that an event contains nudity. { "kind": 1985, "tags": [ - ["e", ] - ["l", "nudity"], + ["e", ], + ["l", "nudity"] + ], + "content": "", + ... +} +``` + +A single event can apply multiple labels to multiple targets to support mass-tagging. + +```json +{ + "kind": 1985, + "tags": [ + ["e", ], + ["p", ], + ["t", "chickens"], + ["l", "permaculture"], + ["l", "permies"], + ["l", "farming"] ], "content": "", ... @@ -71,7 +89,7 @@ A suggestion that multiple pubkeys be associated with the `permies` topic. "tags": [ ["l", "#t/permies"], ["p", ], - ["p", ], + ["p", ] ], "content": "", ... @@ -89,7 +107,7 @@ that's the case. ["l", "#t/bitcoin"], ["r", ], ["quality", 0.7], - ["confidence", 0.2], + ["confidence", 0.2] ], "content": "I think this relay is mostly just bitcoiners.", ... @@ -104,7 +122,7 @@ A plain review of a relay. "tags": [ ["l", "review"], ["r", ], - ["quality", 0.1], + ["quality", 0.1] ], "content": "This relay is full of mean people.", ... @@ -121,7 +139,7 @@ this spec provides for overlaying structured metadata on top of nostr. "tags": [ ["l", "lightning/channel"], ["p", ], - ["p", ], + ["p", ] ], "content": "", ... From 68b9331b624c8fcaa584c8e4b113793981c9ff80 Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Tue, 16 May 2023 06:18:01 -0700 Subject: [PATCH 53/84] Add L tag, allow self-labeling, split namespaces out --- 32.md | 56 +++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 37 insertions(+), 19 deletions(-) diff --git a/32.md b/32.md index 253a5045..f5557ca9 100644 --- a/32.md +++ b/32.md @@ -27,16 +27,21 @@ or topics respectively. Label Tag ---- -This NIP introduces a new tag `l` which denotes a label. A label MAY be an unqualified string indicating the type of content based on convention, a qualified string referring to a tag type within nostr, or a qualified string referring to a nomenclature external to nostr. Some examples: +This NIP introduces a new tag `l` which denotes a label, and a new `L` tag which denotes a label namespace. A label MUST include a mark matching an `L` tag. `L` tags refer to a tag type within nostr, or a nomenclature external to nostr defined either formally or by convention. Some examples: -- `review` - the publisher is leaving a review about the given entity. -- `#t/footstr` - the publisher thinks the given entity should have the `footstr` topic applied. -- `#p/` - the publisher things the given entity should be tagged with with `` -- `MeSH/D005528` - ["Foot"](https://meshb.nlm.nih.gov/record/ui?ui=D005528) from NIH's Medical Subject Headings vocabulary -- `GeoNames/3173435` - [Milan, Italy](https://www.geonames.org/3173435/milan.html) using the GeoNames coding system -- `ISO-3166-2/IT-MI` - Milano, Italy using ISO 3166-2. +- `["l", "footstr", "#t"]` - the publisher thinks the given entity should have the `footstr` topic applied. +- `["l", "", "#p"]` - the publisher things the given entity should be tagged with with `` +- `["l", "D005528", "MeSH"]` - ["Foot"](https://meshb.nlm.nih.gov/record/ui?ui=D005528) from NIH's Medical Subject Headings vocabulary +- `["l", "3173435", "GeoNames"]` - [Milan, Italy](https://www.geonames.org/3173435/milan.html) using the GeoNames coding system +- `["l", "IT-MI", "ISO-3166-2"]` - Milano, Italy using ISO 3166-2. +- `["l", "relay", "review"]` - the publisher is leaving a review about a relay. -As much as possible, fully-qualified labels should be used. +`L` tags containing the label namespaces MUST be included in order to support searching by +namespace rather than by a specific tag. The special `ugc` ("user generated content") namespace +MAY be used when the label content is provided by an end user. + +`l` and `L` tags MAY be added to other event kinds to support self-reporting. For events +with a kind other than 1985, labels refer to the event itself. Other Tags ----- @@ -49,21 +54,25 @@ The label event MAY include a `confidence` tag with a value of 0 to 1. This indi Example events -------------- -A report that an event contains nudity. +A report that an event contains nudity. Note that NIP 56 is preferred for reporting content +to clients, while labels are recommended for supporting distributed content moderation use +cases. ```json { "kind": 1985, "tags": [ - ["e", ], - ["l", "nudity"] + ["L", "report"], + ["l", "nudity", "report"], + ["e", ] ], "content": "", ... } ``` -A single event can apply multiple labels to multiple targets to support mass-tagging. +A single event can apply multiple labels to multiple targets to support mass-tagging. Multiple +namespaces may be used at the same time. ```json { @@ -72,9 +81,14 @@ A single event can apply multiple labels to multiple targets to support mass-tag ["e", ], ["p", ], ["t", "chickens"], - ["l", "permaculture"], - ["l", "permies"], - ["l", "farming"] + ["L", "#t"] + ["L", "ugc"] + ["L", "com.example.labels"] + ["l", "chickens", "#t"], + ["l", "user generated content", "ugc"], + ["l", "permaculture", "com.example.labels"], + ["l", "permies", "com.example.labels"], + ["l", "farming", "com.example.labels"], ], "content": "", ... @@ -87,7 +101,8 @@ A suggestion that multiple pubkeys be associated with the `permies` topic. { "kind": 1985, "tags": [ - ["l", "#t/permies"], + ["L", "#t"], + ["l", "permies", "#t"], ["p", ], ["p", ] ], @@ -104,7 +119,8 @@ that's the case. { "kind": 1985, "tags": [ - ["l", "#t/bitcoin"], + ["L", "#t"], + ["l", "bitcoin", "#t"], ["r", ], ["quality", 0.7], ["confidence", 0.2] @@ -120,7 +136,8 @@ A plain review of a relay. { "kind": 1985, "tags": [ - ["l", "review"], + ["L", "review"], + ["l", "relay", "review"], ["r", ], ["quality", 0.1] ], @@ -137,7 +154,8 @@ this spec provides for overlaying structured metadata on top of nostr. { "kind": 1985, "tags": [ - ["l", "lightning/channel"], + ["L", "my-lightning-nomenclature"], + ["l", "channel", "my-lightning-nomenclature"], ["p", ], ["p", ] ], From 34910c8674917a687ed7a71bb4968d6a54ee3f55 Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Tue, 16 May 2023 12:28:02 -0700 Subject: [PATCH 54/84] Add s3x-jay to author for NIP 32 --- 32.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/32.md b/32.md index f5557ca9..0180a233 100644 --- a/32.md +++ b/32.md @@ -4,7 +4,7 @@ NIP-32 Labeling --------- -`draft` `optional` `author:staab` `author:gruruya` +`draft` `optional` `author:staab` `author:gruruya` `author:s3x-jay` A label is a `kind 1985` note that is used to label other entities. This supports a number of use cases: From 95f537e90d568ff23e485f336d251b5d415e1191 Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Wed, 17 May 2023 12:50:29 -0700 Subject: [PATCH 55/84] Add relay hints, replaceable events, and clarification about content to NIP 32 --- 32.md | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-) diff --git a/32.md b/32.md index 0180a233..b84fc642 100644 --- a/32.md +++ b/32.md @@ -6,7 +6,7 @@ Labeling `draft` `optional` `author:staab` `author:gruruya` `author:s3x-jay` -A label is a `kind 1985` note that is used to label other entities. This supports a number of use cases: +A label is a `kind 1985` (regular) event or `kind 32144` (replaceable) event that is used to label other entities. This supports a number of use cases: - Distributed moderation and content recommendations - Reviews and ratings @@ -22,7 +22,12 @@ Label Target The label event MUST include one or more tags representing the object or objects being labeled: `e`, `p`, `r`, or `t` tags. This allows for labeling of events, people, relays, -or topics respectively. +or topics respectively. As with NIP-01, a relay hint SHOULD be included when using `e` and +`p` tags. + +Any number of targets may be included when using a kind `1985` non-replaceable event. If kind +`32144` is preferred, the event MUST have a single target tag, and its value MUST also be the +value of the `d` tag. Label Tag ---- @@ -51,6 +56,12 @@ absolute, granular scale that can be represented in any way (5 stars, color scal The label event MAY include a `confidence` tag with a value of 0 to 1. This indicates the certainty which the author has about their rating. +Content +------- + +`l` tags should be short, meaningful strings. Longer discussions, such as for a review, or an +explanation of why something was labeled the way it was should go in the event's `content` field. + Example events -------------- @@ -64,7 +75,7 @@ cases. "tags": [ ["L", "report"], ["l", "nudity", "report"], - ["e", ] + ["e", , ] ], "content": "", ... @@ -78,8 +89,8 @@ namespaces may be used at the same time. { "kind": 1985, "tags": [ - ["e", ], - ["p", ], + ["e", , ], + ["p", , ], ["t", "chickens"], ["L", "#t"] ["L", "ugc"] @@ -103,8 +114,8 @@ A suggestion that multiple pubkeys be associated with the `permies` topic. "tags": [ ["L", "#t"], ["l", "permies", "#t"], - ["p", ], - ["p", ] + ["p", , ], + ["p", , ] ], "content": "", ... @@ -156,8 +167,8 @@ this spec provides for overlaying structured metadata on top of nostr. "tags": [ ["L", "my-lightning-nomenclature"], ["l", "channel", "my-lightning-nomenclature"], - ["p", ], - ["p", ] + ["p", , ], + ["p", , ] ], "content": "", ... From 5b32def861fb114feb564ce2d089b7983639ada8 Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Tue, 23 May 2023 14:33:27 -0700 Subject: [PATCH 56/84] Move annotations to the label tag for NIP-32. Remove replaceable events --- 32.md | 30 +++++++++++++----------------- 1 file changed, 13 insertions(+), 17 deletions(-) diff --git a/32.md b/32.md index b84fc642..a16ddf7a 100644 --- a/32.md +++ b/32.md @@ -6,7 +6,7 @@ Labeling `draft` `optional` `author:staab` `author:gruruya` `author:s3x-jay` -A label is a `kind 1985` (regular) event or `kind 32144` (replaceable) event that is used to label other entities. This supports a number of use cases: +A label is a `kind 1985` event that is used to label other entities. This supports a number of use cases: - Distributed moderation and content recommendations - Reviews and ratings @@ -25,10 +25,6 @@ labeled: `e`, `p`, `r`, or `t` tags. This allows for labeling of events, people, or topics respectively. As with NIP-01, a relay hint SHOULD be included when using `e` and `p` tags. -Any number of targets may be included when using a kind `1985` non-replaceable event. If kind -`32144` is preferred, the event MUST have a single target tag, and its value MUST also be the -value of the `d` tag. - Label Tag ---- @@ -48,18 +44,21 @@ MAY be used when the label content is provided by an end user. `l` and `L` tags MAY be added to other event kinds to support self-reporting. For events with a kind other than 1985, labels refer to the event itself. -Other Tags +Label Annotations ----- -The label event MAY include a `quality` tag with a value of 0 to 1. This allows for an -absolute, granular scale that can be represented in any way (5 stars, color scale, etc). +A label tag MAY include a 4th positional element detailing extra information about the label in question. This string +should be a url-encoded list of key/value pairs, for example `quality=1&confidence=1`. Any key MAY be used, but the +following are recommended: -The label event MAY include a `confidence` tag with a value of 0 to 1. This indicates the certainty which the author has about their rating. +- `quality` may have a value of 0 to 1. This allows for an absolute, granular scale that can be represented in any way (5 stars, color scale, etc). +- `confidence` may have a value of 0 to 1. This indicates the certainty which the author has about their rating. +- `context` may be a comma-separated list of urls (including NIP-21 urls) indicating other context that should be considered when interpreting labels. Content ------- -`l` tags should be short, meaningful strings. Longer discussions, such as for a review, or an +Labels should be short, meaningful strings. Longer discussions, such as for a review, or an explanation of why something was labeled the way it was should go in the event's `content` field. Example events @@ -131,10 +130,8 @@ that's the case. "kind": 1985, "tags": [ ["L", "#t"], - ["l", "bitcoin", "#t"], - ["r", ], - ["quality", 0.7], - ["confidence", 0.2] + ["l", "bitcoin", "#t", "quality=0.7&confidence=0.2"], + ["r", ] ], "content": "I think this relay is mostly just bitcoiners.", ... @@ -148,9 +145,8 @@ A plain review of a relay. "kind": 1985, "tags": [ ["L", "review"], - ["l", "relay", "review"], - ["r", ], - ["quality", 0.1] + ["l", "relay", "review", "quality=0.1"], + ["r", ] ], "content": "This relay is full of mean people.", ... From 2372874b98fd109cfa517532a276cec456e738f8 Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Tue, 23 May 2023 14:47:56 -0700 Subject: [PATCH 57/84] Use JSON for label metadata in NIP-32 --- 32.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/32.md b/32.md index a16ddf7a..161af537 100644 --- a/32.md +++ b/32.md @@ -21,7 +21,7 @@ Label Target ---- The label event MUST include one or more tags representing the object or objects being -labeled: `e`, `p`, `r`, or `t` tags. This allows for labeling of events, people, relays, +labeled: `e`, `p`, `a`, `r`, or `t` tags. This allows for labeling of events, people, relays, or topics respectively. As with NIP-01, a relay hint SHOULD be included when using `e` and `p` tags. @@ -47,9 +47,8 @@ with a kind other than 1985, labels refer to the event itself. Label Annotations ----- -A label tag MAY include a 4th positional element detailing extra information about the label in question. This string -should be a url-encoded list of key/value pairs, for example `quality=1&confidence=1`. Any key MAY be used, but the -following are recommended: +A label tag MAY include a 4th positional element detailing extra metadata about the label in question. This string +should be a json-encoded object. Any key MAY be used, but the following are recommended: - `quality` may have a value of 0 to 1. This allows for an absolute, granular scale that can be represented in any way (5 stars, color scale, etc). - `confidence` may have a value of 0 to 1. This indicates the certainty which the author has about their rating. @@ -130,7 +129,7 @@ that's the case. "kind": 1985, "tags": [ ["L", "#t"], - ["l", "bitcoin", "#t", "quality=0.7&confidence=0.2"], + ["l", "bitcoin", "#t", "{\"quality\": 0.7, \"confidence\": 0.2}"], ["r", ] ], "content": "I think this relay is mostly just bitcoiners.", @@ -145,7 +144,7 @@ A plain review of a relay. "kind": 1985, "tags": [ ["L", "review"], - ["l", "relay", "review", "quality=0.1"], + ["l", "relay", "review", "{\"quality\": 0.1}"], ["r", ] ], "content": "This relay is full of mean people.", From 4e8f3adf43afae1944ade2a5031eebf5de0e1fd2 Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Wed, 24 May 2023 12:42:26 -0700 Subject: [PATCH 58/84] Recommend qualified names for label namespaces --- 32.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/32.md b/32.md index 161af537..858e6371 100644 --- a/32.md +++ b/32.md @@ -28,14 +28,15 @@ or topics respectively. As with NIP-01, a relay hint SHOULD be included when usi Label Tag ---- -This NIP introduces a new tag `l` which denotes a label, and a new `L` tag which denotes a label namespace. A label MUST include a mark matching an `L` tag. `L` tags refer to a tag type within nostr, or a nomenclature external to nostr defined either formally or by convention. Some examples: +This NIP introduces a new tag `l` which denotes a label, and a new `L` tag which denotes a label namespace. A label MUST include a mark matching an `L` tag. `L` tags refer to a tag type within nostr, or a nomenclature external to nostr defined either formally or by convention. Any string can be a namespace, but publishers SHOULD ensure they are unambiguous by using a well-defined ISO standard or reverse domain name notation. Some examples: - `["l", "footstr", "#t"]` - the publisher thinks the given entity should have the `footstr` topic applied. - `["l", "", "#p"]` - the publisher things the given entity should be tagged with with `` - `["l", "D005528", "MeSH"]` - ["Foot"](https://meshb.nlm.nih.gov/record/ui?ui=D005528) from NIH's Medical Subject Headings vocabulary - `["l", "3173435", "GeoNames"]` - [Milan, Italy](https://www.geonames.org/3173435/milan.html) using the GeoNames coding system - `["l", "IT-MI", "ISO-3166-2"]` - Milano, Italy using ISO 3166-2. -- `["l", "relay", "review"]` - the publisher is leaving a review about a relay. +- `["l", "VI-hum", "social.nos.ontology"]` - Violence toward a human being as defined by ontology.nos.social. +- `["l", "review", "social.coracle.ontology"]` - the publisher is leaving a review about the target, as defined by ontology.coracle.social. `L` tags containing the label namespaces MUST be included in order to support searching by namespace rather than by a specific tag. The special `ugc` ("user generated content") namespace @@ -58,7 +59,7 @@ Content ------- Labels should be short, meaningful strings. Longer discussions, such as for a review, or an -explanation of why something was labeled the way it was should go in the event's `content` field. +explanation of why something was labeled the way it was, should go in the event's `content` field. Example events -------------- @@ -143,8 +144,8 @@ A plain review of a relay. { "kind": 1985, "tags": [ - ["L", "review"], - ["l", "relay", "review", "{\"quality\": 0.1}"], + ["L", "social.coracle.ontology"], + ["l", "review", "social.coracle.ontology", "{\"quality\": 0.1}"], ["r", ] ], "content": "This relay is full of mean people.", From 057d097e741453895164590d1c56fe87703c2c97 Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Thu, 25 May 2023 10:22:35 -0700 Subject: [PATCH 59/84] Add an example for self-tagging, clarify # labels --- 32.md | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/32.md b/32.md index 858e6371..dd2f50ca 100644 --- a/32.md +++ b/32.md @@ -30,8 +30,10 @@ Label Tag This NIP introduces a new tag `l` which denotes a label, and a new `L` tag which denotes a label namespace. A label MUST include a mark matching an `L` tag. `L` tags refer to a tag type within nostr, or a nomenclature external to nostr defined either formally or by convention. Any string can be a namespace, but publishers SHOULD ensure they are unambiguous by using a well-defined ISO standard or reverse domain name notation. Some examples: +Namespaces starting with `#` indicate that the label target should be associated with the label's value. This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, etc. + - `["l", "footstr", "#t"]` - the publisher thinks the given entity should have the `footstr` topic applied. -- `["l", "", "#p"]` - the publisher things the given entity should be tagged with with `` +- `["l", "", "#p"]` - the publisher thinks the given entity is related to `` - `["l", "D005528", "MeSH"]` - ["Foot"](https://meshb.nlm.nih.gov/record/ui?ui=D005528) from NIH's Medical Subject Headings vocabulary - `["l", "3173435", "GeoNames"]` - [Milan, Italy](https://www.geonames.org/3173435/milan.html) using the GeoNames coding system - `["l", "IT-MI", "ISO-3166-2"]` - Milano, Italy using ISO 3166-2. @@ -170,3 +172,17 @@ this spec provides for overlaying structured metadata on top of nostr. ... } ``` + +Publishers can self-label by adding `l` tags to their own non-1985 events. + +```json +{ + "kind": 1, + "tags": [ + ["L", "social.nos.ontology"], + ["l", "IL-frd", "social.nos.ontology"] + ], + "content": "Send me 100 sats and I'll send you 200 back", + ... +} +``` From 114302517fa5b4ea499c5725f8a6aab675c36e24 Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Sat, 27 May 2023 09:03:48 -0700 Subject: [PATCH 60/84] remove references to nip 56 in nip 32 --- 32.md | 22 ---------------------- 1 file changed, 22 deletions(-) diff --git a/32.md b/32.md index dd2f50ca..1939555c 100644 --- a/32.md +++ b/32.md @@ -12,11 +12,6 @@ A label is a `kind 1985` event that is used to label other entities. This suppor - Reviews and ratings - Definition of edges in a graph structure -This NIP does not supersede NIP-56, which supports reporting content for the purpose of -direct moderation, in order to comply with laws or app store requirements. "Moderation" -as defined by this NIP is only relative to user preferences and should be interpreted -with the social graph in view to provide a better user experience. - Label Target ---- @@ -66,23 +61,6 @@ explanation of why something was labeled the way it was, should go in the event' Example events -------------- -A report that an event contains nudity. Note that NIP 56 is preferred for reporting content -to clients, while labels are recommended for supporting distributed content moderation use -cases. - -```json -{ - "kind": 1985, - "tags": [ - ["L", "report"], - ["l", "nudity", "report"], - ["e", , ] - ], - "content": "", - ... -} -``` - A single event can apply multiple labels to multiple targets to support mass-tagging. Multiple namespaces may be used at the same time. From 363d112e335c13f4fa1c113e2418db1102c58ed5 Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Wed, 7 Jun 2023 16:03:05 -0700 Subject: [PATCH 61/84] Add a note about PREs, update NIP 36 to point to NIP 32 --- 32.md | 15 +++++++++++++-- 36.md | 7 ++++++- 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/32.md b/32.md index 1939555c..b572c132 100644 --- a/32.md +++ b/32.md @@ -23,9 +23,13 @@ or topics respectively. As with NIP-01, a relay hint SHOULD be included when usi Label Tag ---- -This NIP introduces a new tag `l` which denotes a label, and a new `L` tag which denotes a label namespace. A label MUST include a mark matching an `L` tag. `L` tags refer to a tag type within nostr, or a nomenclature external to nostr defined either formally or by convention. Any string can be a namespace, but publishers SHOULD ensure they are unambiguous by using a well-defined ISO standard or reverse domain name notation. Some examples: +This NIP introduces a new tag `l` which denotes a label, and a new `L` tag which denotes a label namespace. +A label MUST include a mark matching an `L` tag. `L` tags refer to a tag type within nostr, or a nomenclature +external to nostr defined either formally or by convention. Any string can be a namespace, but publishers SHOULD +ensure they are unambiguous by using a well-defined ISO standard or reverse domain name notation. Some examples: -Namespaces starting with `#` indicate that the label target should be associated with the label's value. This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, etc. +Namespaces starting with `#` indicate that the label target should be associated with the label's value. +This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, etc. - `["l", "footstr", "#t"]` - the publisher thinks the given entity should have the `footstr` topic applied. - `["l", "", "#p"]` - the publisher thinks the given entity is related to `` @@ -164,3 +168,10 @@ Publishers can self-label by adding `l` tags to their own non-1985 events. ... } ``` + +Other Notes +----------- + +When using this NIP to bulk-label many targets at once, events may be deleted and a replacement +may be published. We have opted not to use parameterizable/replaceable events for this due to the +complexity in coming up with a standard `d` tag. diff --git a/36.md b/36.md index 1223e53c..379d40a4 100644 --- a/36.md +++ b/36.md @@ -9,12 +9,15 @@ Sensitive Content / Content Warning The `content-warning` tag enables users to specify if the event's content needs to be approved by readers to be shown. Clients can hide the content until the user acts on it. +`l` and `L` tags MAY be also be used as defined in [NIP-32](32.md) with the `content-warning` namespace to support +further qualification and querying. + #### Spec ``` tag: content-warning options: - - [reason]: optional + - [reason]: optional ``` #### Example @@ -26,6 +29,8 @@ options: "kind": 1, "tags": [ ["t", "hastag"], + ["L", "content-warning"], + ["l", "reason", "content-warning"], ["content-warning", "reason"] /* reason is optional */ ], "content": "sensitive content with #hastag\n", From 92ce49dda0acce1f661868316a9858521d4bc974 Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Wed, 7 Jun 2023 16:09:26 -0700 Subject: [PATCH 62/84] Add labeling to nip 56 as well --- 36.md | 4 +++- 56.md | 15 ++++++++++----- 2 files changed, 13 insertions(+), 6 deletions(-) diff --git a/36.md b/36.md index 379d40a4..6d1cf639 100644 --- a/36.md +++ b/36.md @@ -9,7 +9,7 @@ Sensitive Content / Content Warning The `content-warning` tag enables users to specify if the event's content needs to be approved by readers to be shown. Clients can hide the content until the user acts on it. -`l` and `L` tags MAY be also be used as defined in [NIP-32](32.md) with the `content-warning` namespace to support +`l` and `L` tags MAY be also be used as defined in [NIP-32](32.md) with the `content-warning` or other namespace to support further qualification and querying. #### Spec @@ -31,6 +31,8 @@ options: ["t", "hastag"], ["L", "content-warning"], ["l", "reason", "content-warning"], + ["L", "social.nos.ontology"], + ["l", "NS-nud", "social.nos.ontology"], ["content-warning", "reason"] /* reason is optional */ ], "content": "sensitive content with #hastag\n", diff --git a/56.md b/56.md index 55ee1a2e..42174fb2 100644 --- a/56.md +++ b/56.md @@ -32,6 +32,9 @@ being reported, which consists of the following report types: Some report tags only make sense for profile reports, such as `impersonation` +`l` and `L` tags MAY be also be used as defined in [NIP-32](32.md) to support +further qualification and querying. + Example events -------------- @@ -39,7 +42,9 @@ Example events { "kind": 1984, "tags": [ - [ "p", , "nudity"] + ["p", , "nudity"] + ["L", "social.nos.ontology"], + ["l", "NS-nud", "social.nos.ontology"], ], "content": "", ... @@ -48,8 +53,8 @@ Example events { "kind": 1984, "tags": [ - [ "e", , "illegal"], - [ "p", ] + ["e", , "illegal"], + ["p", ] ], "content": "He's insulting the king!", ... @@ -58,8 +63,8 @@ Example events { "kind": 1984, "tags": [ - [ "p", , "impersonation"], - [ "p", ] + ["p", , "impersonation"], + ["p", ] ], "content": "Profile is imitating #[1]", ... From 61849b5a6bd1171a4c661c5c0531984a7b3db993 Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Tue, 13 Jun 2023 09:34:24 -0700 Subject: [PATCH 63/84] Small wording changes --- 32.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/32.md b/32.md index b572c132..fcf6082c 100644 --- a/32.md +++ b/32.md @@ -37,7 +37,7 @@ This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, - `["l", "3173435", "GeoNames"]` - [Milan, Italy](https://www.geonames.org/3173435/milan.html) using the GeoNames coding system - `["l", "IT-MI", "ISO-3166-2"]` - Milano, Italy using ISO 3166-2. - `["l", "VI-hum", "social.nos.ontology"]` - Violence toward a human being as defined by ontology.nos.social. -- `["l", "review", "social.coracle.ontology"]` - the publisher is leaving a review about the target, as defined by ontology.coracle.social. +- `["l", "relay/review", "social.coracle.ontology"]` - the publisher is leaving a review about a relay, as defined by ontology.coracle.social. `L` tags containing the label namespaces MUST be included in order to support searching by namespace rather than by a specific tag. The special `ugc` ("user generated content") namespace @@ -54,7 +54,7 @@ should be a json-encoded object. Any key MAY be used, but the following are reco - `quality` may have a value of 0 to 1. This allows for an absolute, granular scale that can be represented in any way (5 stars, color scale, etc). - `confidence` may have a value of 0 to 1. This indicates the certainty which the author has about their rating. -- `context` may be a comma-separated list of urls (including NIP-21 urls) indicating other context that should be considered when interpreting labels. +- `context` may be an array of urls (including NIP-21 urls) indicating other context that should be considered when interpreting labels. Content ------- @@ -129,7 +129,7 @@ A plain review of a relay. "kind": 1985, "tags": [ ["L", "social.coracle.ontology"], - ["l", "review", "social.coracle.ontology", "{\"quality\": 0.1}"], + ["l", "relay/review", "social.coracle.ontology", "{\"quality\": 0.1}"], ["r", ] ], "content": "This relay is full of mean people.", From bef3e6c941c80114c1a040d42317c8fef4a74e7d Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Tue, 13 Jun 2023 17:30:26 -0700 Subject: [PATCH 64/84] Add a few more notes to nip 32 --- 32.md | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/32.md b/32.md index fcf6082c..45cadbe7 100644 --- a/32.md +++ b/32.md @@ -26,7 +26,7 @@ Label Tag This NIP introduces a new tag `l` which denotes a label, and a new `L` tag which denotes a label namespace. A label MUST include a mark matching an `L` tag. `L` tags refer to a tag type within nostr, or a nomenclature external to nostr defined either formally or by convention. Any string can be a namespace, but publishers SHOULD -ensure they are unambiguous by using a well-defined ISO standard or reverse domain name notation. Some examples: +ensure they are unambiguous by using a well-defined namespace (such as an ISO standard) or reverse domain name notation. Some examples: Namespaces starting with `#` indicate that the label target should be associated with the label's value. This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, etc. @@ -36,8 +36,8 @@ This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, - `["l", "D005528", "MeSH"]` - ["Foot"](https://meshb.nlm.nih.gov/record/ui?ui=D005528) from NIH's Medical Subject Headings vocabulary - `["l", "3173435", "GeoNames"]` - [Milan, Italy](https://www.geonames.org/3173435/milan.html) using the GeoNames coding system - `["l", "IT-MI", "ISO-3166-2"]` - Milano, Italy using ISO 3166-2. -- `["l", "VI-hum", "social.nos.ontology"]` - Violence toward a human being as defined by ontology.nos.social. -- `["l", "relay/review", "social.coracle.ontology"]` - the publisher is leaving a review about a relay, as defined by ontology.coracle.social. +- `["l", "VI-hum", "com.example.ontology"]` - Violence toward a human being as defined by ontology.example.com. +- `["l", "relay/review", "com.example.ontology"]` - the publisher is leaving a review about a relay, as defined by ontology.example.com. `L` tags containing the label namespaces MUST be included in order to support searching by namespace rather than by a specific tag. The special `ugc` ("user generated content") namespace @@ -128,8 +128,8 @@ A plain review of a relay. { "kind": 1985, "tags": [ - ["L", "social.coracle.ontology"], - ["l", "relay/review", "social.coracle.ontology", "{\"quality\": 0.1}"], + ["L", "com.example.ontology"], + ["l", "relay/review", "com.example.ontology", "{\"quality\": 0.1}"], ["r", ] ], "content": "This relay is full of mean people.", @@ -161,8 +161,8 @@ Publishers can self-label by adding `l` tags to their own non-1985 events. { "kind": 1, "tags": [ - ["L", "social.nos.ontology"], - ["l", "IL-frd", "social.nos.ontology"] + ["L", "com.example.ontology"], + ["l", "IL-frd", "com.example.ontology"] ], "content": "Send me 100 sats and I'll send you 200 back", ... @@ -175,3 +175,14 @@ Other Notes When using this NIP to bulk-label many targets at once, events may be deleted and a replacement may be published. We have opted not to use parameterizable/replaceable events for this due to the complexity in coming up with a standard `d` tag. + +Before creating a vocabulary, explore how your use case may have already been designed and +imitate that design if possible. Reverse domain name notation is encouraged to avoid +namespace clashes, but for the sake of interoperability all namespaces should be +considered open for public use, and not proprietary. In other words, if there is a +namespace that fits your use case, use it even if it points to someone else's domain name. + +Vocabularies MAY choose to include the namespace in the label, delimited by a `:` character. +This may be preferred when defining more formal vocabularies that should not be confused with +another namespace when querying without an `L` tag. For these vocabularies, all labels +SHOULD include the namespace (rather than mixing qualified and unqualified labels). From 992b045aa7b7610d1c492dab717eb183094fec39 Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Wed, 14 Jun 2023 09:43:03 -0700 Subject: [PATCH 65/84] remove delimiter recommendation --- 32.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/32.md b/32.md index 45cadbe7..b1473859 100644 --- a/32.md +++ b/32.md @@ -182,7 +182,8 @@ namespace clashes, but for the sake of interoperability all namespaces should be considered open for public use, and not proprietary. In other words, if there is a namespace that fits your use case, use it even if it points to someone else's domain name. -Vocabularies MAY choose to include the namespace in the label, delimited by a `:` character. -This may be preferred when defining more formal vocabularies that should not be confused with -another namespace when querying without an `L` tag. For these vocabularies, all labels -SHOULD include the namespace (rather than mixing qualified and unqualified labels). +Vocabularies MAY choose to fully qualify all labels within a namespace (for example, +`["l", "com.example.vocabulary:my-label"]`. This may be preferred when defining more +formal vocabularies that should not be confused with another namespace when querying +without an `L` tag. For these vocabularies, all labels SHOULD include the namespace +(rather than mixing qualified and unqualified labels). From 58f1667479c94011350d15a0c0d9058a86980c71 Mon Sep 17 00:00:00 2001 From: Pablo Fernandez Date: Fri, 16 Jun 2023 01:23:40 +0200 Subject: [PATCH 66/84] NIP-09: Add `a` tag deletion (#600) Co-authored-by: arthurfranca --- 09.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/09.md b/09.md index a73e0ab1..9dab90ff 100644 --- a/09.md +++ b/09.md @@ -8,7 +8,7 @@ Event Deletion A special event with kind `5`, meaning "deletion" is defined as having a list of one or more `e` tags, each referencing an event the author is requesting to be deleted. -Each tag entry must contain an "e" event id intended for deletion. +Each tag entry must contain an "e" event id and/or NIP-33 `a` tags intended for deletion. The event's `content` field MAY contain a text note describing the reason for the deletion. @@ -20,7 +20,8 @@ For example: "pubkey": <32-bytes hex-encoded public key of the event creator>, "tags": [ ["e", "dcd59..464a2"], - ["e", "968c5..ad7a4"] + ["e", "968c5..ad7a4"], + ["a", "::"] ], "content": "these posts were published by accident", ...other fields From b481651e81f3bc1aca8636992e1ede5ded4c1f2d Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Fri, 16 Jun 2023 18:18:44 -0300 Subject: [PATCH 67/84] change wording of nip-18 to bring it back to its original intent. --- 18.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/18.md b/18.md index 422ad9ca..cdea9cd4 100644 --- a/18.md +++ b/18.md @@ -9,8 +9,8 @@ Reposts A repost is a `kind 6` note that is used to signal to followers that another event is worth reading. -The `content` of a repost event is empty. Optionally, it MAY contain -the stringified JSON of the reposted note event for quick look up. +The `content` of a repost event the stringified JSON of the reposted note +for quick look up. It MAY also be empty, but that is not recommended. The repost event MUST include an `e` tag with the `id` of the note that is being reposted. That tag MUST include a relay URL as its third entry From ece0dda45be1053f673216edb9d6cd8a92035757 Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Sat, 17 Jun 2023 09:07:08 -0700 Subject: [PATCH 68/84] Remove some examples from nip 32 to keep things concise --- 32.md | 77 ++++++----------------------------------------------------- 1 file changed, 7 insertions(+), 70 deletions(-) diff --git a/32.md b/32.md index b1473859..ddd364ae 100644 --- a/32.md +++ b/32.md @@ -6,11 +6,7 @@ Labeling `draft` `optional` `author:staab` `author:gruruya` `author:s3x-jay` -A label is a `kind 1985` event that is used to label other entities. This supports a number of use cases: - -- Distributed moderation and content recommendations -- Reviews and ratings -- Definition of edges in a graph structure +A label is a `kind 1985` event that is used to label other entities. This supports a number of use cases, from distributed moderation and content recommendations to reviews and ratings. Label Target ---- @@ -26,18 +22,17 @@ Label Tag This NIP introduces a new tag `l` which denotes a label, and a new `L` tag which denotes a label namespace. A label MUST include a mark matching an `L` tag. `L` tags refer to a tag type within nostr, or a nomenclature external to nostr defined either formally or by convention. Any string can be a namespace, but publishers SHOULD -ensure they are unambiguous by using a well-defined namespace (such as an ISO standard) or reverse domain name notation. Some examples: +ensure they are unambiguous by using a well-defined namespace (such as an ISO standard) or reverse domain name notation. Namespaces starting with `#` indicate that the label target should be associated with the label's value. This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, etc. +Some examples: + - `["l", "footstr", "#t"]` - the publisher thinks the given entity should have the `footstr` topic applied. - `["l", "", "#p"]` - the publisher thinks the given entity is related to `` -- `["l", "D005528", "MeSH"]` - ["Foot"](https://meshb.nlm.nih.gov/record/ui?ui=D005528) from NIH's Medical Subject Headings vocabulary -- `["l", "3173435", "GeoNames"]` - [Milan, Italy](https://www.geonames.org/3173435/milan.html) using the GeoNames coding system - `["l", "IT-MI", "ISO-3166-2"]` - Milano, Italy using ISO 3166-2. - `["l", "VI-hum", "com.example.ontology"]` - Violence toward a human being as defined by ontology.example.com. -- `["l", "relay/review", "com.example.ontology"]` - the publisher is leaving a review about a relay, as defined by ontology.example.com. `L` tags containing the label namespaces MUST be included in order to support searching by namespace rather than by a specific tag. The special `ugc` ("user generated content") namespace @@ -65,30 +60,6 @@ explanation of why something was labeled the way it was, should go in the event' Example events -------------- -A single event can apply multiple labels to multiple targets to support mass-tagging. Multiple -namespaces may be used at the same time. - -```json -{ - "kind": 1985, - "tags": [ - ["e", , ], - ["p", , ], - ["t", "chickens"], - ["L", "#t"] - ["L", "ugc"] - ["L", "com.example.labels"] - ["l", "chickens", "#t"], - ["l", "user generated content", "ugc"], - ["l", "permaculture", "com.example.labels"], - ["l", "permies", "com.example.labels"], - ["l", "farming", "com.example.labels"], - ], - "content": "", - ... -} -``` - A suggestion that multiple pubkeys be associated with the `permies` topic. ```json @@ -105,24 +76,7 @@ A suggestion that multiple pubkeys be associated with the `permies` topic. } ``` -A review of a relay, as relates to certain topics, including additional dimensions. The author -is indicating here that `relay_url` is related to the bitcoin topic, but they're not very sure -that's the case. - -```json -{ - "kind": 1985, - "tags": [ - ["L", "#t"], - ["l", "bitcoin", "#t", "{\"quality\": 0.7, \"confidence\": 0.2}"], - ["r", ] - ], - "content": "I think this relay is mostly just bitcoiners.", - ... -} -``` - -A plain review of a relay. +A review of a relay. ```json { @@ -137,24 +91,6 @@ A plain review of a relay. } ``` -A more abstract use case: defining an edge in a graph structure, in this case identifying -a lightning channel that is open between two pubkeys. This just demonstrates the flexibility -this spec provides for overlaying structured metadata on top of nostr. - -```json -{ - "kind": 1985, - "tags": [ - ["L", "my-lightning-nomenclature"], - ["l", "channel", "my-lightning-nomenclature"], - ["p", , ], - ["p", , ] - ], - "content": "", - ... -} -``` - Publishers can self-label by adding `l` tags to their own non-1985 events. ```json @@ -174,7 +110,8 @@ Other Notes When using this NIP to bulk-label many targets at once, events may be deleted and a replacement may be published. We have opted not to use parameterizable/replaceable events for this due to the -complexity in coming up with a standard `d` tag. +complexity in coming up with a standard `d` tag. In order to avoid ambiguity when querying, +publishers SHOULD limit labeling events to a single namespace. Before creating a vocabulary, explore how your use case may have already been designed and imitate that design if possible. Reverse domain name notation is encouraged to avoid From 1412eb89c2b3fe19b36ea57ef19d5bfe0b6ce929 Mon Sep 17 00:00:00 2001 From: Kieran Date: Sat, 17 Jun 2023 18:49:02 +0100 Subject: [PATCH 69/84] fix typo --- 98.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/98.md b/98.md index 1ccd2611..ecbebc08 100644 --- a/98.md +++ b/98.md @@ -46,7 +46,7 @@ Example event: Servers MUST perform the following checks in order to validate the event: 1. The `kind` MUST be `27235`. 2. The `created_at` MUST be within a reasonable time window (suggestion 60 seconds). -3. The `url` tag MUST be exactly the same as the absolute request URL (including query parameters). +3. The `u` tag MUST be exactly the same as the absolute request URL (including query parameters). 4. The `method` tag MUST be the same HTTP method used for the requested resource. When the request contains a body (as in POST/PUT/PATCH methods) clients SHOULD include a SHA256 hash of the request body in a `payload` tag as hex (`["payload", ""]`), servers MAY check this to validate that the requested payload is authorized. From 36e9fd59e93730c2d2002ec7aac58a53e58143a3 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sat, 17 Jun 2023 15:49:52 -0300 Subject: [PATCH 70/84] add note about websocket status code 4000. nip-01 may need some love. --- 01.md | 1 + 1 file changed, 1 insertion(+) diff --git a/01.md b/01.md index 9164a98d..07440585 100644 --- a/01.md +++ b/01.md @@ -110,3 +110,4 @@ A relay may choose to treat different message kinds differently, and it may or m - 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](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. +- When a websocket is closed by the relay with a status code 4000 that means the client shouldn't try to connect again. From 83cbd3e17a12bbc2b63799fe8f53883f80f70809 Mon Sep 17 00:00:00 2001 From: Suhail Saqan Date: Sat, 17 Jun 2023 16:01:03 -0500 Subject: [PATCH 71/84] change from `Image` to `Icon` --- 11.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/11.md b/11.md index 3ad6896c..ec46b367 100644 --- a/11.md +++ b/11.md @@ -255,14 +255,14 @@ Relays that require payments may want to expose their fee schedules. } ``` -### Image ### +### Icon ### -A URL pointing to an image to be used to represent the relay. +A URL pointing to an image to be used as an icon for the relay. Recommended to be squared in shape. ```json { ... - "image": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg", + "icon": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg", ... } ``` @@ -294,4 +294,4 @@ As of 2 May 2023 the following `curl` command provided these results. "payments_url":"https://eden.nostr.land/invoices", "fees":{"admission":[{"amount":5000000,"unit":"msats"}], "publication":[]}}, - "image": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg" + "icon": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg" From 7668507cdf5580037c3363a2acaf6a2e1f8e032f Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Fri, 16 Jun 2023 18:16:42 -0300 Subject: [PATCH 72/84] kind:16 generic reposts. --- 18.md | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/18.md b/18.md index cdea9cd4..965263f7 100644 --- a/18.md +++ b/18.md @@ -6,8 +6,8 @@ Reposts `draft` `optional` `author:jb55` `author:fiatjaf` `author:arthurfranca` -A repost is a `kind 6` note that is used to signal to followers -that another event is worth reading. +A repost is a `kind 6` event that is used to signal to followers +that a `kind 1` text note is worth reading. The `content` of a repost event the stringified JSON of the reposted note for quick look up. It MAY also be empty, but that is not recommended. @@ -21,5 +21,15 @@ reposted. ## Quote Reposts -Quote reposts are `kind 1` events with an embedded `e` tag (see [NIP-08](08.md) and [NIP-27](27.md)). -Because a quote repost includes an `e` tag, it may show up along replies to the reposted note. +Quote reposts are `kind 1` events with an embedded `e` tag +(see [NIP-08](08.md) and [NIP-27](27.md)). Because a quote repost includes +an `e` tag, it may show up along replies to the reposted note. + +## Generic Reposts + +Since `kind 6` reposts are reserved for `kind 1` contents, we use `kind 16` +as a "generic repost", that can include any kind of event inside other than +`kind 1`. + +`kind 16` reposts SHOULD contain a `k` tag with the stringified kind number +of the reposted event as its value. From 1f6c79f6d217d6a8ba9d6ae8d52738ce3ff45251 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sun, 18 Jun 2023 11:36:23 -0300 Subject: [PATCH 73/84] typo on nip 18. --- 18.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/18.md b/18.md index 965263f7..75c4100c 100644 --- a/18.md +++ b/18.md @@ -9,8 +9,7 @@ Reposts A repost is a `kind 6` event that is used to signal to followers that a `kind 1` text note is worth reading. -The `content` of a repost event the stringified JSON of the reposted note -for quick look up. It MAY also be empty, but that is not recommended. +The `content` of a repost event is _the stringified JSON of the reposted note_. It MAY also be empty, but that is not recommended. The repost event MUST include an `e` tag with the `id` of the note that is being reposted. That tag MUST include a relay URL as its third entry From 73e93d09ad596a7170b9dbea4498d0f74805bb70 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sun, 18 Jun 2023 11:39:31 -0300 Subject: [PATCH 74/84] add generic repost to readme. --- README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index ca2e6881..83d19ad0 100644 --- a/README.md +++ b/README.md @@ -76,9 +76,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `3` | Contacts | [2](02.md) | | `4` | Encrypted Direct Messages | [4](04.md) | | `5` | Event Deletion | [9](09.md) | -| `6` | Reposts | [18](18.md) | +| `6` | Repost | [18](18.md) | | `7` | Reaction | [25](25.md) | | `8` | Badge Award | [58](58.md) | +| `16` | Generic Repost | [18](18.md) | | `40` | Channel Creation | [28](28.md) | | `41` | Channel Metadata | [28](28.md) | | `42` | Channel Message | [28](28.md) | From 1b35f1153dbf57dd65cedf53672593d253bccc5f Mon Sep 17 00:00:00 2001 From: Asai Toshiya Date: Wed, 21 Jun 2023 17:26:48 +0900 Subject: [PATCH 75/84] Add kind and tags for NIP-32 to lists --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index 3de2d29d..9893ffcf 100644 --- a/README.md +++ b/README.md @@ -88,6 +88,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `44` | Channel Mute User | [28](28.md) | | `1063` | File Metadata | [94](94.md) | | `1984` | Reporting | [56](56.md) | +| `1985` | Label | [32](32.md) | | `9734` | Zap Request | [57](57.md) | | `9735` | Zap | [57](57.md) | | `10000` | Mute List | [51](51.md) | @@ -156,6 +157,8 @@ 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) | | `g` | geohash | -- | [12](12.md) | | `i` | identity | proof | [39](39.md) | +| `l` | label, label namespace | annotations | [32](32.md) | +| `L` | label namespace | -- | [32](32.md) | | `p` | pubkey (hex) | relay URL | [1](01.md) | | `r` | a reference (URL, etc) | -- | [12](12.md) | | `t` | hashtag | -- | [12](12.md) | From fab6a21a779460f696f11169ddf343b437327592 Mon Sep 17 00:00:00 2001 From: Yasuhiro Matsumoto Date: Mon, 26 Jun 2023 10:37:48 +0900 Subject: [PATCH 76/84] fixed typos --- 47.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/47.md b/47.md index c884b978..b6a4f2bc 100644 --- a/47.md +++ b/47.md @@ -33,7 +33,7 @@ There are three event kinds: - `NIP-47 response`: 23195 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. +a plaintext string with the supported commands, space-separated, 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 **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. @@ -64,8 +64,8 @@ Response: ``` The `result_type` field MUST contain the name of the method that this event is responding to. -The `error` field MUST contain a `message` field with a human readable error message and a `code` field with the error code if the command was not succesful. -If the command was succesful, the `error` field must be null. +The `error` field MUST contain a `message` field with a human readable error message and a `code` field with the error code if the command was not successful. +If the command was successful, the `error` field must be null. ### Error codes - `RATE_LIMITED`: The client is sending commands too fast. It should retry in a few seconds. From e0fc913719aae2ed1b10884e80f085218738f65d Mon Sep 17 00:00:00 2001 From: tcheeric Date: Sun, 2 Jul 2023 11:57:27 +0100 Subject: [PATCH 77/84] For clarification, the time unit for all date attributes in the filters (since, until) are in seconds --- 01.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/01.md b/01.md index 07440585..2ff81ebf 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": } ``` From 141197c564d97073f0293e3b2f367f0b6b3619c2 Mon Sep 17 00:00:00 2001 From: Vitor Pamplona Date: Sat, 8 Jul 2023 08:11:22 -0400 Subject: [PATCH 78/84] NIP-53 Live Activities (#498) --- 53.md | 125 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 125 insertions(+) create mode 100644 53.md diff --git a/53.md b/53.md new file mode 100644 index 00000000..9a86d9e0 --- /dev/null +++ b/53.md @@ -0,0 +1,125 @@ +NIP-53 +====== + +Live Activities +--------------- + +`draft` `optional` `author:vitorpamplona` `author:v0l` + +## Abstract + +Service providers want to offer live activities to the Nostr network in such a way that participants can easily logged and queried by clients. This NIP describes a general framework to advertise the involvement of pubkeys in such live activities. + +# Live Event + +A special event with `kind:30311` "Live Event" is defined as a [NIP-33: Parameterized Replaceable Events](33.md) of public `p` tags. Each `p` tag SHOULD have a **displayable** marker name for the current role (e.g. `Host`, `Speaker`, `Participant`) of the user in the event and the relay information MAY be empty. This event will be constantly updated as participants join and leave the activity. + +For example: + +```js +{ + "kind": 30311, + "tags": [ + ["d", ""], + ["title", ""], + ["summary", ""], + ["image", ""], + ["t", "hashtag"] + ["streaming", ""], + ["recording", ""], // used to place the edited video once the activity is over + ["starts", ""], + ["ends", ""], + ["status", ""], + ["current_participants", ""], + ["total_participants", ""], + ["p", "91cf9..4e5ca", "wss://provider1.com/", "Host", ""], + ["p", "14aeb..8dad4", "wss://provider2.com/nostr", "Speaker"], + ["p", "612ae..e610f", "ws://provider3.com/ws", "Participant"], + ["relays", "wss://one.com", "wss://two.com", ...] + ], + "content": "", + ...other fields +} +``` + +A distinct `d` tag should be used for each activity. All other tags are optional. + +Providers SHOULD keep the participant list small (e.g. under 1000 users) and, when limits are reached, Providers SHOULD select which participants get named in the event. Clients should not expect a comprehensive list. Once the activity ends, the event can be deleted or updated to summarize the activity and provide async content (e.g. recording of the event). + +Clients are expected to subscribe to `kind:30311` events in general or for given follow lists and statuses. Clients MAY display participants' roles in activities as well as access points to join the activity. + +Live Activity management clients are expected to constantly update `kind:30311` during the event. Clients MAY choose to consider `status=live` events after 1hr without any update as `ended`. The `starts` and `ends` timestamp SHOULD be updated when the status changes to and from `live` + +The activity MUST be linked to using the NIP-19 naddr code along with the "a" tag (see [NIP-33](33.md) and [NIP-19](19.md)). + +## Proof of Agreement to Participate + +Event owners can add proof as the 5th term in each `p` tag to clarify the participant's agreement in joining the event. The proof is a signed SHA256 of the complete `a` Tag of the event (`kind:pubkey:dTag`) by each `p`'s private key, encoded in hex. + +Clients MAY only display participants if the proof is available or MAY display participants as "invited" if the proof is not available. + +This feature is important to avoid malicious event owners adding large account holders to the event, without their knowledge, to lure their followers into the malicious owner's trap. + +# Live Chat Message + +Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity with a `root` marker. Other Kind-1 tags such as `reply` and `mention` can also be used. + +```js +{ + "id": "<32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>", + "pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>", + "created_at": "", + "kind": 1311, + "tags": [ + ["a", "34550::", "", "root"], + ], + "content": "Zaps to live streams is beautiful." +} +``` + +# Use Cases + +Common use cases include meeting rooms/workshops, watch-together activities, or event spaces, such as [live.snort.social](https://live.snort.social) and [nostrnests.com](https://nostrnests.com). + +# Example + +Live Streaming + +```json +{ + "id": "57f28dbc264990e2c61e80a883862f7c114019804208b14da0bff81371e484d2", + "pubkey": "1597246ac22f7d1375041054f2a4986bd971d8d196d7997e48973263ac9879ec", + "created_at": 1687182672, + "kind": 30311, + "tags": [ + ["d", "demo-cf-stream"], + ["title", "Adult Swim Metalocalypse"], + ["summary", "Live stream from IPTV-ORG collection"], + ["streaming", "https://adultswim-vodlive.cdn.turner.com/live/metalocalypse/stream.m3u8"], + ["starts", "1687182672"] + ["status", "live"], + ["t", "animation"], + ["t", "iptv"], + ["image", "https://i.imgur.com/CaKq6Mt.png"] + ], + "content": "", + "sig": "5bc7a60f5688effa5287244a24768cbe0dcd854436090abc3bef172f7f5db1410af4277508dbafc4f70a754a891c90ce3b966a7bc47e7c1eb71ff57640f3d389" +} +``` + +Live Streaming chat message + +```json +{ + "id": "97aa81798ee6c5637f7b21a411f89e10244e195aa91cb341bf49f718e36c8188", + "pubkey": "3f770d65d3a764a9c5cb503ae123e62ec7598ad035d836e2a810f3877a745b24", + "created_at": 1687286726, + "kind": 1311, + "tags": [ + ["a", "30311:1597246ac22f7d1375041054f2a4986bd971d8d196d7997e48973263ac9879ec:demo-cf-stream", "", "root"] + ], + "content": "Zaps to live streams is beautiful.", + "sig": "997f62ddfc0827c121043074d50cfce7a528e978c575722748629a4137c45b75bdbc84170bedc723ef0a5a4c3daebf1fef2e93f5e2ddb98e5d685d022c30b622" +} +```` + From 3a32c0fd781bb1b6e2d23eb83da9f0b56e4a233e Mon Sep 17 00:00:00 2001 From: jiftechnify Date: Sun, 9 Jul 2023 12:32:26 +0900 Subject: [PATCH 79/84] clarify case-sensitiveness of tag names --- 01.md | 2 +- 12.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/01.md b/01.md index 2ff81ebf..686b2ee3 100644 --- a/01.md +++ b/01.md @@ -107,7 +107,7 @@ 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. See [NIP-10](10.md) for a detailed description of "e" and "p" tags. +- The `tags` array can store a case-sensitive 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](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. - When a websocket is closed by the relay with a status code 4000 that means the client shouldn't try to connect again. diff --git a/12.md b/12.md index 74c9d81a..7d1f46e7 100644 --- a/12.md +++ b/12.md @@ -8,7 +8,7 @@ Generic Tag Queries Relays may support subscriptions over arbitrary tags. `NIP-01` requires relays to respond to queries for `e` and `p` tags. This NIP allows any single-letter tag present in an event to be queried. -The `` object described in `NIP-01` is expanded to contain arbitrary keys with a `#` prefix. Any single-letter key in a filter beginning with `#` is a tag query, and MUST have a value of an array of strings. The filter condition matches if the event has a tag with the same name, and there is at least one tag value in common with the filter and event. The tag name is the letter without the `#`, and the tag value is the second element. Subsequent elements are ignored for the purposes of tag queries. +The `` object described in `NIP-01` is expanded to contain arbitrary keys with a `#` prefix. Any single-letter key in a filter beginning with `#` is a tag query, and MUST have a value of an array of strings. The filter condition matches if the event has a tag with the same name, and there is at least one tag value in common with the filter and event. The tag name is the letter without the `#`, and the tag value is the second element. Subsequent elements are ignored for the purposes of tag queries. Note that tag names are case-sensitive. Example Subscription Filter --------------------------- From 52edccbbe380eeadb7622fc9eb255928dcff6178 Mon Sep 17 00:00:00 2001 From: jiftechnify Date: Sun, 9 Jul 2023 12:45:16 +0900 Subject: [PATCH 80/84] standardize the terminology --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/01.md b/01.md index 686b2ee3..4c2ccd9d 100644 --- a/01.md +++ b/01.md @@ -107,7 +107,7 @@ 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 case-sensitive 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](10.md) for a detailed description of "e" and "p" tags. +- The `tags` array can store a case-sensitive tag name 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](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. - When a websocket is closed by the relay with a status code 4000 that means the client shouldn't try to connect again. From 20b22e7079282fd5403b6f11ea4ddc3f1beb8bfe Mon Sep 17 00:00:00 2001 From: jiftechnify Date: Sun, 9 Jul 2023 11:27:58 +0900 Subject: [PATCH 81/84] add NIP-53 to the list --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index 9893ffcf..2a444c32 100644 --- a/README.md +++ b/README.md @@ -58,6 +58,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos - [NIP-47: Wallet Connect](47.md) - [NIP-50: Keywords filter](50.md) - [NIP-51: Lists](51.md) +- [NIP-53: Live Activities](53.md) - [NIP-56: Reporting](56.md) - [NIP-57: Lightning Zaps](57.md) - [NIP-58: Badges](58.md) @@ -87,6 +88,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `43` | Channel Hide Message | [28](28.md) | | `44` | Channel Mute User | [28](28.md) | | `1063` | File Metadata | [94](94.md) | +| `1311` | Live Chat Message | [53](53.md) | | `1984` | Reporting | [56](56.md) | | `1985` | Label | [32](32.md) | | `9734` | Zap Request | [57](57.md) | @@ -108,6 +110,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `30018` | Create or update a product | [15](15.md) | | `30023` | Long-form Content | [23](23.md) | | `30078` | Application-specific Data | [78](78.md) | +| `30311` | Live Event | [53](53.md) | | `31989` | Handler recommendation | [89](89.md) | | `31990` | Handler information | [89](89.md) | From 7cd861c4d3c7a28d6b0d4ee26ad2a36fdb2670a5 Mon Sep 17 00:00:00 2001 From: Asai Toshiya Date: Mon, 10 Jul 2023 12:38:50 +0900 Subject: [PATCH 82/84] Update tag list --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 2a444c32..c448df64 100644 --- a/README.md +++ b/README.md @@ -172,7 +172,7 @@ When experimenting with kinds, keep in mind the classification introduced by [NI | `delegation` | pubkey, conditions, delegation token | -- | [26](26.md) | | `description` | badge description | -- | [58](58.md) | | `description` | invoice description | -- | [57](57.md) | -| `emoji` | shortcode | image URL | [30](30.md) | +| `emoji` | shortcode, image URL | -- | [30](30.md) | | `expiration` | unix timestamp (string) | -- | [40](40.md) | | `image` | image URL | dimensions in pixels | [23](23.md), [58](58.md) | | `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) | From a1cd2bd809c6e7476fe1e4dcab78f3a0df22f37d Mon Sep 17 00:00:00 2001 From: Yasuhiro Matsumoto Date: Thu, 6 Jul 2023 17:22:42 +0900 Subject: [PATCH 83/84] NIP-25 content might be NIP-30 custom emoji --- 25.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/25.md b/25.md index f74bcc08..855f331c 100644 --- a/25.md +++ b/25.md @@ -18,7 +18,7 @@ downvote or dislike on a post. A client MAY also choose to tally likes against dislikes in a reddit-like system of upvotes and downvotes, or display them as separate tallies. -The `content` MAY be an emoji, in this case it MAY be interpreted as a "like" or "dislike", +The `content` MAY be an emoji, or [NIP-30](30.md) custom emoji in this case it MAY be interpreted as a "like" or "dislike", or the client MAY display this emoji reaction on the post. Tags From 00ec0c83ace1353b297b60af6bf519cb2ea04f0e Mon Sep 17 00:00:00 2001 From: Yasuhiro Matsumoto Date: Tue, 11 Jul 2023 00:15:34 +0900 Subject: [PATCH 84/84] Add new section Custom Emoji Reaction --- 25.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/25.md b/25.md index 855f331c..7a612a14 100644 --- a/25.md +++ b/25.md @@ -47,3 +47,25 @@ func make_like_event(pubkey: String, privkey: String, liked: NostrEvent) -> Nost ev.sign(privkey: privkey) return ev } +``` + +Custom Emoji Reaction +--------------------- + +The client may specify a custom emoji ([NIP-30](30.md)) `:shortcode` in the +reaction content. The client should refer to the emoji tag and render the +content as an emoji if shortcode is specified. + +```json +{ + "kind": 7, + "content": ":soapbox:", + "tags": [ + ["emoji", "soapbox", "https://gleasonator.com/emoji/Gleasonator/soapbox.png"] + ], + "pubkey": "79c2cae114ea28a981e7559b4fe7854a473521a8d22a66bbab9fa248eb820ff6", + "created_at": 1682790000 +} +``` + +The content can be set only one `:shortcode:`. And emoji tag should be one.