Sync with upstream

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>]` (note: include the trailing colon)
+>>>>>>> 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

@@ -21,7 +21,7 @@ Kind `14` is a chat message. `p` tags identify one or more receivers of the mess
   "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
+    ["e", "<kind-14-id>", "<relay-url>"] // if this is a reply
     ["subject", "<conversation-title>"],
     // rest of tags...
   ],
@@ -31,10 +31,56 @@ Kind `14` is a chat message. `p` tags identify one or more receivers of the mess
 
 `.content` MUST be plain text. Fields `id` and `created_at` are required.
 
-Tags that mention, quote and assemble threading structures MUST follow [NIP-10](10.md).
+An `e` tag denotes the direct parent message this post is replying to. 
+
+`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>"]
+```
 
 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 +91,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 +179,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