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
 {
@@ -87,15 +105,27 @@ 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`: **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 **parameterized replaceable**, which means that, for each combination of `pubkey`, `kind` and the `d` tag's first value, only the latest event MUST be stored by relays, older versions MAY be discarded.
+>>>>>>> upstream/master
 
 置換可能イベントが同じタイムスタンプを持っている場合は、最も小さいID(辞書順で最初)のイベントが保持され、他のイベントは破棄されるべきだ。
 
@@ -125,8 +155,8 @@ 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>
 }
 ```
@@ -143,7 +173,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
 
 ### リレーからクライアントへ: イベントの送信と通知
 

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

05.md

@@ -6,11 +6,19 @@ Nostr鍵をDNSベースのインターネット識別子に結びつける
 
 `final` `optional`
 
+<<<<<<< HEAD
 kind `0` (`metadata`)には[インターネット識別子](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (eメールのようなアドレス) を値として`"nip05"`というキーを指定できる。"インターネット識別子"に対する多種多様な仕様のリンクがあるが、NIP-05は`<local-part>`部分が`a-z0-9-_.`で大文字と小文字を区別しないことを前提としている。
+=======
+On events of kind `0` (`user metadata`) one can specify the key `"nip05"` with an [internet identifier](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (an email-like address) as the value. Although there is a link to a very liberal "internet identifier" specification above, NIP-05 assumes the `<local-part>` part will be restricted to the characters `a-z0-9-_.`, case-insensitive.
+>>>>>>> upstream/master
 
 クライアントは識別子を`<local-part>`と`<domain>`に分けた上でそれらの値で`https://<domain>/.well-known/nostr.json?name=<local-part>`にGET要求を行う。
 
+<<<<<<< HEAD
 結果として、16進数で表される公開鍵に対応した`"names"`キーを持つ、JSONドキュメントオブジェクトが返されなければならない。指定された`<name>`の公開鍵が`metadata`イベントの`pubkey`と一致する場合、クライアントは与えられた公開鍵が実際にその識別子で照会できると結論付ける。
+=======
+The result should be a JSON document object with a key `"names"` that should then be a mapping of names to hex formatted public keys. If the public key for the given `<name>` matches the `pubkey` from the `user's metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier.
+>>>>>>> upstream/master
 
 ### 例
 

07.md

@@ -24,6 +24,14 @@ async window.nostr.nip44.encrypt(pubkey, plaintext): string // returns ciphertex
 async window.nostr.nip44.decrypt(pubkey, ciphertext): string // takes ciphertext as specified in nip-44
 ```
 
+<<<<<<< HEAD
 ### 実装
+=======
+### Recommendation to Extension Authors
+To make sure that the `window.nostr` is available to nostr clients on page load, the authors who create Chromium and Firefox extensions should load their scripts by specifying `"run_at": "document_end"` in the extension's manifest.
+
+
+### Implementation
+>>>>>>> upstream/master
 
 https://github.com/aljazceru/awesome-nostr#nip-07-browser-extensions を参照する。

09.md

@@ -1,16 +1,14 @@
 NIP-09
 ======
 
-Event Deletion
+Event Deletion Request
 --------------
 
 `draft` `optional`
 
-A special event with kind `5`, meaning "deletion" is defined as having a list of one or more `e` tags, each referencing an event the author is requesting to be deleted.
+A special event with kind `5`, meaning "deletion request" is defined as having a list of one or more `e` or `a` tags, each referencing an event the author is requesting to be deleted. Deletion requests SHOULD include a `k` tag for the kind of each event being requested for deletion.
 
-Each tag entry must contain an "e" event id and/or `a` tags intended for deletion.
-
-The event's `content` field MAY contain a text note describing the reason for the deletion.
+The event's `content` field MAY contain a text note describing the reason for the deletion request.
 
 For example:
 
@@ -21,29 +19,35 @@ For example:
   "tags": [
     ["e", "dcd59..464a2"],
     ["e", "968c5..ad7a4"],
-    ["a", "<kind>:<pubkey>:<d-identifier>"]
+    ["a", "<kind>:<pubkey>:<d-identifier>"],
+    ["k", "1"],
+    ["k", "30023"]
   ],
   "content": "these posts were published by accident",
   ...other fields
 }
 ```
 
-Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the deletion request.  Clients SHOULD hide or otherwise indicate a deletion status for referenced events.
+Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the deletion request.  Clients SHOULD hide or otherwise indicate a deletion request status for referenced events.
+
+Relays SHOULD continue to publish/share the deletion request events indefinitely, as clients may already have the event that's intended to be deleted. Additionally, clients SHOULD broadcast deletion request events to other relays which don't have it.
 
-Relays SHOULD continue to publish/share the deletion events indefinitely, as clients may already have the event that's intended to be deleted. Additionally, clients SHOULD broadcast deletion events to other relays which don't have it.
+When an `a` tag is used, relays SHOULD delete all versions of the replaceable event up to the `created_at` timestamp of the deletion request event.
 
 ## Client Usage
 
-Clients MAY choose to fully hide any events that are referenced by valid deletion events.  This includes text notes, direct messages, or other yet-to-be defined event kinds.  Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event.  The `content` field MAY also be used to replace the deleted events' own content, although a user interface should clearly indicate that this is a deletion reason, not the original content.
+Clients MAY choose to fully hide any events that are referenced by valid deletion request events.  This includes text notes, direct messages, or other yet-to-be defined event kinds.  Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event.  The `content` field MAY also be used to replace the deleted events' own content, although a user interface should clearly indicate that this is a deletion request reason, not the original content.
 
 A client MUST validate that each event `pubkey` referenced in the `e` tag of the deletion request is identical to the deletion request `pubkey`, before hiding or deleting any event.  Relays can not, in general, perform this validation and should not be treated as authoritative.
 
-Clients display the deletion event itself in any way they choose, e.g., not at all, or with a prominent notice.
+Clients display the deletion request event itself in any way they choose, e.g., not at all, or with a prominent notice.
+
+Clients MAY choose to inform the user that their request for deletion does not guarantee deletion because it is impossible to delete events from all relays and clients.
 
 ## Relay Usage
 
-Relays MAY validate that a deletion event only references events that have the same `pubkey` as the deletion itself, however this is not required since relays may not have knowledge of all referenced events.
+Relays MAY validate that a deletion request event only references events that have the same `pubkey` as the deletion request itself, however this is not required since relays may not have knowledge of all referenced events.
 
-## Deleting a Deletion
+## Deletion Request of a Deletion Request
 
-Publishing a deletion event against a deletion has no effect.  Clients and relays are not obliged to support "undelete" functionality.
+Publishing a deletion request event against a deletion request has no effect.  Clients and relays are not obliged to support "unrequest deletion" functionality.

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.

11.md

@@ -37,7 +37,7 @@ Detailed plain-text information about the relay may be contained in the `descrip
 
 ### Pubkey
 
-An administrative contact may be listed with a `pubkey`, in the same format as Nostr events (32-byte hex for a `secp256k1` public key).  If a contact is listed, this provides clients with a recommended address to send encrypted direct messages (See `NIP-04`) to a system administrator.  Expected uses of this address are to report abuse or illegal content, file bug reports, or request other technical assistance.
+An administrative contact may be listed with a `pubkey`, in the same format as Nostr events (32-byte hex for a `secp256k1` public key).  If a contact is listed, this provides clients with a recommended address to send encrypted direct messages (See [NIP-17](17.md)) to a system administrator.  Expected uses of this address are to report abuse or illegal content, file bug reports, or request other technical assistance.
 
 Relay operators have no obligation to respond to direct messages.
 

13.md

@@ -35,7 +35,7 @@ Example mined note
   "created_at": 1651794653,
   "kind": 1,
   "tags": [
-    ["nonce", "776797", "21"]
+    ["nonce", "776797", "20"]
   ],
   "content": "It's just me mining my own business",
   "sig": "284622fc0a3f4f1303455d5175f7ba962a3300d136085b9566801bc2e0699de0c7e31e44c81fb40ad9049173742e904713c3594a1da0fc5d2382a25c11aba977"