Sync with upstream including CONFLICT

01.md

@@ -56,7 +56,11 @@ NIP-01
 
 ### タグ
 
+<<<<<<< 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
 {
@@ -87,8 +91,13 @@ NIP-01
 
 Kindはクライアントがイベントやイベントのフィールドをどう解釈すべきかを決める(たとえば、`"r"`タグのkind 1における意味は、kind 10002のイベントにおける意味と全く異なる可能性がある)。それぞれのNIPにおいて、他の場所で定義されていないkindの意味を定義する可能性がある。このNIPでは、以下のように2つの基本的なkindを定義する。
 
+<<<<<<< HEAD
 - `0`: **メタデータ**: `content`は文字列化されたJSONオブジェクト`{name: <ユーザ名>, about: <文字列>, picture: <URL、文字列>}`で、イベントを作成したユーザのことを記述する。リレーは、同一のpubkeyから新しいイベントを受信した際、過去のイベントを削除できる。
 - `1`: **テキスト投稿**: `content`はノート(ユーザが発言したいこと)を**プレーンテキスト**で指定する。パースが必要なコンテンツ(マークダウンやHTMLなど)を使用すべきではない。クライアントもコンテンツをそのようにパースをしてはならない。
+=======
+- `0`: **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の範囲についての以下のような慣例もある。
 

02.md

@@ -8,7 +8,13 @@ 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
 
 例:
 

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

10.md

@@ -38,20 +38,22 @@ They are citing from this event.  `root-id` and `reply-id` are as above.
 >This scheme is deprecated because it creates ambiguities that are difficult, or impossible to resolve when an event references another but is not a reply.
 
 ## Marked "e" tags (PREFERRED)
-`["e", <event-id>, <relay-url>, <marker>]`
+`["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"`.
+ * `<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.
 
 A direct reply to the root of a thread should have a single marked "e" tag of type "root".
 
 >This scheme is preferred because it allows events to mention others without confusing them with `<reply-id>` or `<root-id>`.
 
+`<pubkey>` SHOULD be the pubkey of the author of the `e` tagged event, this is used in the outbox model to search for that event from the authors write relays where relay hints did not resolve the event.
 
 ## The "p" tag
 Used in a text event contains a list of pubkeys used to record who is involved in a reply thread.