Merge branch 'master' into AsaiToshiya-patch-17

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
 
@@ -87,12 +87,12 @@ As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key
 
 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.
@@ -125,8 +125,8 @@ 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>,
+  "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 be older than 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>
 }
 ```

05.md

@@ -6,11 +6,11 @@ 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's metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier.
 
 ### Example
 

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.

24.md

@@ -28,7 +28,7 @@ These are fields that should be ignored or removed when found in the wild:
 kind 3
 ======
 
-These are extra fields not specified in NIP-02 that may be present in the stringified JSON of contacts events:
+These are extra fields not specified in NIP-02 that may be present in the stringified JSON of follow events:
 
 ### Deprecated fields
 

27.md

@@ -20,7 +20,7 @@ A reader client that receives an event with such `nostr:...` mentions in its `.c
 
 Suppose Bob is writing a note in a client that has search-and-autocomplete functionality for users that is triggered when they write the character `@`.
 
-As Bob types `"hello @mat"` the client will prompt him to autocomplete with [mattn's profile](https://gateway.nostr.com/p/2c7cc62a697ea3a7826521f3fd34f0cb273693cbe5e9310f35449f43622a5cdc), showing a picture and name.
+As Bob types `"hello @mat"` the client will prompt him to autocomplete with [mattn's profile](https://njump.me/npub1937vv2nf06360qn9y8el6d8sevnndy7tuh5nzre4gj05xc32tnwqauhaj6), showing a picture and name.
 
 Bob presses "enter" and now he sees his typed note as `"hello @mattn"`, `@mattn` is highlighted, indicating that it is a mention. Internally, however, the event looks like this:
 

28.md

@@ -37,7 +37,7 @@ In the channel creation `content` field, Client SHOULD include basic channel met
 
 Update a channel's public metadata.
 
-Clients and relays SHOULD handle kind 41 events similar to kind 33 replaceable events, where the information is used to update the metadata, without modifying the event id for the channel.Only the most recent kind 41 is needed to be stored.
+Kind 41 is used to update the metadata without modifying the event id for the channel. Only the most recent kind 41 per `e` tag value MAY be available.
 
 Clients SHOULD ignore kind 41s from pubkeys other than the kind 40 pubkey.
 

29.md

@@ -119,6 +119,7 @@ Each moderation action uses a different kind and requires different arguments, w
 | 9004 | `remove-permission` | `p` (pubkey), `permission` (name)         |
 | 9005 | `delete-event`      | `e` (id hex)                              |
 | 9006 | `edit-group-status` | `public` or `private`, `open` or `closed` |
+| 9007 | `create-group`      |                                           |
 
 - *group metadata* (`kind:39000`) (optional)
 

65.md

@@ -37,7 +37,7 @@ When seeking events **about** a user, where the user was tagged, Clients SHOULD
 When broadcasting an event, Clients SHOULD:
 
 - Broadcast the event to the WRITE relays of the author
-- Broadcast the event all READ relays of each tagged user
+- Broadcast the event to all READ relays of each tagged user
 
 ## Motivation
 

70.md

@@ -0,0 +1,45 @@
+NIP-70
+======
+
+Protected Events
+----------------
+
+`draft` `optional`
+
+When the `"-"` tag is present, that means the event is "protected".
+
+A protected event is an event that can only be published to relays by its author. This is achieved by relays ensuring that the author is [authenticated](42.md) before publishing their own events or by just rejecting events with `["-"]` outright.
+
+The default behavior of a relay MUST be to reject any event that contains `["-"]`.
+
+Relays that want to accept such events MUST first require that the client perform the [NIP-42](https://github.com/nostr-protocol/nips/blob/master/42.md) `AUTH` flow and then check if the authenticated client has the same pubkey as the event being published and only accept the event in that case.
+
+## The tag
+
+The tag is a simple tag with a single item: `["-"]`. It may be added to any event.
+
+## Example flow
+
+- User `79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798` connects to relay `wss://example.com`:
+
+```jsonc
+/* client: */
+["EVENT",{"id":"cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2","pubkey":"79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798","created_at":1707409439,"kind":1,"tags":[["-"]],"content":"hello members of the secret group","sig":"fa163f5cfb75d77d9b6269011872ee22b34fb48d23251e9879bb1e4ccbdd8aaaf4b6dc5f5084a65ef42c52fbcde8f3178bac3ba207de827ec513a6aa39fa684c"}]
+/* relay: */
+["AUTH", "<challenge>"]
+["OK", "cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2", false, "auth-required: this event may only be published by its author"]
+/* client: */
+["AUTH", {}]
+["EVENT",{"id":"cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2","pubkey":"79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798","created_at":1707409439,"kind":1,"tags":[["-"]],"content":"hello members of the secret group","sig":"fa163f5cfb75d77d9b6269011872ee22b34fb48d23251e9879bb1e4ccbdd8aaaf4b6dc5f5084a65ef42c52fbcde8f3178bac3ba207de827ec513a6aa39fa684c"}]
+["OK", "cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2", true, ""]
+```
+
+## Why
+
+There are multiple circumstances in which it would be beneficial to prevent the unlimited spreading of an event through all relays imaginable and restrict some to only a certain demographic or to a semi-closed community relay. Even when the information is public it may make sense to keep it compartimentalized across different relays.
+
+It's also possible to create closed access feeds with this when the publisher has some relationship with the relay and trusts the relay to not release their published events to anyone.
+
+Even though it's ultimately impossible to restrict the spread of information on the internet (for example, one of the members of the closed group may want to take an event intended to be restricted and republish it to other relays), most relays would be happy to not facilitate the acts of these so-called "pirates", in respect to the original decision of the author and therefore gladly reject these republish acts if given the means to.
+
+This NIP gives these authors and relays the means to clearly signal when a given event is not intended to be republished by third parties.

89.md

@@ -116,7 +116,7 @@ User B might see in their timeline an event referring to a `kind:31337` event (e
 User B's client, not knowing how to handle a `kind:31337` might display the event using its `alt` tag (as described in NIP-31). When the user clicks on the event, the application queries for a handler for this `kind`:
 
 ```json
-["REQ", <id>, '[{ "kinds": [31989], "#d": ["31337"], 'authors': [<user>, <users-contact-list>] }]']
+["REQ", <id>, { "kinds": [31989], "#d": ["31337"], "authors": [<user>, <users-contact-list>] }]
 ```
 
 User B, who follows User A, sees that `kind:31989` event and fetches the `a`-tagged event for the app and handler information.
@@ -127,5 +127,5 @@ User B's client sees the application's `kind:31990` which includes the informati
 Alternatively, users might choose to query directly for `kind:31990` for an event kind. Clients SHOULD be careful doing this and use spam-prevention mechanisms or querying high-quality restricted relays to avoid directing users to malicious handlers.
 
 ```json
-["REQ", <id>, '[{ "kinds": [31990], "#k": [<desired-event-kind>], 'authors': [...] }]']
+["REQ", <id>, { "kinds": [31990], "#k": [<desired-event-kind>], "authors": [...] }]
 ```

98.md

@@ -55,7 +55,8 @@ Using the `Authorization` HTTP header, the `kind 27235` event MUST be `base64` e
 
 Example HTTP Authorization header:
 ```
-Authorization: Nostr eyJpZCI6ImZlOTY0ZTc1ODkwMzM2MGYyOGQ4NDI0ZDA5MmRhODQ5NGVkMjA3Y2JhODIzMTEwYmUzYTU3ZGZlNGI1Nzg3MzQiLCJwdWJrZXkiOiI2M2ZlNjMxOGRjNTg1ODNjZmUxNjgxMGY4NmRkMDllMThiZmQ3NmFhYmMyNGEwMDgxY2UyODU2ZjMzMDUwNGVkIiwiY29udGVudCI6IiIsImtpbmQiOjI3MjM1LCJjcmVhdGVkX2F0IjoxNjgyMzI3ODUyLCJ0YWdzIjpbWyJ1cmwiLCJodHRwczovL2FwaS5zbm9ydC5zb2NpYWwvYXBpL3YxL241c3AvbGlzdCJdLFsibWV0aG9kIiwiR0VUIl1dLCJzaWciOiI1ZWQ5ZDhlYzk1OGJjODU0Zjk5N2JkYzI0YWMzMzdkMDA1YWYzNzIzMjQ3NDdlZmU0YTAwZTI0ZjRjMzA0MzdmZjRkZDgzMDg2ODRiZWQ0NjdkOWQ2YmUzZTVhNTE3YmI0M2IxNzMyY2M3ZDMzOTQ5YTNhYWY4NjcwNWMyMjE4NCJ9
+Authorization: Nostr 
+eyJpZCI6ImZlOTY0ZTc1ODkwMzM2MGYyOGQ4NDI0ZDA5MmRhODQ5NGVkMjA3Y2JhODIzMTEwYmUzYTU3ZGZlNGI1Nzg3MzQiLCJwdWJrZXkiOiI2M2ZlNjMxOGRjNTg1ODNjZmUxNjgxMGY4NmRkMDllMThiZmQ3NmFhYmMyNGEwMDgxY2UyODU2ZjMzMDUwNGVkIiwiY29udGVudCI6IiIsImtpbmQiOjI3MjM1LCJjcmVhdGVkX2F0IjoxNjgyMzI3ODUyLCJ0YWdzIjpbWyJ1IiwiaHR0cHM6Ly9hcGkuc25vcnQuc29jaWFsL2FwaS92MS9uNXNwL2xpc3QiXSxbIm1ldGhvZCIsIkdFVCJdXSwic2lnIjoiNWVkOWQ4ZWM5NThiYzg1NGY5OTdiZGMyNGFjMzM3ZDAwNWFmMzcyMzI0NzQ3ZWZlNGEwMGUyNGY0YzMwNDM3ZmY0ZGQ4MzA4Njg0YmVkNDY3ZDlkNmJlM2U1YTUxN2JiNDNiMTczMmNjN2QzMzk0OWEzYWFmODY3MDVjMjIxODQifQ
 ```
 
 ## Reference Implementations

README.md

@@ -76,6 +76,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-58: Badges](58.md)
 - [NIP-59: Gift Wrap](59.md)
 - [NIP-65: Relay List Metadata](65.md)
+- [NIP-70: Protected Events](70.md)
 - [NIP-71: Video Events](71.md)
 - [NIP-72: Moderated Communities](72.md)
 - [NIP-75: Zap Goals](75.md)
@@ -92,7 +93,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 ## Event Kinds
 | kind          | description                | NIP                      |
 | ------------- | -------------------------- | ------------------------ |
-| `0`           | Metadata                   | [01](01.md)              |
+| `0`           | User Metadata              | [01](01.md)              |
 | `1`           | Short Text Note            | [01](01.md)              |
 | `2`           | Recommend Relay            | 01 (deprecated)          |
 | `3`           | Follows                    | [02](02.md)              |
@@ -243,7 +244,9 @@ These tags are defined by at least one NIP and may vary between different kinds.
 
 | name              | value                                | other parameters                | NIP                                   |
 | ----------------- | ------------------------------------ | ------------------------------- | ------------------------------------- |
+| `-`               | --                                   | --                              | [70](70.md)                           |
 | `g`               | geohash                              | --                              | [52](52.md)                           |
+| `h`               | group id                             | --                              | [29](29.md)                           |
 | `i`               | identity                             | proof                           | [39](39.md)                           |
 | `k`               | kind number (string)                 | --                              | [18](18.md), [25](25.md), [72](72.md) |
 | `l`               | label, label namespace               | --                              | [32](32.md)                           |