Sync with upstream

29.md

@@ -22,15 +22,15 @@ Relays are supposed to generate the events that describe group metadata and grou
 
 A group may be identified by a string in the format `<host>'<group-id>`. For example, a group with _id_ `abcdef` hosted at the relay `wss://groups.nostr.com` would be identified by the string `groups.nostr.com'abcdef`.
 
-Group identifiers must be strings restricted to the characters `a-z0-9-_`.
+Group identifiers must be strings restricted to the characters `a-z0-9-_`, and SHOULD be random in order to avoid name collisions.
 
-When encountering just the `<host>` without the `'<group-id>`, clients can choose to connect to the group with id `_`, which is a special top-level group dedicated to relay-local discussions.
-
-Group identifiers in most cases should be random or pseudo-random, as that mitigates message replay confusion and ensures they can be migrated or forked to other relays easily without risking conflicting with other groups using the same id in these new relays. This isn't a hard rule, as, for example, in `unmanaged` and/or ephemeral relays groups might not want to migrate ever, so they might not care about this. Notably, the `_` relay-local group isn't expected to be migrated ever.
+When encountering just the `<host>` without the `'<group-id>`, clients MAY infer `_` as the group id, which is a special top-level group dedicated to relay-local discussions.
 
 ## The `h` tag
 
-Events sent by users to groups (chat messages, text notes, moderation events etc) must have an `h` tag with the value set to the group _id_.
+Events sent by users to groups (chat messages, text notes, moderation events etc) MUST have an `h` tag with the value set to the group _id_.
+
+`h` tags MAY include the group's name as the second argument. This allows `unmanaged` groups to be assigned human-readable names without relay support.
 
 ## Timeline references
 
@@ -241,4 +241,4 @@ A definition for `kind:10009` was included in [NIP-51](51.md) that allows client
 
 ### Using `unmanaged` relays
 
-To prevent event leakage, replay and confusion, when using `unmanaged` relays, clients should include the [NIP-70](70.md) `-` tag, as just the `previous` tag won't be checked by other `unmanaged` relays.
+To prevent event leakage, when using `unmanaged` relays, clients should include the [NIP-70](70.md) `-` tag, as just the `previous` tag won't be checked by other `unmanaged` relays.

46.md

@@ -49,11 +49,21 @@ bunker://<remote-signer-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://a
 
 ### クライアントによって直接接続が開始される場合
 
-_クライアント_は次のような接続トークンを提供する:
+_クライアント_ はプロトコルとして`nostrconnect://`、オリジンとして`client-pubkey`を使用する接続トークンを提供する。追加情報はクエリパラメータとして渡す必要がある:
+
+- `relay` (必須) - _クライアント_ が _リモート署名器_ からの応答を待ち受ける1以上のリレーURL。
+-  `secret` (必須) - _リモート署名器_ が応答の`result`フィールドとして返す短いランダムな文字列。
+- `perms` (任意) - _クライアント_ が _リモート署名器_ による承認を要求している権限のカンマ区切りのリスト。
+- `name` (任意) - _クライアント_ アプリケーションの名前
+- `url` (任意) - _クライアント_ アプリケーションの正規URL
+- `image` (任意) - _クライアント_ アプリケーションを表す小さな画像
+
+以下に例を示す。
 
 ```
-nostrconnect://<client-pubkey>?relay=<wss://relay-to-connect-on>&metadata=<json metadata: {"name":"...", "url": "...", "description": "...", "perms": "..."}>&secret=<required-secret-value>
+nostrconnect://83f3b2ae6aa368e8275397b9c26cf550101d63ebaab900d19dd4a4429f5ad8f5?relay=wss%3A%2F%2Frelay1.example.com&perms=nip44_encrypt%2Cnip44_decrypt%2Csign_event%3A13%2Csign_event%3A14%2Csign_event%3A1059&name=My+Client&secret=0s8j2djs&relay=wss%3A%2F%2Frelay2.example2.com
 ```
+
 このトークンはユーザーによって_リモート署名器_に渡され、リモート署名器は指定されたリレーを介して`client-pubkey`に`connect`*応答*イベントを送る。クライアントは接続応答の作成者から`remote-signer-pubkey`を探す。接続相手のなりすましを防ぐために`secret`値を指定する必要があり (MUST) _クライアント_は`connect`応答によって得られた`secret`を検証する必要がある (MUST)。
 
 ## Request Events `kind: 24133`

