Sync with upstream including CONFLICT

01.md

@@ -42,6 +42,7 @@ NIP-01
 ]
 ```
 
+<<<<<<< HEAD
 同一のイベントに対して異なるイベントIDが生成されるような実装の差異を防ぐため、シリアライズを行う際には以下のルールに従わなければならない(MUST):
 - ホワイトスペースや改行、その他の不必要なフォーマットは出力のJSONに含めてはならない。
 - 以下の文字列以外はエスケープせず、そのまま含めるべきだ:
@@ -53,10 +54,27 @@ NIP-01
   - バックスペース`0x08`は`\b`
   - 改ページ`0x0C`は`\f`
 - エンコーディングにはUTF-8を使用するべきだ。
+=======
+To prevent implementation differences from creating a different event ID for the same event, the following rules MUST be followed while serializing:
+- UTF-8 should be used for encoding.
+- Whitespace, line breaks or other unnecessary formatting should not be included in the output JSON.
+- The following characters in the content field must be escaped as shown, and all other characters must be included verbatim:
+  - A line break (`0x0A`), use `\n`
+  - A double quote (`0x22`), use `\"`
+  - A backslash (`0x5C`), use `\\`
+  - A carriage return (`0x0D`), use `\r`
+  - A tab character (`0x09`), use `\t`
+  - A backspace, (`0x08`), use `\b`
+  - A form feed, (`0x0C`), use `\f`
+>>>>>>> upstream/master
 
 ### タグ
 
+<<<<<<< HEAD
 タグはそれぞれ任意長の文字列の配列で、関連していくつかの慣例がある。以下の例を見てみよう。
+=======
+Each tag is an array of one or more strings, with some conventions around them. Take a look at the example below:
+>>>>>>> upstream/master
 
 ```jsonc
 {
@@ -75,27 +93,49 @@ NIP-01
 
 このNIPでは標準的なタグを3つ定義する。これらのタグは、あらゆるイベントのkindにおいて同じ意味で用いられる。以下の通りだ。
 
+<<<<<<< HEAD
 - `e`タグ。イベントを参照するために用いる: `["e", <他のイベントIDの32バイト小文字16進数文字列>, <おすすめのリレーURL、省略可能>]`
 - `p`タグ。別のユーザを参照するために用いる: `["p", <pubkeyの32バイト小文字16進数文字列>, <おすすめのリレーURL、省略可能>]`
 - `a`タグ。(パラメータ付き・無し)置換可能イベントを参照するために用いる。
   - パラメータ付き置換可能イベントの場合: `["a", <kind整数>:<pubkeyの32バイト小文字16進数文字列>:<dタグの値>, <おすすめリレーURL、省略可能>]`
   - パラメータ無し置換可能イベントの場合: `["a", <kind整数>:<pubkeyの32バイト小文字16進数文字列>:, <おすすめリレーURL、省略可能>]`
 
 慣例として、全ての1文字(英語のアルファベットa-zとA-Zに限る)キーをもつタグは、リレーによってインデクスされることが期待される。これにより、例えば、イベント`"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"`を参照しているイベントをクエリしたり購読するために、`{"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]}`フィルタを使える。
+=======
+- The `e` tag, used to refer to an event: `["e", <32-bytes lowercase hex of the id of another event>, <recommended relay URL, 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>]`
+
+As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]}` filter. Only the first value in any given tag is indexed.
+>>>>>>> upstream/master
 
 ### Kinds
 
 Kindはクライアントがイベントやイベントのフィールドをどう解釈すべきかを決める(たとえば、`"r"`タグのkind 1における意味は、kind 10002のイベントにおける意味と全く異なる可能性がある)。それぞれのNIPにおいて、他の場所で定義されていないkindの意味を定義する可能性がある。このNIPでは、以下のように2つの基本的なkindを定義する。
 
+<<<<<<< HEAD
 - `0`: **メタデータ**: `content`は文字列化されたJSONオブジェクト`{name: <ユーザ名>, about: <文字列>, picture: <URL、文字列>}`で、イベントを作成したユーザのことを記述する。リレーは、同一のpubkeyから新しいイベントを受信した際、過去のイベントを削除できる。
 - `1`: **テキスト投稿**: `content`はノート(ユーザが発言したいこと)を**プレーンテキスト**で指定する。パースが必要なコンテンツ(マークダウンやHTMLなど)を使用すべきではない。クライアントもコンテンツをそのようにパースをしてはならない。
+=======
+- `0`: **user metadata**: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` 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.
+- `1`: **text note**: the `content` is set to the **plaintext** content of a note (anything the user wants to say). Content that must be parsed, such as Markdown and HTML, should not be used. Clients should also not parse content as those.
+>>>>>>> upstream/master
 
 実験を容易にし、リレーの実装を柔軟にするため、kindの範囲についての以下のような慣例もある。
 
