Merge branch 'master' into draft-event

01.md

@@ -43,16 +43,16 @@ To obtain the `event.id`, we `sha256` the serialized event. The serialization is
 ```
 
 To prevent implementation differences from creating a different event ID for the same event, the following rules MUST be followed while serializing:
-- No whitespace, line breaks or other unnecessary formatting should be included in the output JSON.
-- No characters except the following should be escaped, and instead should be included verbatim:
-  - A line break, `0x0A`, as `\n`
-  - A double quote, `0x22`, as `\"`
-  - A backslash, `0x5C`, as `\\`
-  - A carriage return, `0x0D`, as `\r`
-  - A tab character, `0x09`, as `\t`
-  - A backspace, `0x08`, as `\b`
-  - A form feed, `0x0C`, as `\f`
 - 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`
 
 ### Tags
 
@@ -77,25 +77,25 @@ This NIP defines 3 standard tags that can be used across all event kinds with th
 
 - 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 a (maybe parameterized) replaceable event
-    - for a parameterized replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
-    - for a non-parameterized replaceable event: `["a", <kind integer>:<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.
+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.
 
 ### Kinds
 
 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. This NIP defines two basic kinds:
 
-- `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.
+- `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.
 
 And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation:
 
-- for kind `n` such that `1000 <= n < 10000`, events are **regular**, which means they're all expected to be stored by relays.
+- 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.
+- 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.
 
 In case of replaceable events with the same timestamp, the event with the lowest id (first in lexical order) should be retained, and the other discarded.
 
@@ -125,13 +125,13 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
   "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>
 }
 ```
 
-Upon receiving a `REQ` message, the relay SHOULD query its internal database and return events that match the filter, then store that filter and send again all future events it receives to that same websocket until the websocket is closed. The `CLOSE` event is received with the same `<subscription_id>` or a new `REQ` is sent using the same `<subscription_id>`, in which case relay MUST overwrite the previous subscription.
+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).
 
 Filter attributes containing lists (`ids`, `authors`, `kinds` and tag filters like `#e`) are JSON arrays with one or more values. At least one of the arrays' values must match the relevant field in an event for the condition to be considered a match. For scalar event attributes such as `authors` and `kind`, the attribute from the event must be contained in the filter list. In the case of tag attributes such as `#e`, for which an event may have multiple values, the event and filter condition values must have at least one item in common.
 
@@ -143,7 +143,7 @@ All conditions of a filter that are specified must match for an event for it to
 
 A `REQ` message may contain multiple filters. In this case, events that match any of the filters are to be returned, i.e., multiple filters are to be interpreted as `||` conditions.
 
-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`. 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.
+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.
 
 ### From relay to client: sending events and notices
 
@@ -169,7 +169,6 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated.
   * `["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", "duplicate: sub1 already opened"]`
   * `["CLOSED", "sub1", "unsupported: filter contains unknown elements"]`
   * `["CLOSED", "sub1", "error: could not connect to the database"]`
   * `["CLOSED", "sub1", "error: shutting down idle subscription"]`

02.md

@@ -14,7 +14,7 @@ The `.content` is not used.
 
 For example:
 
-```json
+```jsonc
 {
   "kind": 3,
   "tags": [
@@ -23,7 +23,7 @@ For example:
     ["p", "612ae..e610f", "ws://carolrelay.com/ws", "carol"]
   ],
   "content": "",
-  ...other fields
+  // other fields...
 }
 ```
 

05.md

@@ -6,22 +6,22 @@ Mapping Nostr keys to DNS-based internet identifiers
 
 `final` `optional`
 
-On events of kind `0` (`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.
+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.
 
 Upon seeing that, the client splits the identifier into `<local-part>` and `<domain>` and use these values to make a GET request to `https://<domain>/.well-known/nostr.json?name=<local-part>`.
 
-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 `metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier.
+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 metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier.
 
 ### Example
 
 If a client sees an event like this:
 
-```json
+```jsonc
 {
   "pubkey": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9",
   "kind": 0,
   "content": "{\"name\": \"bob\", \"nip05\": \"[email protected]\"}"
-  ...
+  // other fields...
 }
 ```
 
@@ -33,7 +33,7 @@ It will make a GET request to `https://example.com/.well-known/nostr.json?name=b
     "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
   }
 }
-````
+```
 
 or with the **recommended** `"relays"` attribute:
 
@@ -46,7 +46,7 @@ or with the **recommended** `"relays"` attribute:
     "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [ "wss://relay.example.com", "wss://relay2.example.com" ]
   }
 }
-````
+```
 
 If the pubkey matches the one given in `"names"` (as in the example above) that means the association is right and the `"nip05"` identifier is valid and can be displayed.
 
@@ -58,6 +58,15 @@ A client may implement support for finding users' public keys from _internet ide
 
 ## Notes
 
+### Identification, not verification
+
+The NIP-05 is not intended to _verify_ a user, but only to _identify_ them, for the purpose of facilitating the exchange of a contact or their search.  
+Exceptions are people who own (e.g., a company) or are connected (e.g., a project) to a well-known domain, who can exploit NIP-05 as an attestation of their relationship with it, and thus to the organization behind it, thereby gaining an element of trust.
+
+### User discovery implementation suggestion
+
+A client can use this to allow users to search other profiles. If a client has a search box or something like that, a user may be able to type "[email protected]" there and the client would recognize that and do the proper queries to obtain a pubkey and suggest that to the user.
+
 ### Clients must always follow public keys, not NIP-05 addresses
 
 For example, if after finding that `[email protected]` has the public key `abc...def`, the user clicks a button to follow that profile, the client must keep a primary reference to `abc...def`, not `[email protected]`. If, for any reason, the address `https://bob.com/.well-known/nostr.json?name=bob` starts returning the public key `1d2...e3f` at any time in the future, the client must not replace `abc...def` in his list of followed profiles for the user (but it should stop displaying "[email protected]" for that user, as that will have become an invalid `"nip05"` property).
@@ -66,10 +75,6 @@ For example, if after finding that `[email protected]` has the public key `abc...def`,
 
 Keys must be returned in hex format. Keys in NIP-19 `npub` format are only meant to be used for display in client UIs, not in this NIP.
 
-### User Discovery implementation suggestion
-
-A client can also use this to allow users to search other profiles. If a client has a search box or something like that, a user may be able to type "[email protected]" there and the client would recognize that and do the proper queries to obtain a pubkey and suggest that to the user.
-
 ### Showing just the domain as an identifier
 
 Clients may treat the identifier `_@domain` as the "root" identifier, and choose to display it as just the `<domain>`. For example, if Bob owns `bob.com`, he may not want an identifier like `[email protected]` as that is redundant. Instead, Bob can use the identifier `[email protected]` and expect Nostr clients to show and treat that as just `bob.com` for all purposes.

07.md

@@ -24,6 +24,10 @@ 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
 ```
 
+### 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
 
 See https://github.com/aljazceru/awesome-nostr#nip-07-browser-extensions.