Sync with upstream including CONFLICT

Author: github-actions[bot]

01.md

@@ -14,7 +14,7 @@ NIP-01
 
 ただ1つだけ存在するオブジェクトの型が`event`で、以下のようなフォーマットで伝送される。
 
-```jsonc
+```yaml
 {
   "id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
@@ -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, specifies 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の範囲についての以下のような慣例もある。
 
@@ -119,7 +135,7 @@ Kindはクライアントがイベントやイベントのフィールドをど
 
 `<フィルタX>`はJSONオブジェクトで、どんなイベントがその購読で転送されるかを決める。以下の属性をもつ可能性がある:
 
-```json
+```yaml
 {
   "ids": <a list of event ids>,
   "authors": <a list of lowercase pubkeys, the pubkey of an event must be one of these>,
@@ -143,7 +159,11 @@ Kindはクライアントがイベントやイベントのフィールドをど
 
 1つの`REQ`メッセージに複数のフィルタを含むことができる。この場合、いずれかのフィルタにマッチするイベントが返される。つまり、複数のフィルタは`||`条件として解釈される。
 
+<<<<<<< HEAD
 フィルタの`limit`プロパティは、初期クエリにのみ影響を及ぼし、それ以降は無視されなければならない(MUST)。`limit: n`が存在する場合、初期クエリでは最新の`n`イベントが`created_at`順に返されることが想定される。`新しいイベントが最初に表示され、同時刻の場合はidが最も小さい (辞書式順序で最初の) イベントが最初に表示されるべきである。limit`の指定よりも少ないイベントを返すことは問題ない。しかし、クライアントに対して不必要に負荷を与えることを避けるため、リレーは要求されたよりも(はるかに)多くのイベントを返すことがないよう期待される。
+=======
+The `limit` property of a filter is only valid for the initial query and MUST be ignored afterwards. When `limit: n` is present it is assumed that the events returned in the initial query will be the last `n` events ordered by the `created_at`. Newer events should appear first, and in the case of ties the event with the lowest id (first in lexical order) should be first. Relays SHOULD use the `limit` value to guide how many events are returned in the initial response. Returning fewer events is acceptable, but returning (much) more should be avoided to prevent overwhelming clients.
+>>>>>>> upstream/master
 
 ### リレーからクライアントへ: イベントの送信と通知
 
@@ -160,6 +180,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 +194,20 @@ 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"]`
+  * `["OK", "b1a649ebe8...", false, "mute: no one was listening to your ephemeral event and it wasn't handled in any way, it was ignored"]`
+- `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`, `mute` and `error` for when none of that fits.
+>>>>>>> upstream/master

03.md

@@ -12,8 +12,8 @@ NIP-03
 {
   "kind": 1040
   "tags": [
-    ["e", <event-id>, <relay-url>],
-    ["alt", "opentimestamps attestation"]
+    ["e", <target-event-id>, <relay-url>],
+    ["k", "<target-event-kind>"]
   ],
   "content": <base64-encoded OTS file data>
 }

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".