+<<<<<<< HEAD
 - kind`n`が範囲`1000 <= n < 10000`の場合は、イベントは**通常(regular)**で、全てがリレーに保存されることが期待される。
 - kind`n`が範囲`10000 <= n < 20000 || n == 0 || n == 3`の場合は、イベントは**置換可能(replaceable)**で、最新のイベントだけがリレーに保持されなければならない(MUST)。また、古いバージョンは破棄してもかまわない(MAY)。
 - kind`n`が範囲`20000 <= n < 30000`の場合は、イベントは**一時的(ephemeral)**で、リレーに保存されないことが期待される。
 - kind`n`が範囲`30000 <= n < 40000`の場合は、イベントは**パラメータ付き置換可能(parameterized replaceable)**で、`pubkey`と`kind`と`d`タグの最初の値の組み合わせについて、最新のイベントのみがリレーに保存されなければならない(MUST)。また、古いバージョンは破棄してかまわない(MAY)。
+=======
+- for kind `n` such that `1000 <= n < 10000 || 4 <= n < 45 || n == 1 || n == 2`, events are **regular**, which means they're all expected to be stored by relays.
+- for kind `n` such that `10000 <= n < 20000 || n == 0 || n == 3`, events are **replaceable**, which means that, for each combination of `pubkey` and `kind`, only the latest event MUST be stored by relays, older versions MAY be discarded.
+- for kind `n` such that `20000 <= n < 30000`, events are **ephemeral**, which means they are not expected to be stored by relays.
+- for kind `n` such that `30000 <= n < 40000`, events are **addressable** by their `kind`, `pubkey` and `d` tag value -- which means that, for each combination of `kind`, `pubkey` and the `d` tag value, only the latest event MUST be stored by relays, older versions MAY be discarded.
+>>>>>>> upstream/master
 
 置換可能イベントが同じタイムスタンプを持っている場合は、最も小さいID(辞書順で最初)のイベントが保持され、他のイベントは破棄されるべきだ。
 
@@ -125,13 +165,17 @@ Kindはクライアントがイベントやイベントのフィールドをど
   "authors": <a list of lowercase pubkeys, the pubkey of an event must be one of these>,
   "kinds": <a list of a kind numbers>,
   "#<single-letter (a-zA-Z)>": <a list of tag values, for #e — a list of event ids, for #p — a list of pubkeys, etc.>,
