From 524caa38563f49fc2aacbbe48b212fde0f24f97e Mon Sep 17 00:00:00 2001 From: Mike Dilger Date: Mon, 20 Feb 2023 09:28:39 +1300 Subject: [PATCH 01/22] More explicit explanation of the meaning of read and write relays --- 65.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/65.md b/65.md index c4fc2461..4c7a6a53 100644 --- a/65.md +++ b/65.md @@ -10,20 +10,26 @@ A special replaceable event meaning "Relay List Metadata" is defined as an event The primary purpose of this relay list is to advertise to others, not for configuring one's client. -The content is not used and SHOULD be blank. +The content is not used and SHOULD be an empty string. -The `r` tags can have a second parameter as either `read` or `write`. If it is omitted, it means the author both reads from and writes to that relay. +The `r` tags can have a second parameter as either `read` or `write`. If it is omitted, it means the author uses the relay for both purposes. Clients SHOULD, as with all replaceable events, use only the most recent kind-10002 event they can find. ### The meaning of read and write -If an author advertises a write relay in a kind `10002` event, that means that feed-related events created by the author, which the author wants their followers to see, will be posted there. Normally these would be kind-1 Text Note events, but are not limited as such. +Write relays are for events that are intended for anybody (e.g. your followers). Read relays are for events that address a particular person. + +Clients SHOULD write feed-related events created by their user to their user's write relays. + +Clients SHOULD read feed-related events created by another from at least some of that other person's write relays. Explicitly, they SHOULD NOT expect them to be available at their user's read relays. It SHOULD NOT be presumed that the user's read relays coincide with the write relays of the people the user follows. + +Clients SHOULD read events that tag their user from their user's read relays. + +Clients SHOULD write events that tag a person to at least some of that person's read relays. Explicitly, they SHOULD NOT expect that person will pick them up from their user's write relays. It SHOULD NOT be presumed that the user's write relays coincide with the read relays of the person being tagged. Clients SHOULD presume that if their user has a pubkey in their ContactList (kind 3) that it is because they wish to see that author's feed-related events. But clients MAY presume otherwise. -If an author advertises a read relay in a kind `10002` event, that means that the author may be subscribed to events that tag them on such relays. Clients SHOULD publish events that tag someone on at least some of the read relays of the person being tagged. - ### Motivation There is a common nostr use case where users wish to follow the content produced by other users. This is evidenced by the implicit meaning of the Contact List in [NIP-02](02.md) From b1a5ad355a8b376170471a41817d8722ba7443b1 Mon Sep 17 00:00:00 2001 From: Marco Argentieri <3596602+tiero@users.noreply.github.com> Date: Mon, 20 Feb 2023 20:26:13 +0100 Subject: [PATCH 02/22] =?UTF-8?q?NIP-46:=20Nostr=20Connect=20=F0=9F=94=8C?= =?UTF-8?q?=20connect=20your=20Nostr=20app=20with=20remote=20signing=20dev?= =?UTF-8?q?ices=20(#153)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 46.md | 162 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 2 + 2 files changed, 164 insertions(+) create mode 100644 46.md diff --git a/46.md b/46.md new file mode 100644 index 00000000..a9f37c1b --- /dev/null +++ b/46.md @@ -0,0 +1,162 @@ +NIP-46 +====== + +Nostr Connect +------------------------ + +`draft` `optional` `author:tiero` `author:giowe` `author:vforvalerio87` + +## Rationale + +Private keys should be exposed to as few systems - apps, operating systems, devices - as possible as each system adds to the attack surface. + +Entering private keys can also be annoying and requires exposing them to even more systems such as the operating system's clipboard that might be monitored by malicious apps. + + +## Terms + +* **App**: Nostr app on any platform that *requires* to act on behalf of a nostr account. +* **Signer**: Nostr app that holds the private key of a nostr account and *can sign* on its behalf. + + +## `TL;DR` + + +**App** and **Signer** sends ephemeral encrypted messages to each other using kind `24133`, using a relay of choice. + +App prompts the Signer to do things such as fetching the public key or signing events. + +The `content` field must be an encrypted JSONRPC-ish **request** or **response**. + +## Signer Protocol + +### Messages + +#### Request + +```json +{ + "id": , + "method": , + "params": [, ] +} +``` + +#### Response + +```json +{ + "id": , + "result": , + "error": +} +``` + +### Methods + + +#### Mandatory + +These are mandatory methods the remote signer app MUST implement: + +- **describe** + - params [] + - result `{"get_public_key": { params: [], result: anything }}` +- **get_public_key** + - params [] + - result `pubkey` +- **sign_event** + - params [`event`] + - result `signature` + +#### optional + + +- **connect** + - params [`pubkey`] +- **disconnect** + - params [] +- **delegate** + - params [`pubkey`, `conditions query string`] + - result `nip26 delegation token` +- **get_relays** + - params [] + - result `{ [url: string]: {read: boolean, write: boolean} }` +- **nip04_encrypt** + - params [`pubkey`, `plaintext`] + - result `nip4 ciphertext` +- **nip04_decrypt** + - params [`pubkey`, `nip4 ciphertext`] + - result [`plaintext`] + + +NOTICE: `pubkey` and `signature` are hex-encoded strings. + + +### Nostr Connect URI + +**Signer** discovers **App** by scanning a QR code, clicking on a deep link or copy-pasting an URI. + +The **App** generates a special URI with prefix `nostrconnect://` and base path the hex-encoded `pubkey` with the following querystring parameters **URL encoded** + +- `relay` URL of the relay of choice where the **App** is connected and the **Signer** must send and listen for messages. +- `metadata` metadata JSON of the **App** + - `name` human-readable name of the **App** + - `url` (optional) URL of the website requesting the connection + - `description` (optional) description of the **App** + - `icons` (optional) array of URLs for icons of the **App**. + +#### JavaScript + +```js +const uri = `nostrconnect://?relay=${encodeURIComponent("wss://relay.damus.io")}&metadata=${encodeURIComponent(JSON.stringify({"name": "Example"}))}` +``` + +#### Example +```sh +nostrconnect://b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558e9d4?relay=wss%3A%2F%2Frelay.damus.io&metadata=%7B%22name%22%3A%22Example%22%7D +``` + + + +## Flows + +The `content` field contains encrypted message as specified by [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md). The `kind` chosen is `24133`. + +### Connect + +1. User clicks on **"Connect"** button on a website or scan it with a QR code +2. It will show an URI to open a "nostr connect" enabled **Signer** +3. In the URI there is a pubkey of the **App** ie. `nostrconnect://&relay=&metadata=` +4. The **Signer** will send a message to ACK the `connect` request, along with his public key + +### Disconnect (from App) + +1. User clicks on **"Disconnect"** button on the **App** +2. The **App** will send a message to the **Signer** with a `disconnect` request +3. The **Signer** will send a message to ACK the `disconnect` request + +### Disconnect (from Signer) + +1. User clicks on **"Disconnect"** button on the **Signer** +2. The **Signer** will send a message to the **App** with a `disconnect` request + + +### Get Public Key + +1. The **App** will send a message to the **Signer** with a `get_public_key` request +3. The **Signer** will send back a message with the public key as a response to the `get_public_key` request + +### Sign Event + +1. The **App** will send a message to the **Signer** with a `sign_event` request along with the **event** to be signed +2. The **Signer** will show a popup to the user to inspect the event and sign it +3. The **Signer** will send back a message with the schnorr `signature` of the event as a response to the `sign_event` request + +### Delegate + +1. The **App** will send a message with metadata to the **Signer** with a `delegate` request along with the **conditions** query string and the **pubkey** of the **App** to be delegated. +2. The **Signer** will show a popup to the user to delegate the **App** to sign on his behalf +3. The **Signer** will send back a message with the signed [NIP-26 delegation token](https://github.com/nostr-protocol/nips/blob/master/26.md) or reject it + + diff --git a/README.md b/README.md index e45c531b..25e5861a 100644 --- a/README.md +++ b/README.md @@ -30,6 +30,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh - [NIP-36: Sensitive Content](36.md) - [NIP-40: Expiration Timestamp](40.md) - [NIP-42: Authentication of clients to relays](42.md) +- [NIP-46: Nostr Connect](46.md) - [NIP-50: Keywords filter](50.md) - [NIP-56: Reporting](56.md) - [NIP-57: Lightning Zaps](57.md) @@ -56,6 +57,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh | 9735 | Zap | [57](57.md) | | 10002 | Relay List Metadata | [65](65.md) | | 22242 | Client Authentication | [42](42.md) | +| 24133 | Nostr Connect | [46](46.md) | | 30023 | Long-form Content | [23](23.md) | | 1000-9999 | Regular Events | [16](16.md) | | 10000-19999 | Replaceable Events | [16](16.md) | From 050317409d92aaab9007408f4bd5b206cdada1d7 Mon Sep 17 00:00:00 2001 From: Alejandro Gomez Date: Tue, 21 Feb 2023 20:08:46 +0100 Subject: [PATCH 03/22] NIP-57: add optional a tag for tipping nip-33 coordinates --- 57.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/57.md b/57.md index f6fa4ccf..bbeb629d 100644 --- a/57.md +++ b/57.md @@ -30,7 +30,7 @@ Having lightning receipts on nostr allows clients to display lightning payments 3. Clients may choose to display a lightning zap button on each post or on the users profile, if the user's lnurl pay request endpoint supports nostr, the client SHOULD generate a `zap invoice` instead of a normal lnurl invoice. -4. To generate a `zap invoice`, call the `callback` url with `amount` set to the milli-satoshi amount value. A `nostr` querystring value MUST be set as well. It is a uri-encoded `zap request` note signed by the user's key. The `zap request` note contains an `e` tag of the note it is zapping, and a `p` tag of the target user's pubkey. The `e` tag is optional which allows profile tipping. The `zap request` note must also have a `relays` tag, which is gathered from the user's configured relays. The `zap request` note SHOULD contain an `amount` tag, which is the milli-satoshi value of the zap which clients SHOULD verify being equal to the amount of the invoice. The `content` MAY be an additional comment from the user which can be displayed when listing zaps on posts and profiles. +4. To generate a `zap invoice`, call the `callback` url with `amount` set to the milli-satoshi amount value. A `nostr` querystring value MUST be set as well. It is a uri-encoded `zap request` note signed by the user's key. The `zap request` note contains an `e` tag of the note it is zapping, and a `p` tag of the target user's pubkey. The `e` tag is optional which allows profile tipping. An optional `a` tag allows tipping parameterized replaceable events such as NIP-23 long-form notes. The `zap request` note must also have a `relays` tag, which is gathered from the user's configured relays. The `zap request` note SHOULD contain an `amount` tag, which is the milli-satoshi value of the zap which clients SHOULD verify being equal to the amount of the invoice. The `content` MAY be an additional comment from the user which can be displayed when listing zaps on posts and profiles. 5. Pay this invoice or pass it to an app that can pay the invoice. Once it's paid, a `zap note` will be created by the `zapper`. @@ -58,6 +58,8 @@ The lnurl server will need some additional pieces of information so that clients f. If there is an `amount` tag, it MUST be equal to the `amount` query parameter. + g. If there is an `a` tag, it MUST be a valid NIP-33 event coordinate + 5. If valid, fetch a description hash invoice where the description is this note and this note only. No additional lnurl metadata is included in the description. At this point, the lightning node is ready to send the zap note once payment is received. From 2a4c44035e56580fb22929972a69280236663557 Mon Sep 17 00:00:00 2001 From: Brandon Lucas Date: Wed, 22 Feb 2023 19:14:07 -0500 Subject: [PATCH 04/22] Fix minor typo Fix spelling of `coordinates` in Note --- 04.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/04.md b/04.md index 0ebcddb9..bafc5c7e 100644 --- a/04.md +++ b/04.md @@ -14,7 +14,7 @@ A special event with kind `4`, meaning "encrypted direct message". It is suppose **`tags`** MAY contain an entry identifying the previous message in a conversation or a message we are explicitly replying to (such that contextual, more organized conversations may happen), in the form `["e", ""]`. -**Note**: By default in the [libsecp256k1](https://github.com/bitcoin-core/secp256k1) ECDH implementation, the secret is the SHA256 hash of the shared point (both X and Y coorinates). In Nostr, only the X coordinate of the shared point is used as the secret and it is NOT hashed. If using libsecp256k1, a custom function that copies the X coordinate must be passed as the `hashfp` argument in `secp256k1_ecdh`. See [here](https://github.com/bitcoin-core/secp256k1/blob/master/src/modules/ecdh/main_impl.h#L29). +**Note**: By default in the [libsecp256k1](https://github.com/bitcoin-core/secp256k1) ECDH implementation, the secret is the SHA256 hash of the shared point (both X and Y coordinates). In Nostr, only the X coordinate of the shared point is used as the secret and it is NOT hashed. If using libsecp256k1, a custom function that copies the X coordinate must be passed as the `hashfp` argument in `secp256k1_ecdh`. See [here](https://github.com/bitcoin-core/secp256k1/blob/master/src/modules/ecdh/main_impl.h#L29). Code sample for generating such an event in JavaScript: From 405cf480e9f6d419eb5b3516b7acdd1fc5759248 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ricardo=20Arturo=20Cabral=20Mej=C3=ADa?= Date: Wed, 22 Feb 2023 20:11:55 -0500 Subject: [PATCH 05/22] docs: add nip-58 badge event and profile badges (#229) --- 58.md | 132 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 7 +-- 2 files changed, 136 insertions(+), 3 deletions(-) create mode 100644 58.md diff --git a/58.md b/58.md new file mode 100644 index 00000000..2fa44066 --- /dev/null +++ b/58.md @@ -0,0 +1,132 @@ +NIP-58 +====== + +Badges +------ + +`draft` `optional` `author:cameri` + +Three special events are used to define, award and display badges in +user profiles: + +1. A "Badge Definition" event is defined as a parameterized replaceable event +with kind `30009` having a `d` tag with a value that uniquely identifies +the badge (e.g. `bravery`) published by the badge issuer. Badge definitions can +be updated. + +2. A "Badge Award" event is a kind `8` event with a single `a` tag referencing +a "Define Badge" event and one or more `p` tags, one for each pubkey the +badge issuer wishes to award. The value for the `a` tag MUST follow the format +defined in [NIP-33](33.md). Awarded badges are immutable and non-transferrable. + +3. A "Profile Badges" event is defined as a parameterized replaceable event +with kind `30008` with a `d` tag with the value `profile_badges`. +Profile badges contain an ordered list of pairs of `a` and `e` tags referencing a `Badge Definition` and a `Badge Award` for each badge to be displayed. + +### Badge Definition event + +The following tags MUST be present: + +- `d` tag with the unique name of the badge. + +The following tags MAY be present: + +- A `name` tag with a short name for the badge. +- `image` tag whose value is the URL of a high-resolution image representing the badge. The second value optionally specifies the dimensions of the image as `width`x`height` in pixels. Badge recommended dimensions is 1024x1024 pixels. +- A `description` tag whose value MAY contain a textual representation of the +image, the meaning behind the badge, or the reason of it's issuance. +- One or more `thumb` tags whose first value is an URL pointing to a thumbnail version of the image referenced in the `image` tag. The second value optionally specifies the dimensions of the thumbnail as `width`x`height` in pixels. + +### Badge Award event + +The following tags MUST be present: + +- An `a` tag referencing a kind `30009` Badge Definition event. +- One or more `p` tags referencing each pubkey awarded. + +### Profile Badges Event + +The number of badges a pubkey can be awarded is unbounded. The Profile Badge +event allows individual users to accept or reject awarded badges, as well +as choose the display order of badges on their profiles. + +The following tags MUST be present: + +- A `d` tag with the unique identifier `profile_badges` + +The following tags MAY be present: + +- Zero or more ordered consecutive pairs of `a` and `e` tags referencing a kind `30009` Badge Definition and kind `8` Badge Award, respectively. Clients SHOULD +ignore `a` without corresponding `e` tag and viceversa. Badge Awards referenced +by the `e` tags should contain the same `a` tag. + +### Motivation + +Users MAY be awarded badges (but not limited to) in recognition, in gratitude, for participation, or in appreciation of a certain goal, task or cause. + +Users MAY choose to decorate their profiles with badges for fame, notoriety, recognition, support, etc., from badge issuers they deem reputable. + +### Recommendations + +Badge issuers MAY include some Proof of Work as per [NIP-13](13.md) when minting Badge Definitions or Badge Awards to embed them with a combined energy cost, arguably making them more special and valuable for users that wish to collect them. + +Clients MAY whitelist badge issuers (pubkeys) for the purpose of ensuring they retain a valuable/special factor for their users. + +Badge image recommended aspect ratio is 1:1 with a high-res size of 1024x1024 pixels. + +Badge thumbnail image recommended dimensions are: 512x512 (xl), 256x256 (l), 64x64 (m), 32x32 (s) and 16x16 (xs). + +Clients MAY choose to render less badges than those specified by users in the Profile Badges event or replace the badge image and thumbnails with ones that fits the theme of the client. + +Clients SHOULD attempt to render the most appropriate badge thumbnail according to the number of badges chosen by the user and space available. Clients SHOULD attempt render the high-res version on user action (click, tap, hover). + +### Example of a Badge Definition event + +```json +{ + "pubkey": "alice", + "kind": 30009, + "tags": [ + ["d", "bravery"], + ["name", "Medal of Bravery"], + ["description", "Awarded to users demonstrating bravery"], + ["image", "https://nostr.academy/awards/bravery.png", "1024x1024"], + ["thumb", "https://nostr.academy/awards/bravery_256x256.png", "256x256"], + ], + ... +} +``` + +### Example of Badge Award event + +```json +{ + "id": "", + "kind": 8, + "pubkey": "alice", + "tags": [ + ["a", "30009:alice:bravery"], + ["p", "bob", "wss://relay"], + ["p", "charlie", "wss://relay"], + ], + ... +} +``` + +### Example of a Profile Badges event + +Honorable Bob The Brave: +```json +{ + "kind": 30008, + "pubkey": "bob", + "tags": [ + ["d", "profile_badges"], + ["a", "30009:alice:bravery"], + ["e", "", "wss://nostr.academy"], + ["a", "30009:alice:honor"], + ["e", "", "wss://nostr.academy"], + ], + ... +} +``` diff --git a/README.md b/README.md index 25e5861a..24106e1e 100644 --- a/README.md +++ b/README.md @@ -30,7 +30,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh - [NIP-36: Sensitive Content](36.md) - [NIP-40: Expiration Timestamp](40.md) - [NIP-42: Authentication of clients to relays](42.md) -- [NIP-46: Nostr Connect](46.md) +- [NIP-46: Nostr Connect](46.md) - [NIP-50: Keywords filter](50.md) - [NIP-56: Reporting](56.md) - [NIP-57: Lightning Zaps](57.md) @@ -46,6 +46,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh | 4 | Encrypted Direct Messages | [4](04.md) | | 5 | Event Deletion | [9](09.md) | | 7 | Reaction | [25](25.md) | +| 8 | Badge Award | [58](58.md) | | 40 | Channel Creation | [28](28.md) | | 41 | Channel Metadata | [28](28.md) | | 42 | Channel Message | [28](28.md) | @@ -63,8 +64,8 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh | 10000-19999 | Replaceable Events | [16](16.md) | | 20000-29999 | Ephemeral Events | [16](16.md) | | 30000-39999 | Parameterized Replaceable Events | [33](33.md) | - - +| 30008 | Profile Badges | [58](58.md) | +| 30009 | Badge Definition | [58](58.md) | ## Message types From 127d5518bfa9a4e4e7510490c0b8d95e342dfa4b Mon Sep 17 00:00:00 2001 From: barkyq <122579762+barkyq@users.noreply.github.com> Date: Thu, 23 Feb 2023 14:20:10 -0500 Subject: [PATCH 06/22] relay hint language update (#291) --- 10.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/10.md b/10.md index c0ef9d19..64947967 100644 --- a/10.md +++ b/10.md @@ -43,8 +43,8 @@ They are citings from this event. `root-id` and `reply-id` are as above. Where: * `` is the id of the event being referenced. - * `` is the URL of a recommended relay associated with the reference. It is NOT optional. - * `` is optional and if present is one of `"reply"`, `"root"`, or `"mention"` + * `` is the URL of a recommended relay associated with the reference. Clients SHOULD add a valid `` field, but may instead leave it as `""`. + * `` is optional and if present is one of `"reply"`, `"root"`, or `"mention"`. **The order of marked "e" tags is not relevant.** Those marked with `"reply"` denote the id of the reply event being responded to. Those marked with `"root"` denote the root id of the reply thread being responded to. For top level replies (those replying directly to the root event), only the `"root"` marker should be used. Those marked with `"mention"` denote a quoted or reposted event id. From 379252f992c2528e287bc4ce7faee5631aa3f73c Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sat, 25 Feb 2023 13:54:27 -0300 Subject: [PATCH 07/22] explicitly prohibit markdown on kind:1. --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/01.md b/01.md index 68efc6fc..12b5ba9a 100644 --- a/01.md +++ b/01.md @@ -98,7 +98,7 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated. ## Basic Event Kinds - `0`: `set_metadata`: the `content` is set to a stringified JSON object `{name: , about: , picture: }` describing the user who created the event. A relay may delete past `set_metadata` events once it gets a new one for the same pubkey. - - `1`: `text_note`: the `content` is set to the text content of a note (anything the user wants to say). Non-plaintext notes should instead use kind 1000-10000 as described in [NIP-16](16.md). + - `1`: `text_note`: the `content` is set to the plaintext content of a note (anything the user wants to say). Markdown links (`[]()` stuff) are not plaintext. - `2`: `recommend_server`: the `content` is set to the URL (e.g., `wss://somerelay.com`) of a relay the event creator wants to recommend to its followers. A relay may choose to treat different message kinds differently, and it may or may not choose to have a default way to handle kinds it doesn't know about. From ab1f26a3fd8fa0703a4be76091566c92aeadbd4b Mon Sep 17 00:00:00 2001 From: Callum Macdonald Date: Sat, 25 Feb 2023 12:23:46 +0100 Subject: [PATCH 08/22] Add browsers to the extension list --- 07.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/07.md b/07.md index 8ebb4d99..6c9f2b32 100644 --- a/07.md +++ b/07.md @@ -24,7 +24,7 @@ async window.nostr.nip04.decrypt(pubkey, ciphertext): string // takes ciphertext ### Implementation -- [nos2x](https://github.com/fiatjaf/nos2x) -- [Alby](https://getalby.com) -- [Blockcore](https://www.blockcore.net/wallet) -- [nos2x-fox](https://diegogurpegui.com/nos2x-fox/) +- [nos2x](https://github.com/fiatjaf/nos2x) (Chrome and derivatives) +- [Alby](https://getalby.com) (Chrome and derivatives, Firefox, Safari) +- [Blockcore](https://www.blockcore.net/wallet) (Chrome and derivatives) +- [nos2x-fox](https://diegogurpegui.com/nos2x-fox/) (Firefox) From 5a80a906d41a2d756a01addb50f6bead0061fb29 Mon Sep 17 00:00:00 2001 From: Mike O'Bank <111360219+mikeobank@users.noreply.github.com> Date: Sat, 25 Feb 2023 07:02:48 +0100 Subject: [PATCH 09/22] Improve `` specification - "random" is not an accurate description - I've noticed long (sha256 hashes in hex) being rejected by some relays. So there seems a need to specify a max length. - "non empty", cause an empty string could be interpreted as `null` To be decided: - Max length number - Are `subscription_id`s case sensitive? - Will `subscription_id`s be white space trimmed? --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/01.md b/01.md index 12b5ba9a..d32903b9 100644 --- a/01.md +++ b/01.md @@ -55,7 +55,7 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th * `["REQ", , ...]`, used to request events and subscribe to new updates. * `["CLOSE", ]`, used to stop previous subscriptions. -`` is a random string that should be used to represent a subscription. +`` is an arbitrary, non-empty string of max length 64 chars, that should be used to represent a subscription. `` is a JSON object that determines what events will be sent in that subscription, it can have the following attributes: From 2bf08b34874bc040cc257b46806cc682b56e6b50 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ricardo=20Arturo=20Cabral=20Mej=C3=ADa?= Date: Sat, 25 Feb 2023 10:17:33 -0500 Subject: [PATCH 10/22] docs: add nip-58 to readme --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 24106e1e..77f97c00 100644 --- a/README.md +++ b/README.md @@ -34,6 +34,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh - [NIP-50: Keywords filter](50.md) - [NIP-56: Reporting](56.md) - [NIP-57: Lightning Zaps](57.md) +- [NIP-58: Badges](58.md) - [NIP-65: Relay List Metadata](65.md) ## Event Kinds From d70959aee6f8e6e2f2bff02898c0281a64c53a8d Mon Sep 17 00:00:00 2001 From: Marco Argentieri <3596602+tiero@users.noreply.github.com> Date: Mon, 27 Feb 2023 18:22:46 +0100 Subject: [PATCH 11/22] Amend nip46 describe and delegate methods (#304) --- 46.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/46.md b/46.md index a9f37c1b..6589fc00 100644 --- a/46.md +++ b/46.md @@ -61,7 +61,7 @@ These are mandatory methods the remote signer app MUST implement: - **describe** - params [] - - result `{"get_public_key": { params: [], result: anything }}` + - result `["describe", "get_public_key", "sign_event", "connect", "disconnect", "delegate", ...]` - **get_public_key** - params [] - result `pubkey` @@ -77,8 +77,8 @@ These are mandatory methods the remote signer app MUST implement: - **disconnect** - params [] - **delegate** - - params [`pubkey`, `conditions query string`] - - result `nip26 delegation token` + - params [`delegatee`, `{ kind: number, since: number, until: number }`] + - result `{ from: string, to: string, cond: string, sig: string }` - **get_relays** - params [] - result `{ [url: string]: {read: boolean, write: boolean} }` From b549a9809f94ca703b3b63b73cdacc5407a2edd0 Mon Sep 17 00:00:00 2001 From: Sepehr Safari Date: Mon, 27 Feb 2023 23:51:22 +0330 Subject: [PATCH 12/22] Update README.md fixed a tiny tipo --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 77f97c00..8ee8b858 100644 --- a/README.md +++ b/README.md @@ -84,7 +84,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh | EVENT | used to send events requested to clients | [1](01.md) | | NOTICE | used to send human-readable messages to clients | [1](01.md) | | EOSE | used to notify clients all stored events have been sent | [15](15.md) | -| OK | used to notify clients if an EVENT was successuful | [20](20.md) | +| OK | used to notify clients if an EVENT was successful | [20](20.md) | | AUTH | used to send authentication challenges | [42](42.md) | Please update these lists when proposing NIPs introducing new event kinds. From c4949ea7078ec96a373f77f725267b36316ee9e4 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Thu, 23 Feb 2023 18:25:55 -0300 Subject: [PATCH 13/22] NIP-78: app-specific data. --- 78.md | 21 +++++++++++++++++++++ README.md | 6 ++++-- 2 files changed, 25 insertions(+), 2 deletions(-) create mode 100644 78.md diff --git a/78.md b/78.md new file mode 100644 index 00000000..175f66b1 --- /dev/null +++ b/78.md @@ -0,0 +1,21 @@ +NIP-78 +====== + +Arbitrary custom app data +------------------------- + +`draft` `optional` `author:sandwich` `author:fiatjaf` + +The goal of this NIP is to enable [remoteStorage](https://remotestorage.io/)-like capabilities for custom applications that do not care about interoperability. + +Even though interoperability is great, some apps do not want or do not need interoperability, and it that wouldn't make sense for them. Yet Nostr can still serve as a generalized data storage for these apps in a "bring your own database" way, for example: a user would open an app and somehow input their preferred relay for storage, which would then enable these apps to store application-specific data there. + +## Nostr event + +This NIP specifies the use of event kind `30078` (parameterized replaceable event) with a `d` tag containing some reference to the app name and context -- or any other arbitrary string. `content` and other `tags` can be anything or in any format. + +## Some use cases + + - User personal settings on Nostr clients (and other apps unrelated to Nostr) + - A way for client developers to propagate dynamic parameters to users without these having to update + - Personal private data generated by apps that have nothing to do with Nostr, but allow users to use Nostr relays as their personal database diff --git a/README.md b/README.md index 8ee8b858..91ad0e82 100644 --- a/README.md +++ b/README.md @@ -36,6 +36,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh - [NIP-57: Lightning Zaps](57.md) - [NIP-58: Badges](58.md) - [NIP-65: Relay List Metadata](65.md) +- [NIP-78: Application-specific data](78.md) ## Event Kinds | kind | description | NIP | @@ -60,13 +61,14 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh | 10002 | Relay List Metadata | [65](65.md) | | 22242 | Client Authentication | [42](42.md) | | 24133 | Nostr Connect | [46](46.md) | +| 30008 | Profile Badges | [58](58.md) | +| 30009 | Badge Definition | [58](58.md) | | 30023 | Long-form Content | [23](23.md) | +| 30078 | Application-specific Data | [78](78.md) | | 1000-9999 | Regular Events | [16](16.md) | | 10000-19999 | Replaceable Events | [16](16.md) | | 20000-29999 | Ephemeral Events | [16](16.md) | | 30000-39999 | Parameterized Replaceable Events | [33](33.md) | -| 30008 | Profile Badges | [58](58.md) | -| 30009 | Badge Definition | [58](58.md) | ## Message types From ab6308c29aa8cc10c06addc9fd26c90f8dac9c6a Mon Sep 17 00:00:00 2001 From: ennmichael Date: Thu, 2 Mar 2023 21:27:50 +0100 Subject: [PATCH 14/22] NIP-20: fix a typo --- 20.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/20.md b/20.md index 49e2396a..7e97dd91 100644 --- a/20.md +++ b/20.md @@ -82,7 +82,7 @@ Client Handling For the `pow:` prefix it may query relay metadata to get the updated difficulty requirement and try again in the background. -For the `invalid:` and `blocked`: prefix the client may wish to show these as styled error popups. +For the `invalid:` and `blocked:` prefix the client may wish to show these as styled error popups. The prefixes include a colon so that the message can be cleanly separated from the prefix by taking everything after `:` and trimming it. From c74f11b7a921276849f4d0eebc3a90a6a3edf2c1 Mon Sep 17 00:00:00 2001 From: Josua Schmid Date: Fri, 3 Mar 2023 22:29:39 +0100 Subject: [PATCH 15/22] Update NIP-01 to clarify pubkey reference We mean to reference any public key. "the key" was a bit unspecific. --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/01.md b/01.md index d32903b9..0e68de5e 100644 --- a/01.md +++ b/01.md @@ -22,7 +22,7 @@ The only object type that exists is the `event`, which has the following format "kind": , "tags": [ ["e", <32-bytes hex of the id of another event>, ], - ["p", <32-bytes hex of the key>, ], + ["p", <32-bytes hex of a pubkey>, ], ... // other kinds of tags may be included later ], "content": , From d97928bd9024a988be6c9f7ec18c0fcf93a8b9a3 Mon Sep 17 00:00:00 2001 From: ennmichael Date: Sun, 5 Mar 2023 21:43:14 +0100 Subject: [PATCH 16/22] avoid using substr in NIP-04 example --- 04.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/04.md b/04.md index bafc5c7e..153456ae 100644 --- a/04.md +++ b/04.md @@ -23,7 +23,7 @@ import crypto from 'crypto' import * as secp from 'noble-secp256k1' let sharedPoint = secp.getSharedSecret(ourPrivateKey, '02' + theirPublicKey) -let sharedX = sharedPoint.substr(2, 64) +let sharedX = sharedPoint.slice(2, 67) let iv = crypto.randomFillSync(new Uint8Array(16)) var cipher = crypto.createCipheriv( From b8e657bb3764af8bec952a6e3d5d8d3319abccf9 Mon Sep 17 00:00:00 2001 From: shafemtol Date: Sun, 5 Mar 2023 20:49:57 +0000 Subject: [PATCH 17/22] NIP-08: Specify nonmatch behavior --- 08.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/08.md b/08.md index 5dbb695f..113cb539 100644 --- a/08.md +++ b/08.md @@ -15,3 +15,5 @@ Once a mention is identified, for example, the pubkey `27866e9d854c78ae625b867ee The same process applies for mentioning event IDs. A client that receives a `text_note` event with such `#[index]` mentions in its `.content` CAN do a search-and-replace using the actual contents from the `.tags` array with the actual pubkey or event ID that is mentioned, doing any desired context augmentation (for example, linking to the pubkey or showing a preview of the mentioned event contents) it wants in the process. + +Where `#[index]` has an `index` that is outside the range of the tags array or points to a tag that is not an `e` or `p` tag or a tag otherwise declared to support this notation, the client MUST NOT perform such replacement or augmentation, but instead display it as normal text. From c233b3ffd0209a68a31a305fa1e8a7305137ece2 Mon Sep 17 00:00:00 2001 From: rain8128 <126866571+rain8128@users.noreply.github.com> Date: Tue, 7 Mar 2023 03:14:45 +0900 Subject: [PATCH 18/22] Update 02.md --- 02.md | 1 + 1 file changed, 1 insertion(+) diff --git a/02.md b/02.md index ba1ae60e..2f199080 100644 --- a/02.md +++ b/02.md @@ -22,6 +22,7 @@ For example: ], "content": "", ...other fields +} ``` Every new contact list that gets published overwrites the past ones, so it should contain all entries. Relays and clients SHOULD delete past contact lists as soon as they receive a new one. From b99723efcca383affd43eb2efb5b25c949346588 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Tue, 28 Feb 2023 20:36:21 -0300 Subject: [PATCH 19/22] add flamingo extension. --- 07.md | 1 + 1 file changed, 1 insertion(+) diff --git a/07.md b/07.md index 6c9f2b32..ad26d2fd 100644 --- a/07.md +++ b/07.md @@ -28,3 +28,4 @@ async window.nostr.nip04.decrypt(pubkey, ciphertext): string // takes ciphertext - [Alby](https://getalby.com) (Chrome and derivatives, Firefox, Safari) - [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 6eb18389212430f91f293f7a57895b05b9e37e13 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Tue, 7 Mar 2023 07:28:53 -0300 Subject: [PATCH 20/22] remove reserved range from NIP-28. --- 28.md | 8 +------- README.md | 59 +++++++++++++++++++++++++++---------------------------- 2 files changed, 30 insertions(+), 37 deletions(-) diff --git a/28.md b/28.md index 0862e72d..d72e7ab0 100644 --- a/28.md +++ b/28.md @@ -9,7 +9,7 @@ Public Chat This NIP defines new event kinds for public chat channels, channel messages, and basic client-side moderation. -It reserves five event kinds (40-44) for immediate use and five event kinds (45-49) for future use. +It reserves five event kinds (40-44) for immediate use: - `40 - channel create` - `41 - channel metadata` @@ -138,12 +138,6 @@ For [NIP-10](10.md) relay recommendations, clients generally SHOULD use the rela Clients MAY recommend any relay URL. For example, if a relay hosting the original kind 40 event for a channel goes offline, clients could instead fetch channel data from a backup relay, or a relay that clients trust more than the original relay. -Future extensibility --------------------- - -We reserve event kinds 45-49 for other events related to chat, to potentially include new types of media (photo/video), moderation, or support of private or group messaging. - - Motivation ---------- If we're solving censorship-resistant communication for social media, we may as well solve it also for Telegram-style messaging. diff --git a/README.md b/README.md index 91ad0e82..42674cce 100644 --- a/README.md +++ b/README.md @@ -39,36 +39,35 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh - [NIP-78: Application-specific data](78.md) ## Event Kinds -| kind | description | NIP | -| ------------- | -------------------------------- | ----------------------- | -| 0 | Metadata | [1](01.md), [5](05.md) | -| 1 | Short Text Note | [1](01.md) | -| 2 | Recommend Relay | [1](01.md) | -| 3 | Contacts | [2](02.md) | -| 4 | Encrypted Direct Messages | [4](04.md) | -| 5 | Event Deletion | [9](09.md) | -| 7 | Reaction | [25](25.md) | -| 8 | Badge Award | [58](58.md) | -| 40 | Channel Creation | [28](28.md) | -| 41 | Channel Metadata | [28](28.md) | -| 42 | Channel Message | [28](28.md) | -| 43 | Channel Hide Message | [28](28.md) | -| 44 | Channel Mute User | [28](28.md) | -| 45-49 | Public Chat Reserved | [28](28.md) | -| 1984 | Reporting | [56](56.md) | -| 9734 | Zap Request | [57](57.md) | -| 9735 | Zap | [57](57.md) | -| 10002 | Relay List Metadata | [65](65.md) | -| 22242 | Client Authentication | [42](42.md) | -| 24133 | Nostr Connect | [46](46.md) | -| 30008 | Profile Badges | [58](58.md) | -| 30009 | Badge Definition | [58](58.md) | -| 30023 | Long-form Content | [23](23.md) | -| 30078 | Application-specific Data | [78](78.md) | -| 1000-9999 | Regular Events | [16](16.md) | -| 10000-19999 | Replaceable Events | [16](16.md) | -| 20000-29999 | Ephemeral Events | [16](16.md) | -| 30000-39999 | Parameterized Replaceable Events | [33](33.md) | +| kind | description | NIP | +| ------------- | -------------------------------- | ----------- | +| 0 | Metadata | [1](01.md) | +| 1 | Short Text Note | [1](01.md) | +| 2 | Recommend Relay | [1](01.md) | +| 3 | Contacts | [2](02.md) | +| 4 | Encrypted Direct Messages | [4](04.md) | +| 5 | Event Deletion | [9](09.md) | +| 7 | Reaction | [25](25.md) | +| 8 | Badge Award | [58](58.md) | +| 40 | Channel Creation | [28](28.md) | +| 41 | Channel Metadata | [28](28.md) | +| 42 | Channel Message | [28](28.md) | +| 43 | Channel Hide Message | [28](28.md) | +| 44 | Channel Mute User | [28](28.md) | +| 1984 | Reporting | [56](56.md) | +| 9734 | Zap Request | [57](57.md) | +| 9735 | Zap | [57](57.md) | +| 10002 | Relay List Metadata | [65](65.md) | +| 22242 | Client Authentication | [42](42.md) | +| 24133 | Nostr Connect | [46](46.md) | +| 30008 | Profile Badges | [58](58.md) | +| 30009 | Badge Definition | [58](58.md) | +| 30023 | Long-form Content | [23](23.md) | +| 30078 | Application-specific Data | [78](78.md) | +| 1000-9999 | Regular Events | [16](16.md) | +| 10000-19999 | Replaceable Events | [16](16.md) | +| 20000-29999 | Ephemeral Events | [16](16.md) | +| 30000-39999 | Parameterized Replaceable Events | [33](33.md) | ## Message types From a8fab58526f3cafa9d511512e2881f505fbe1626 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Tue, 7 Mar 2023 07:31:21 -0300 Subject: [PATCH 21/22] add security warning on nip-04. --- 04.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/04.md b/04.md index 153456ae..63b1177f 100644 --- a/04.md +++ b/04.md @@ -43,3 +43,7 @@ let event = { content: encryptedMessage + '?iv=' + ivBase64 } ``` + +## Security Warning + +This standard does not go anywhere near what is considered the state-of-the-art in encrypted communication between peers, and it leaks metadata in the events, therefore it must not be used for anything you really need to keep secret, and only with relays that use `AUTH` to restrict who can read your `kind:4` events. From 2c055513519df1cb8f3fc0944f6a873e64771944 Mon Sep 17 00:00:00 2001 From: cj-ibex Date: Tue, 7 Mar 2023 21:38:32 -0600 Subject: [PATCH 22/22] make explicit that root event tag is compulsory --- 28.md | 1 + 1 file changed, 1 insertion(+) diff --git a/28.md b/28.md index d72e7ab0..169ae4f4 100644 --- a/28.md +++ b/28.md @@ -84,6 +84,7 @@ Reply to another message: { "content": , "tags": [ + ["e", , , "root"], ["e", , , "reply"], ["p", , ], ...