From cee69773473a9f6fed2cd7a150d70e77837a42b4 Mon Sep 17 00:00:00 2001 From: Ryan Breen Date: Wed, 1 Nov 2023 08:55:45 -0400 Subject: [PATCH 1/9] Adding Nostore to NIP-07 extension list. --- 07.md | 1 + 1 file changed, 1 insertion(+) diff --git a/07.md b/07.md index 24d8d456..51ddc165 100644 --- a/07.md +++ b/07.md @@ -35,3 +35,4 @@ async window.nostr.nip04.decrypt(pubkey, ciphertext): string // takes ciphertext - [Nostrmo](https://github.com/haorendashu/nostrmo_faq#download) (Android, IOS) - [Spring Browser](https://spring.site) (Android) - [nodestr](https://github.com/lightning-digital-entertainment/nodestr) (NodeJS polyfill) +- [Nostore](https://apps.apple.com/us/app/nostore/id1666553677) (Safari on iOS/MacOS) From b14b9d2120ea7fd287eb44249ce5910df7ad45d2 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Thu, 2 Nov 2023 19:46:35 -0300 Subject: [PATCH 2/9] nip-01: clarify that whitespace is allowed inside the strings. closes https://github.com/nostr-protocol/nips/pull/861 --- 01.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/01.md b/01.md index 2b28f23f..183e0ba2 100644 --- a/01.md +++ b/01.md @@ -29,9 +29,9 @@ The only object type that exists is the `event`, which has the following format } ``` -To obtain the `event.id`, we `sha256` the serialized event. The serialization is done over the UTF-8 JSON-serialized string (with no white space or line breaks) of the following structure: +To obtain the `event.id`, we `sha256` the serialized event. The serialization is done over the UTF-8 JSON-serialized string (with no white space or line breaks between the fields) of the following structure: -```json +``` [ 0, , From 08d3eff350d11657160eca78459da34d9254252b Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sat, 4 Nov 2023 16:55:28 -0300 Subject: [PATCH 3/9] 52: fix kinds (as ints). --- 52.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/52.md b/52.md index f5bd0adb..69507441 100644 --- a/52.md +++ b/52.md @@ -40,7 +40,7 @@ The list of tags are as follows: "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": "31922", + "kind": 31922, "content": "", "tags": [ ["d", ""], @@ -98,7 +98,7 @@ The list of tags are as follows: "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": "31923", + "kind": 31923, "content": "", "tags": [ ["d", ""], @@ -183,7 +183,7 @@ The list of tags are as follows: "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": "31925", + "kind": 31925, "content": "", "tags": [ ["a", "<31922 or 31923>::", ""], From 749c9b0a2d49d09ccbd00f6bdb4843182e334ddf Mon Sep 17 00:00:00 2001 From: jiftechnify Date: Wed, 25 Oct 2023 12:21:24 +0900 Subject: [PATCH 4/9] clearly define the term "READ/WRITE relay" --- 65.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/65.md b/65.md index b6760290..573e1df2 100644 --- a/65.md +++ b/65.md @@ -8,7 +8,7 @@ Relay List Metadata Defines a replaceable event using `kind:10002` to advertise preferred relays for discovering a user's content and receiving fresh content from others. -The event MUST include a list of `r` tags with relay URIs and a `read` or `write` marker. If the marker is omitted, the relay is used for both purposes. +The event MUST include a list of `r` tags with relay URIs and a `read` or `write` marker. Relays marked as `read` / `write` are called READ / WRITE relays, respectively. If the marker is omitted, the relay is used for both purposes. The `.content` is not used. @@ -27,7 +27,7 @@ The `.content` is not used. This NIP doesn't fully replace relay lists that are designed to configure a client's usage of relays (such as `kind:3` style relay lists). Clients MAY use other relay lists in situations where a `kind:10002` relay list cannot be found. -## When to Use Read and Write +## When to Use Read and Write Relays When seeking events **from** a user, Clients SHOULD use the WRITE relays of the user's `kind:10002` From 6b566e897cf0a75d9b6671e73bc614333b89d7ae Mon Sep 17 00:00:00 2001 From: jiftechnify Date: Wed, 25 Oct 2023 12:27:18 +0900 Subject: [PATCH 5/9] make the usage of punctuations uniform --- 65.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/65.md b/65.md index 573e1df2..939b2639 100644 --- a/65.md +++ b/65.md @@ -23,26 +23,27 @@ The `.content` is not used. ], "content": "", ...other fields +} ``` This NIP doesn't fully replace relay lists that are designed to configure a client's usage of relays (such as `kind:3` style relay lists). Clients MAY use other relay lists in situations where a `kind:10002` relay list cannot be found. ## When to Use Read and Write Relays -When seeking events **from** a user, Clients SHOULD use the WRITE relays of the user's `kind:10002` +When seeking events **from** a user, Clients SHOULD use the WRITE relays of the user's `kind:10002`. -When seeking events **about** a user, where the user was tagged, Clients SHOULD use the READ relays of the user's `kind:10002` +When seeking events **about** a user, where the user was tagged, Clients SHOULD use the READ relays of the user's `kind:10002`. When broadcasting an event, Clients SHOULD: - Broadcast the event to the WRITE relays of the author -- Broadcast the event all READ relays of each tagged user. +- Broadcast the event all READ relays of each tagged user ## Motivation The old model of using a fixed relay list per user centralizes in large relay operators: - - Most users submit their posts to the same highly popular relays, aiming to achieve greater visibility among a broader audience. + - Most users submit their posts to the same highly popular relays, aiming to achieve greater visibility among a broader audience - Many users are pulling events from a large number of relays in order to get more data at the expense of duplication - Events are being copied between relays, oftentimes to many different relays From 108b7f16f9f75157cffde590a55077e4dfe7c955 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Mon, 6 Nov 2023 13:18:11 -0300 Subject: [PATCH 6/9] clarify that the OK array must have 4 items. --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/01.md b/01.md index 183e0ba2..cb4f522d 100644 --- a/01.md +++ b/01.md @@ -150,7 +150,7 @@ Relays can send 4 types of messages, which must also be JSON arrays, according t This NIP defines no rules for how `NOTICE` messages should be sent or treated. - `EVENT` messages MUST be sent only with a subscription ID related to a subscription previously initiated by the client (using the `REQ` message above). -- `OK` messages MUST be sent in response to `EVENT` messages received from clients, they must have the 3rd parameter set to `true` when an event has been accepted by the relay, `false` otherwise. The 4th parameter MAY be empty when the 3rd is `true`, otherwise it MUST be a string containing a machine-readable single-word prefix followed by a `:` and then a human-readable message. The standardized machine-readable prefixes are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, and `error` for when none of that fits. Some examples: +- `OK` messages MUST be sent in response to `EVENT` messages received from clients, they must have the 3rd parameter set to `true` when an event has been accepted by the relay, `false` otherwise. The 4th parameter MUST always be present, but MAY be an empty string when the 3rd is `true`, otherwise it MUST be a string formed by a machine-readable single-word prefix followed by a `:` and then a human-readable message. The standardized machine-readable prefixes are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, and `error` for when none of that fits. Some examples: * `["OK", "b1a649ebe8...", true, ""]` * `["OK", "b1a649ebe8...", true, "pow: difficulty 25>=24"]` From b128ad98ade41b2b1f029e7460329554748fea73 Mon Sep 17 00:00:00 2001 From: Pablo Fernandez Date: Tue, 7 Nov 2023 14:16:43 +0200 Subject: [PATCH 7/9] NIP-84: Highlights (#501) Co-authored-by: Alejandro Co-authored-by: arthurfranca Co-authored-by: fiatjaf_ --- 84.md | 98 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 2 ++ 2 files changed, 100 insertions(+) create mode 100644 84.md diff --git a/84.md b/84.md new file mode 100644 index 00000000..b4a4be72 --- /dev/null +++ b/84.md @@ -0,0 +1,98 @@ +NIP-84 +====== + +Highlights +---------- + +`draft` `optional` `author:pablof7z` + +This NIP defines `kind:9802`, a "highlight" event, to signal content a user finds valuable. + +## Format +The `.content` of these events is the highlighted portion of the text. + +`.content` might be empty for highlights of non-text based media (e.g. NIP-94 audio/video). + +### References +Events SHOULD tag the source of the highlight, whether nostr-native or not. +`a` or `e` tags should be used for nostr events and `r` tags for URLs. + +When tagging a URL, clients generating these events SHOULD do a best effort of cleaning the URL from trackers +or obvious non-useful information from the query string. + +### Attribution +Clients MAY include one or more `p` tags, tagging the original authors of the material being highlighted; this is particularly +useful when highlighting non-nostr content for which the client might be able to get a nostr pubkey somehow +(e.g. prompting the user or reading a `` tag on the document). A role MAY be included as the +last value of the tag. + +```json +[ "p", "...", "author" ], +[ "p", "...", "author" ], +[ "p", "...", "editor" ], +``` + +### Context +Clients MAY include a `context` tag, useful when the highlight is a subset of a paragraph and displaying the +surrounding content might be beneficial to give context to the higlight. + +### Ranges +Clients MAY include `range` tags with the start/end indexes of where the highlight begins and finishes within +the referenced article/tagged-event. + +``` +[ "range", , ] +``` + +Additionally a range with `context` as the third value of the tag MAY be added to indicate the begin/finish indexes +of the highlight within the included `context` tag. + +``` +[ "range", , , "context" ] +``` + +#### Text-based nostr events' highlights + +Highlights of Nostr events SHOULD use the range index of the content as-is +(e.g. NIP-23 articles include the markdown instead of computing the index from the rendered markdown). + +``` +[ "range", 3000, 3042 ] # highlight begins at index position 3000 of the tagged event's `.content` +[ "range", 42, 84, "context" ] # highlight begins at index position 42 of the `context` tag's value +``` + +#### Non-text-based nostr events' highlights + +A `kind:9802` event that tags a NIP-94 event which includes a video or audio file can use ranges to +indicate the start/end time position in seconds. + +#### Ranges in URL highlights + +When creating a highlight from a URL the range should be expressed over +the extracted plain text of the formatted content (e.g. rendered HTML instead of including the HTML markup); +this helps make finding the correct indexes easier on websites with markup variations on each render. + +e.g. `hello, world` + +Tagging `hello, world` would result in using a range tag like `["range", 0, 12 ]`. + +Text extraction (i.e. translation from non-plain text medium like HTML or PDF) is highly subjective and the value +of the range should be carefully interpreted by the different clients that support this. + +```json +{ + "created_at": 1682707885, + "content": "while allowing creators to simply keep doing what they’re doing. Creators don’t need to be blatant shills for brands", + "tags": [ + [ "r", "https://footstr.com/zapvertise/" ], + [ "p", "c48e29f04b482cc01ca1f9ef8c86ef8318c059e0e9353235162f080f26e14c11", "wss://relay.url", "author" ], + [ "context", "The Nostr zapvertising model creates a truly free market for advertisers, while allowing creators to simply keep doing what they’re doing. Creators don’t need to be blatant shills for brands, they just have to create high quality content people find valuable, and companies will naturally want to zapvertise on their posts." ] + [ "range", 3916, 4032 ], + [ "range", 74, 190, "context" ], + ], + "kind": 9802, + "pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52", + "id": "59e5887a3cdf32d5f11edf9b8cd098c620d278514b2edde3e6d1ba8a541d262c", + "sig": "f2d15b8bc2csf6d198350f8df0a31dcf66d7c32ec9c54e6b3f102d579370b7de9d164d70350a5b32a2911db3b124e972bafa9a1bc8fd60c1e338903d2f6306b0" +} +``` diff --git a/README.md b/README.md index 8be05951..f818b043 100644 --- a/README.md +++ b/README.md @@ -66,6 +66,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos - [NIP-72: Moderated Communities](72.md) - [NIP-75: Zap Goals](75.md) - [NIP-78: Application-specific data](78.md) +- [NIP-84: Highlights](84.md) - [NIP-89: Recommended Application Handlers](89.md) - [NIP-90: Data Vending Machines](90.md) - [NIP-94: File Metadata](94.md) @@ -101,6 +102,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `9041` | Zap Goal | [75](75.md) | | `9734` | Zap Request | [57](57.md) | | `9735` | Zap | [57](57.md) | +| `9802` | Highlights | [84](84.md) | | `10000` | Mute List | [51](51.md) | | `10001` | Pin List | [51](51.md) | | `10002` | Relay List Metadata | [65](65.md) | From d85f9269ca300fb3bee627733c8086df4fcff875 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Tue, 7 Nov 2023 09:19:11 -0300 Subject: [PATCH 8/9] 84: fix markers example. --- 84.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/84.md b/84.md index b4a4be72..89bf88b1 100644 --- a/84.md +++ b/84.md @@ -27,9 +27,9 @@ useful when highlighting non-nostr content for which the client might be able to last value of the tag. ```json -[ "p", "...", "author" ], -[ "p", "...", "author" ], -[ "p", "...", "editor" ], +[ "p", "", "", "author" ], +[ "p", "", "", "author" ], +[ "p", "", "", "editor" ], ``` ### Context From 1d61e815d4072834ed40cd3309a3270e0f81ed98 Mon Sep 17 00:00:00 2001 From: Yoji Shidara Date: Wed, 8 Nov 2023 12:23:32 +0900 Subject: [PATCH 9/9] Update NIP-01 translation Reflecting changes of * b14b9d2120ea7fd287eb44249ce5910df7ad45d2 * 108b7f16f9f75157cffde590a55077e4dfe7c955 --- 01.md | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/01.md b/01.md index 9c0cac93..a53e3ce1 100644 --- a/01.md +++ b/01.md @@ -29,11 +29,7 @@ NIP-01 } ``` -<<<<<<< HEAD -`event.id`を得るため、そのイベントをシリアライズして`sha256`を計算します。具体的には、以下の構造をUTF-8 JSON文字列（ホワイトスペースや改行を含めない）としてシリアライズすることで行います。 -======= -To obtain the `event.id`, we `sha256` the serialized event. The serialization is done over the UTF-8 JSON-serialized string (with no white space or line breaks between the fields) of the following structure: ->>>>>>> en-source/master +`event.id`を得るため、そのイベントをシリアライズして`sha256`を計算します。具体的には、以下の構造をUTF-8 JSON文字列（フィールド間にはホワイトスペースや改行を含めない）としてシリアライズすることで行います。 ``` [ @@ -153,13 +149,8 @@ Kindはクライアントがイベントやイベントのフィールドをど このNIPでは`NOTICE`メッセージをどのように送信し、またどのように扱うべきかについてのルールは定義しません。 -<<<<<<< HEAD - `EVENT`メッセージは、クライアントが（前述の`REQ`メッセージを用いて）以前に開始した購読IDと紐付けられたものだけが送信されなければなりません（MUST）。 -- `OK`メッセージは、クライアントから受信した`EVENT`メッセージに対する返信として送信されなければなりません（MUST）。3番目のパラメータは、リレーがメッセージを受理する場合は`ture`を、そうでなければ`false`を指定しなければなりません。4番目のパラメータは、3番目が`true`である場合は空でもかまいません（MAY）が、そうでなければ機械可読な一語のプレフィクスに続けて`:`と人間可読なメッセージを含まなければなりません（MUST）。標準化されている機械可読なプレフィクスは、`duplicate`、`pow`、`blocked`、`rate-limited`、`invalid`と`error`（他のどれにも当てはまらない場合）です。例は以下の通りです。 -======= -- `EVENT` messages MUST be sent only with a subscription ID related to a subscription previously initiated by the client (using the `REQ` message above). -- `OK` messages MUST be sent in response to `EVENT` messages received from clients, they must have the 3rd parameter set to `true` when an event has been accepted by the relay, `false` otherwise. The 4th parameter MUST always be present, but MAY be an empty string when the 3rd is `true`, otherwise it MUST be a string formed by a machine-readable single-word prefix followed by a `:` and then a human-readable message. The standardized machine-readable prefixes are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, and `error` for when none of that fits. Some examples: ->>>>>>> en-source/master +- `OK`メッセージは、クライアントから受信した`EVENT`メッセージに対する返信として送信されなければなりません（MUST）。3番目のパラメータは、リレーがメッセージを受理する場合は`ture`を、そうでなければ`false`を指定しなければなりません。4番目のパラメータも必須で（MUST）、3番目が`true`である場合は空文字列でもかまいません（MAY）が、そうでなければ、機械可読な一語のプレフィクスに続けて`:`と人間可読なメッセージを含まなければなりません（MUST）。標準化されている機械可読なプレフィクスは、`duplicate`、`pow`、`blocked`、`rate-limited`、`invalid`と`error`（他のどれにも当てはまらない場合）です。例は以下の通りです。 * `["OK", "b1a649ebe8...", true, ""]` * `["OK", "b1a649ebe8...", true, "pow: difficulty 25>=24"]` pow: 難易度25は24以上