47.md

@@ -175,7 +175,7 @@ Request:
 Response:
 
 For every invoice in the request, a separate response event is sent. To differentiate between the responses, each
-response event contains an `d` tag with the id of the invoice it is responding to, if no id was given, then the
+response event contains a `d` tag with the id of the invoice it is responding to, if no id was given, then the
 payment hash of the invoice should be used.
 
 ```jsonc

51.md

@@ -29,7 +29,7 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
 | Public chats      | 10005 | [NIP-28](28.md) chat channels the user is in                | `"e"` (kind:40 channel definitions)                                               |
 | Blocked relays    | 10006 | relays clients should never connect to                      | `"relay"` (relay URLs)                                                            |
 | Search relays     | 10007 | relays clients should use when performing search queries    | `"relay"` (relay URLs)                                                            |
-| Simple groups     | 10009 | [NIP-29](29.md) groups the user is in                       | `"group"` ([NIP-29](29.md) group ids + mandatory relay URL)                       |
+| Simple groups     | 10009 | [NIP-29](29.md) groups the user is in                       | `"group"` ([NIP-29](29.md) group id + relay URL), `"r"` for each relay in use     |
 | Interests         | 10015 | topics a user may be interested in and pointers             | `"t"` (hashtags) and `"a"` (kind:30015 interest set)                              |
 | Emojis            | 10030 | user preferred emojis and pointers to emoji sets            | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set)                  |
 | DM relays         | 10050 | Where to receive [NIP-17](17.md) direct messages            | `"relay"` (see [NIP-17](17.md))                                                   |

68.md

@@ -0,0 +1,92 @@
+NIP-68
+======
+
+Picture-first feeds
+-------------------
+
+`draft` `optional`
+
+This NIP defines event kind `20` for picture-first clients. Images must be self-contained. They are hosted externally and referenced using `imeta` tags.
+
+The idea is for this type of event to cater to Nostr clients resembling platforms like Instagram, Flickr, Snapchat, or 9GAG, where the picture itself takes center stage in the user experience.
+
+## Picture Events
+
+Picture events contain a `title` tag and description in the `.content`. 
+
+They may contain multiple images to be displayed as a single post.
+
+```jsonc
+{
+  "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
+  "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
+  "created_at": <Unix timestamp in seconds>,
+  "kind": 20,
+  "content": "<description of post>",
+  "tags": [
+    ["title", "<short title of post>"],
+
+    // Picture Data
+    [
+      "imeta",
+      "url https://nostr.build/i/my-image.jpg",
+      "m image/jpeg",
+      "blurhash eVF$^OI:${M{o#*0-nNFxakD-?xVM}WEWB%iNKxvR-oetmo#R-aen$",
+      "dim 3024x4032",
+      "alt A scenic photo overlooking the coast of Costa Rica",
+      "x <sha256 hash as specified in NIP 94>",
+      "fallback https://nostrcheck.me/alt1.jpg",
+      "fallback https://void.cat/alt1.jpg"
+    ],
+    [
+      "imeta",
+      "url https://nostr.build/i/my-image2.jpg",
+      "m image/jpeg",
+      "blurhash eVF$^OI:${M{o#*0-nNFxakD-?xVM}WEWB%iNKxvR-oetmo#R-aen$",
+      "dim 3024x4032",
+      "alt Another scenic photo overlooking the coast of Costa Rica",
+      "x <sha256 hash as specified in NIP 94>",
+      "fallback https://nostrcheck.me/alt2.jpg",
+      "fallback https://void.cat/alt2.jpg",
+
+      "annotate-user <32-bytes hex of a pubkey>:<posX>:<posY>" // Tag users in specific locations in the picture
+    ],
+
+    ["content-warning", "<reason>"], // if NSFW
+
+    // Tagged users
+    ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>"],
+    ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>"],
+
+    // Specify the media type for filters to allow clients to filter by supported kinds
+    ["m", "image/jpeg"],
+
+    // Hashes of each image to make them queryable
+    ["x", "<sha256>"]
+
+    // Hashtags
+    ["t", "<tag>"],
+    ["t", "<tag>"],
+
+    // location
+    ["location", "<location>"], // city name, state, country
+    ["g", "<geohash>"],
+
+    // When text is written in the image, add the tag to represent the language
+    ["L", "ISO-639-1"],
+    ["l", "en", "ISO-639-1"]
+  ]
+}
+```
+
+The `imeta` tag `annotate-user` places a user link in the specific position in the image.
+
+Only the following media types are accepted: 
+- `image/apng`: Animated Portable Network Graphics (APNG)
+- `image/avif`: AV1 Image File Format (AVIF)
+- `image/gif`: Graphics Interchange Format (GIF)
+- `image/jpeg`: Joint Photographic Expert Group image (JPEG)
+- `image/png`: Portable Network Graphics (PNG)
+- `image/webp`: Web Picture format (WEBP)
+
+Picture events might be used with [NIP-71](71.md)'s kind `34236` to display short vertical videos in the same feed.

86.md

@@ -0,0 +1,90 @@
+NIP-86
+======
+
+Relay Management API
+--------------------
+
+`draft` `optional`
+
+Relays may provide an API for performing management tasks. This is made available as a JSON-RPC-like request-response protocol over HTTP, on the same URI as the relay's websocket.
+
+When a relay receives an HTTP(s) request with a `Content-Type` header of `application/nostr+json+rpc` to a URI supporting WebSocket upgrades, it should parse the request as a JSON document with the following fields:
+
+```json
+{
+  "method": "<method-name>",
+  "params": ["<array>", "<of>", "<parameters>"]
+}
+```
+
+Then it should return a response in the format
+
+```json
+{
+  "result": {"<arbitrary>": "<value>"},
+  "error": "<optional error message, if the call has errored>"
+}
+```
+
+This is the list of **methods** that may be supported:
+
+* `supportedmethods`:
+  - params: `[]`
+  - result: `["<method-name>", "<method-name>", ...]` (an array with the names of all the other supported methods)
+* `banpubkey`:
+  - params: `["<32-byte-hex-public-key>", "<optional-reason>"]`
+  - result: `true` (a boolean always set to `true`)
+* `listbannedpubkeys`:
+  - params: `[]`
+  - result: `[{"pubkey": "<32-byte-hex>", "reason": "<optional-reason>"}, ...]`, an array of objects
+* `allowpubkey`:
+  - params: `["<32-byte-hex-public-key>", "<optional-reason>"]`
+  - result: `true` (a boolean always set to `true`)
+* `listallowedpubkeys`:
+  - params: `[]`
+  - result: `[{"pubkey": "<32-byte-hex>", "reason": "<optional-reason>"}, ...]`, an array of objects
+* `listeventsneedingmoderation`:
+  - params: `[]`
+  - result: `[{"id": "<32-byte-hex>", "reason": "<optional-reason>"}]`, an array of objects
+* `allowevent`:
+  - params: `["<32-byte-hex-event-id>", "<optional-reason>"]`
+  - result: `true` (a boolean always set to `true`)
+* `banevent`:
+  - params: `["<32-byte-hex-event-id>", "<optional-reason>"]`
+  - result: `true` (a boolean always set to `true`)
+* `listbannedevents`:
+  - params: `[]`
+  - result: `[{"id": "<32-byte hex>", "reason": "<optional-reason>"}, ...]`, an array of objects
+* `changerelayname`:
+  - params: `["<new-name>"]`
+  - result: `true` (a boolean always set to `true`)
+* `changerelaydescription`:
+  - params: `["<new-description>"]`
+  - result: `true` (a boolean always set to `true`)
+* `changerelayicon`:
+  - params: `["<new-icon-url>"]`
+  - result: `true` (a boolean always set to `true`)
+* `allowkind`:
+  - params: `[<kind-number>]`
+  - result: `true` (a boolean always set to `true`)
+* `disallowkind`:
+  - params: `[<kind-number>]`
+  - result: `true` (a boolean always set to `true`)
+* `listallowedkinds`:
+  - params: `[]`
+  - result: `[<kind-number>, ...]`, an array of numbers
+* `blockip`:
+  - params: `["<ip-address>", "<optional-reason>"]`
+  - result: `true` (a boolean always set to `true`)
+* `unblockip`:
+  - params: `["<ip-address>"]`
+  - result: `true` (a boolean always set to `true`)
+* `listblockedips`:
+  - params: `[]`
+  - result: `[{"ip": "<ip-address>", "reason": "<optional-reason>"}, ...]`, an array of objects
+
+### Authorization
+
+The request must contain an `Authorization` header with a valid [NIP-98](./98.md) event, except the `payload` tag is required. The `u` tag is the relay URL.
+
+If `Authorization` is not provided or is invalid, the endpoint should return a 401 response.