Merge pull request #18 from darashi/nip-01-update

Sync and NIP-01 update

01.md

@@ -29,9 +29,9 @@ NIP-01
 }
 ```
 
-`event.id`を得るため、そのイベントをシリアライズして`sha256`を計算します。具体的には、以下の構造をUTF-8 JSON文字列（ホワイトスペースや改行を含めない）としてシリアライズすることで行います。
+`event.id`を得るため、そのイベントをシリアライズして`sha256`を計算します。具体的には、以下の構造をUTF-8 JSON文字列（フィールド間にはホワイトスペースや改行を含めない）としてシリアライズすることで行います。
 
-```json
+```
 [
   0,
   <pubkey, as a lowercase hex string>,
@@ -150,7 +150,7 @@ Kindはクライアントがイベントやイベントのフィールドをど
 このNIPでは`NOTICE`メッセージをどのように送信し、またどのように扱うべきかについてのルールは定義しません。
 
 - `EVENT`メッセージは、クライアントが（前述の`REQ`メッセージを用いて）以前に開始した購読IDと紐付けられたものだけが送信されなければなりません（MUST）。
-- `OK`メッセージは、クライアントから受信した`EVENT`メッセージに対する返信として送信されなければなりません（MUST）。3番目のパラメータは、リレーがメッセージを受理する場合は`ture`を、そうでなければ`false`を指定しなければなりません。4番目のパラメータは、3番目が`true`である場合は空でもかまいません（MAY）が、そうでなければ機械可読な一語のプレフィクスに続けて`:`と人間可読なメッセージを含まなければなりません（MUST）。標準化されている機械可読なプレフィクスは、`duplicate`、`pow`、`blocked`、`rate-limited`、`invalid`と`error`（他のどれにも当てはまらない場合）です。例は以下の通りです。
+- `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以上

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)

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": <Unix timestamp in seconds>,
-  "kind": "31922",
+  "kind": 31922,
   "content": "<description of calendar event>",
   "tags": [
     ["d", "<UUID>"],
@@ -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": <Unix timestamp in seconds>,
-  "kind": "31923",
+  "kind": 31923,
   "content": "<description of calendar event>",
   "tags": [
     ["d", "<UUID>"],
@@ -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": <Unix timestamp in seconds>,
-  "kind": "31925",
+  "kind": 31925,
   "content": "<note>",
   "tags": [
     ["a", "<31922 or 31923>:<calendar event author pubkey>:<d-identifier of calendar event>", "<optional relay url>"],

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.
 
@@ -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
+## 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
 

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 `<meta name="nostr:nprofile1..." />` tag on the document). A role MAY be included as the
+last value of the tag.
+
+```json
+[ "p", "<pubkey-hex>", "<relay-url>", "author" ],
+[ "p", "<pubkey-hex>", "<relay-url>", "author" ],
+[ "p", "<pubkey-hex>", "<relay-url>", "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", <start-index>, <end-index> ]
+```
+
+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", <start-index>, <end-index>, "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. `<html><body>hello, world</body></html>`
+
+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"
+}
+```

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) |