Sync with upstream including CONFLICT

01.md

@@ -75,20 +75,36 @@ NIP-01
 
 このNIPでは標準的なタグを3つ定義する。これらのタグは、あらゆるイベントのkindにおいて同じ意味で用いられる。以下の通りだ。
 
+<<<<<<< HEAD
 - `e`タグ。イベントを参照するために用いる: `["e", <他のイベントIDの32バイト小文字16進数文字列>, <おすすめのリレーURL、省略可能>]`
 - `p`タグ。別のユーザを参照するために用いる: `["p", <pubkeyの32バイト小文字16進数文字列>, <おすすめのリレーURL、省略可能>]`
 - `a`タグ。アドレス指定可能 (addressable) または置換可能 (replaceable) イベントを参照するために用いる。
   - アドレス指定可能 (addressable) イベントの場合: `["a", <kind整数>:<pubkeyの32バイト小文字16進数文字列>:<dタグの値>, <おすすめリレーURL、省略可能>]`
   - 置換可能 (replaceable) イベントの場合: `["a", <kind整数>:<pubkeyの32バイト小文字16進数文字列>:, <おすすめリレーURL、省略可能>]`
+=======
+- The `e` tag, used to refer to an event: `["e", <32-bytes lowercase hex of the id of another event>, <recommended relay URL, optional>, <32-bytes lowercase hex of the author's pubkey, optional>]`
+- The `p` tag, used to refer to another user: `["p", <32-bytes lowercase hex of a pubkey>, <recommended relay URL, optional>]`
+- The `a` tag, used to refer to an addressable or replaceable event
+    - for an addressable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
+    - for a normal replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:, <recommended relay URL, optional>]`
+>>>>>>> upstream/master
 
 慣例として、全ての1文字(英語のアルファベットa-zとA-Zに限る)キーをもつタグは、リレーによってインデクスされることが期待される。これにより、例えば、イベント`"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"`を参照しているイベントをクエリしたり購読するために、`{"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]}`フィルタを使える。
 
 ### Kinds
 
+<<<<<<< HEAD
 Kindはクライアントがイベントやイベントのフィールドをどう解釈すべきかを決める(たとえば、`"r"`タグのkind 1における意味は、kind 10002のイベントにおける意味と全く異なる可能性がある)。それぞれのNIPにおいて、他の場所で定義されていないkindの意味を定義する可能性がある。このNIPでは、以下のように2つの基本的なkindを定義する。
 
 - `0`: **メタデータ**: `content`は文字列化されたJSONオブジェクト`{name: <ユーザ名>, about: <文字列>, picture: <URL、文字列>}`で、イベントを作成したユーザのことを記述する。リレーは、同一のpubkeyから新しいイベントを受信した際、過去のイベントを削除できる。
 - `1`: **テキスト投稿**: `content`はノート(ユーザが発言したいこと)を**プレーンテキスト**で指定する。パースが必要なコンテンツ(マークダウンやHTMLなど)を使用すべきではない。クライアントもコンテンツをそのようにパースをしてはならない。
+=======
+Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. [NIP-10](10.md), for instance, especifies the `kind:1` text note for social media applications.  
+
+This NIP defines one basic kind:
+
+- `0`: **user metadata**: the `content` is set to a stringified JSON object `{name: <nickname or full name>, about: <short bio>, picture: <url of the image>}` describing the user who created the event. [Extra metadata fields](24.md#kind-0) may be set. A relay may delete older events once it gets a new one for the same pubkey.
+>>>>>>> upstream/master
 
 実験を容易にし、リレーの実装を柔軟にするため、kindの範囲についての以下のような慣例もある。
 
@@ -160,6 +176,7 @@ Kindはクライアントがイベントやイベントのフィールドをど
 - `EVENT`メッセージは、クライアントが(前述の`REQ`メッセージを用いて)以前に開始した購読IDと紐付けられたものだけが送信されなければならない(MUST)。
 - `OK`メッセージは、クライアントから受信した`EVENT`メッセージに対する返信として送信されなければならない(MUST)。3番目のパラメータは、リレーがメッセージを受理する場合は`true`を、そうでなければ`false`を指定しなければならない。4番目のパラメータも必須で(MUST)、3番目が`true`の場合は空文字列でもかまわない(MAY)が、そうでなければ、機械可読な一語のプレフィクスに続けて`:`と人間可読なメッセージを含まなければならない(MUST)。例は以下の通り:
   * `["OK", "b1a649ebe8...", true, ""]`
+<<<<<<< HEAD
   * `["OK", "b1a649ebe8...", true, "pow: difficulty 25>=24"]` pow: 難易度25は24以上
   * `["OK", "b1a649ebe8...", true, "duplicate: already have this event"]` 重複: すでにこのイベントは存在している
   * `["OK", "b1a649ebe8...", false, "blocked: you are banned from posting here"]` ブロックされている: あなたはここで投稿することが禁止されている
@@ -173,3 +190,19 @@ Kindはクライアントがイベントやイベントのフィールドをど
   * `["CLOSED", "sub1", "error: could not connect to the database"]` エラー: データベースに接続できなかった
   * `["CLOSED", "sub1", "error: shutting down idle subscription"]` エラー: アイドル状態の購読をシャットダウン
 - `OK`と`CLOSED`の標準化されている機械可読なプレフィクスは、`duplicate`、`pow`、`blocked`、`rate-limited`、`invalid`と`error`(他のどれにも当てはまらない場合)である。
+=======
+  * `["OK", "b1a649ebe8...", true, "pow: difficulty 25>=24"]`
+  * `["OK", "b1a649ebe8...", true, "duplicate: already have this event"]`
+  * `["OK", "b1a649ebe8...", false, "blocked: you are banned from posting here"]`
+  * `["OK", "b1a649ebe8...", false, "blocked: please register your pubkey at https://my-expensive-relay.example.com"]`
+  * `["OK", "b1a649ebe8...", false, "rate-limited: slow down there chief"]`
+  * `["OK", "b1a649ebe8...", false, "invalid: event creation date is too far off from the current time"]`
+  * `["OK", "b1a649ebe8...", false, "pow: difficulty 26 is less than 30"]`
+  * `["OK", "b1a649ebe8...", false, "restricted: not allowed to write."]`
+  * `["OK", "b1a649ebe8...", false, "error: could not connect to the database"]`
+- `CLOSED` messages MUST be sent in response to a `REQ` when the relay refuses to fulfill it. It can also be sent when a relay decides to kill a subscription on its side before a client has disconnected or sent a `CLOSE`. This message uses the same pattern of `OK` messages with the machine-readable prefix and human-readable message. Some examples:
+  * `["CLOSED", "sub1", "unsupported: filter contains unknown elements"]`
+  * `["CLOSED", "sub1", "error: could not connect to the database"]`
+  * `["CLOSED", "sub1", "error: shutting down idle subscription"]`
+- The standardized machine-readable prefixes for `OK` and `CLOSED` are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, `restricted`, and `error` for when none of that fits.
+>>>>>>> upstream/master

07.md

@@ -17,7 +17,6 @@ async window.nostr.signEvent(event: { created_at: number, kind: number, tags: st
 
 上記２つのメソッドの他に、オプションとして下記のメソッドを定義してもよい。
 ```
-async window.nostr.getRelays(): { [url: string]: {read: boolean, write: boolean} } // returns a basic map of relay urls to relay policies
 async window.nostr.nip04.encrypt(pubkey, plaintext): string // returns ciphertext and iv as specified in nip-04 (deprecated)
 async window.nostr.nip04.decrypt(pubkey, ciphertext): string // takes ciphertext and iv as specified in nip-04 (deprecated)
 async window.nostr.nip44.encrypt(pubkey, plaintext): string // returns ciphertext as specified in nip-44

10.md

@@ -1,26 +1,43 @@
 NIP-10
 ======
 
-
-On "e" and "p" tags in Text Events (kind 1)
--------------------------------------------
+Text Notes and Threads
+----------------------
 
 `draft` `optional`
 
+This NIP defines `kind:1` as a simple plaintext note.
+
 ## Abstract
-This NIP describes how to use "e" and "p" tags in text events, especially those that are replies to other text events.  It helps clients thread the replies into a tree rooted at the original event.
+
+The `.content` property contains some human-readable text. 
+
+`e` tags can be used to define note thread roots and replies. They SHOULD be sorted by the reply stack from root to the direct parent.
+
+`q` tags MAY be used when citing events in the `.content` with [NIP-21](21.md).
+
+```json
+["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]
+```
+
+Authors of the `e` and `q` tags SHOULD be added as `p` tags to notify of a new reply or quote.
+
+Markup languages such as markdown and HTML SHOULD NOT be used. 
 
 ## Marked "e" tags (PREFERRED)
+
+Kind 1 events with `e` tags are replies to other kind 1 events. Kind 1 replies MUST NOT be used to reply to other kinds, use [NIP-22](22.md) instead. 
+
 `["e", <event-id>, <relay-url>, <marker>, <pubkey>]`
 
 Where:
 
  * `<event-id>` is the id of the event being referenced.
  * `<relay-url>` is the URL of a recommended relay associated with the reference. Clients SHOULD add a valid `<relay-url>` field, but may instead leave it as `""`.
- * `<marker>` is optional and if present is one of `"reply"`, `"root"`, or `"mention"`.
+ * `<marker>` is optional and if present is one of `"reply"`, `"root"`.
  * `<pubkey>` is optional, SHOULD be the pubkey of the author of the referenced event
 
-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.
+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. 
 
 A direct reply to the root of a thread should have a single marked "e" tag of type "root".
 

17.md

@@ -35,6 +35,46 @@ Tags that mention, quote and assemble threading structures MUST follow [NIP-10](
 
 Kind `14`s MUST never be signed. If it is signed, the message might leak to relays and become **fully public**.
 
+## File Message Kind
+
+```jsonc
+{
+  "id": "<usual hash>",
+  "pubkey": "<sender-pubkey>",
+  "created_at": "<current-time>",
+  "kind": 15,
+  "tags": [
+    ["p", "<receiver-1-pubkey>", "<relay-url>"],
+    ["p", "<receiver-2-pubkey>", "<relay-url>"],
+    ["e", "<kind-14-id>", "<relay-url>", "reply"], // if this is a reply
+    ["subject", "<conversation-title>"],
+    ["file-type", "<file-mime-type>"],
+    ["encryption-algorithm", "<encryption-algorithm>"],
+    ["decryption-key", "<decryption-key>"],
+    ["decryptiion-nonce", "<decryption-nonce>"],
+    ["x", "<the SHA-256 hexencoded string of the file>"],
+    // rest of tags...
+  ],
+  "content": "<file-url>"
+}
+```
+
+Kind 15 is used for sending encrypted file event messages:
+
+- `file-type`: Specifies the MIME type of the attached file (e.g., `image/jpeg`, `audio/mpeg`, etc.).
+- `encryption-algorithm`: Indicates the encryption algorithm used for encrypting the file. Supported algorithms may include `aes-gcm`, `chacha20-poly1305`,`aes-cbc` etc.
+- `decryption-key`: The decryption key that will be used by the recipient to decrypt the file.
+- `decryption-nonce`: The decryption nonce that will be used by the recipient to decrypt the file.
+- `content`: The URL of the file (`<file-url>`).
+- `x` containing the SHA-256 hexencoded string of the file.
+- `size` (optional) size of file in bytes
+- `dim` (optional) size of file in pixels in the form `<width>x<height>`
+- `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the file is being loaded by the client
+- `thumb` (optional) url of thumbnail with same aspect ratio
+- `fallback` (optional) zero or more fallback file sources in case `url` fails
+
+Just like kind 14, kind `15`s MUST never be signed.
+
 ## Chat Rooms
 
 The set of `pubkey` + `p` tags defines a chat room. If a new `p` tag is added or a current one is removed, a new room is created with clean message history.
@@ -45,7 +85,7 @@ An optional `subject` tag defines the current name/topic of the conversation. An
 
 ## Encrypting
 
-Following [NIP-59](59.md), the **unsigned** `kind:14` chat message must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
+Following [NIP-59](59.md), the **unsigned** `kind:14` & `kind:15` chat message must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
 
 ```jsonc
 {
@@ -133,7 +173,7 @@ When sending a message to anyone, clients must then connect to the relays in the
 
 This example sends the message `Hola, que tal?` from `nsec1w8udu59ydjvedgs3yv5qccshcj8k05fh3l60k9x57asjrqdpa00qkmr89m` to `nsec12ywtkplvyq5t6twdqwwygavp5lm4fhuang89c943nf2z92eez43szvn4dt`.
 
-The two final GiftWraps, one to the receiver and the other to the sender, are:
+The two final GiftWraps, one to the receiver and the other to the sender, respectively, are:
 
 ```json
 {

18.md

@@ -9,7 +9,12 @@ NIP-18
 リポストは`kind 1`テキスト投稿が読む価値を持つことを
 フォロワーへ知らせるために使われる`kind 6`イベントである。
 
+<<<<<<< HEAD
 リポストイベントの`content`は _リポストされた投稿を文字列化したJSON_ だ。これは空でもかまわない (MAY) が、推奨されない。
+=======
+The `content` of a repost event is _the stringified JSON of the reposted note_. It MAY also be empty, but that is not recommended.
+Reposts of [NIP-70](70.md)-protected events SHOULD always have an empty `content`.
+>>>>>>> upstream/master
 
 リポストイベントはリポストされた投稿の`id`を持つ`e`タグを含まなければならない (MUST) 。
 そのタグは投稿を取得可能な場所を指すリレーURLを
@@ -36,5 +41,11 @@ NIP-18
 「汎用リポスト」として用い、これは`kind 1`以外のあらゆる種類のイベントを含めることが
 できる。
 
+<<<<<<< HEAD
 `kind 16`のリポストは、リポストされたイベントの文字列化されたkind番号を値とする
 `k`タグを含むべきだ (SHOULD) 。
+=======
+`kind 16` reposts SHOULD contain a `k` tag with the stringified kind number
+of the reposted event as its value.
+
+>>>>>>> upstream/master

22.md

@@ -6,13 +6,16 @@ Comment
 
 `draft` `optional`
 
-A comment is a threading note always scoped to a root event or an `I`-tag.
+A comment is a threading note always scoped to a root event or an [`I`-tag](73.md).
 
 It uses `kind:1111` with plaintext `.content` (no HTML, Markdown, or other formatting).
 
 Comments MUST point to the root scope using uppercase tag names (e.g. `K`, `E`, `A` or `I`)
 and MUST point to the parent item with lowercase ones (e.g. `k`, `e`, `a` or `i`).
 
+Comments MUST point to the authors when one is available (i.e. tagging a nostr event). `P` for the root scope
+and `p` for the author of the parent item.
+
 ```jsonc
 {
   kind: 1111,
@@ -23,10 +26,16 @@ and MUST point to the parent item with lowercase ones (e.g. `k`, `e`, `a` or `i`
     // the root item kind
     ["K", "<root kind>"],
 
+    // pubkey of the author of the root scope event
+    ["P", "<root-pubkey>", "relay-url-hint"],
+
     // parent item: event addresses, event ids, or i-tags.
     ["<a, e, i>", "<address, id or i-value>", "<relay or web page hint>", "<parent event's pubkey, if an e tag>"],
     // parent item kind
-    ["k", "<parent comment kind>"]
+    ["k", "<parent comment kind>"],
+
+    // parent item pubkey
+    ["p", "<parent-pubkey>", "relay-url-hint"]
   ]
   // other fields
 }
@@ -46,11 +55,8 @@ Their uppercase versions use the same type of values but relate to the root item
 ```
 
 `p` tags SHOULD be used when mentioning pubkeys in the `.content` with [NIP-21](21.md).
-If the parent item is an event, a `p` tag set to the parent event's author SHOULD be added.
 
-```json
-["p", "<pubkey>", "<relay-url>"]
-```
+Comments MUST NOT be used to reply to kind 1 notes. [NIP-10](10.md) should instead be followed.
 
 ## Examples
 
@@ -65,13 +71,17 @@ A comment on a blog post looks like this:
     ["A", "30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "wss://example.relay"],
     // the root kind
     ["K", "30023"],
+    // author of root event
+    ["P", "3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289", "wss://example.relay"]
 
     // the parent event address (same as root for top-level comments)
     ["a", "30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "wss://example.relay"],
     // when the parent event is replaceable or addressable, also include an `e` tag referencing its id
     ["e", "5b4fc7fed15672fefe65d2426f67197b71ccc82aa0cc8a9e94f683eb78e07651", "wss://example.relay"],
     // the parent event kind
-    ["k", "30023"]
+    ["k", "30023"],
+    // author of the parent event
+    ["p", "3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289", "wss://example.relay"]
   ]
   // other fields
 }
@@ -88,11 +98,14 @@ A comment on a [NIP-94](94.md) file looks like this:
     ["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
     // the root kind
     ["K", "1063"],
+    // author of the root event
+    ["P", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
 
     // the parent event id (same as root for top-level comments)
     ["e", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"],
     // the parent kind
-    ["k", "1063"]
+    ["k", "1063"],
+    ["p", "3721e07b079525289877c366ccab47112bdff3d1b44758ca333feb2dbbbbe5bb"]
   ]
   // other fields
 }
@@ -109,11 +122,13 @@ A reply to a comment looks like this:
     ["E", "768ac8720cdeb59227cf95e98b66560ef03d8bc9a90d721779e76e68fb42f5e6", "wss://example.relay", "fd913cd6fa9edb8405750cd02a8bbe16e158b8676c0e69fdc27436cc4a54cc9a"],
     // the root kind
     ["K", "1063"],
+    ["P", "fd913cd6fa9edb8405750cd02a8bbe16e158b8676c0e69fdc27436cc4a54cc9a"],
 
     // the parent event
     ["e", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "wss://example.relay", "93ef2ebaaf9554661f33e79949007900bbc535d239a4c801c33a4d67d3e7f546"],
     // the parent kind
-    ["k", "1111"]
+    ["k", "1111"],
+    ["p", "93ef2ebaaf9554661f33e79949007900bbc535d239a4c801c33a4d67d3e7f546"]
   ]
   // other fields
 }
@@ -178,6 +193,7 @@ A reply to a podcast comment:
     ["e", "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05", "wss://example.relay", "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111"],
     // the parent comment kind
     ["k", "1111"]
+    ["p", "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111"]
   ]
   // other fields
 }