-  "since": <an integer unix timestamp in seconds, events must be newer than this to pass>,
-  "until": <an integer unix timestamp in seconds, events must be older than this to pass>,
+  "since": <an integer unix timestamp in seconds. Events must have a created_at >= to this to pass>,
+  "until": <an integer unix timestamp in seconds. Events must have a created_at <= to this to pass>,
   "limit": <maximum number of events relays SHOULD return in the initial query>
 }
 ```
 
+<<<<<<< HEAD
 `REQ`メッセージを受信すると、リレーは内部データベースに問い合わせてフィルターにマッチするイベントを返し、そのフィルターを保存しておいて、以降に受信した全てのイベントをWebSocketがクローズされるまで同じWebSocketに送信すべきだ(SHOULD)。同一の`<購読ID>`を持つ`CLOSE`イベントを受信するか、同一の`<購読ID>`を使って新たな`REQ`が送信されると、リレーは既存の購読を更新しなければならない(MUST)。
+=======
+Upon receiving a `REQ` message, the relay SHOULD return events that match the filter. Any new events it receives SHOULD be sent to that same websocket until the connection is closed, a `CLOSE` event is received with the same `<subscription_id>`, or a new `REQ` is sent using the same `<subscription_id>` (in which case a new subscription is created, replacing the old one).
+>>>>>>> upstream/master
 
 リストをとるフィルター属性(`ids`、`authors`、`kind`と`#e`のようなタグフィルタ)は、1つ以上の要素を持つJSON配列である。その条件がマッチしたとみなされるためには、配列の値のうち少なくとも1つがイベントの関連するフィールドと一致しなければならない。`authors`や`kind`のようなスカラーのイベント属性の場合は、イベントの属性値がフィルターのリストに含まれなければならない。`#e`などのタグ属性のように、イベントが複数の値を持ちうる場合は、イベントとフィルタの条件値が少なくとも1つの共通する要素を持たなければならない。
 
@@ -143,7 +187,11 @@ Kindはクライアントがイベントやイベントのフィールドをど
 
 1つの`REQ`メッセージに複数のフィルタを含むことができる。この場合、いずれかのフィルタにマッチするイベントが返される。つまり、複数のフィルタは`||`条件として解釈される。
 
+<<<<<<< HEAD
 フィルタの`limit`プロパティは、初期クエリにのみ影響を及ぼし、それ以降は無視されなければならない(MUST)。`limit: n`が存在する場合、初期クエリでは最新の`n`イベントが`created_at`順に返されることが想定される。`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. It is safe to return less events than `limit` specifies, but it is expected that relays do not return (much) more events than requested so clients don't get unnecessarily overwhelmed by data.
+>>>>>>> upstream/master
 
 ### リレーからクライアントへ: イベントの送信と通知
 
@@ -160,6 +208,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"]` ブロックされている: あなたはここで投稿することが禁止されている
@@ -174,3 +223,18 @@ 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, "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`, and `error` for when none of that fits.
+>>>>>>> upstream/master

02.md

@@ -8,11 +8,17 @@ NIP-02
 
 「フォローリスト」を意味するkind `3`の特別なイベントは、フォローしている/既知のプロフィールごとの`p`タグのリストを持つものとして定義される。
 
+<<<<<<< HEAD
 タグの個々の要素は、プロフィールの鍵・その鍵からのイベントを発見できるリレーのURL (必要なければ空文字列で設定可能) ・そのプロフィールのローカル名 (あるいは「愛称」) (空文字列が設定されるか、提供されないようできる) を含むべきで、つまり`["p", <32-bytes hex key>, <main relay URL>, <petname>]`である。`content`は何でもかまわないが、無視されるべきである。
+=======
+Each tag entry should contain the key for the profile, a relay URL where events from that key can be found (can be set to an empty string if not needed), and a local name (or "petname") for that profile (can also be set to an empty string or not provided), i.e., `["p", <32-bytes hex key>, <main relay URL>, <petname>]`.
+
+The `.content` is not used.
+>>>>>>> upstream/master
 
 例:
 
-```json
+```jsonc
 {
   "kind": 3,
   "tags": [
@@ -21,7 +27,7 @@ NIP-02
     ["p", "612ae..e610f", "ws://carolrelay.com/ws", "carol"]
   ],
   "content": "",
-  ...other fields
+  // other fields...
 }
 ```
 

04.md

@@ -1,4 +1,4 @@
-> __Warning__  `unrecommended`: deprecated in favor of [NIP-44](44.md)
+> __Warning__  `unrecommended`: deprecated in favor of [NIP-17](17.md)
 
 NIP-04
 ======