nip46: switch_relays.

29.md

@@ -120,21 +120,21 @@ Clients can send these events to a relay in order to accomplish a moderation act
 
 Each moderation action uses a different kind and requires different arguments, which are given as tags. These are defined in the following table:
 
-| kind | name                | tags                                           |
-| ---  | ---                 | ---                                            |
-| 9000 | `put-user`          | `p` with pubkey hex and optional roles         |
-| 9001 | `remove-user`       | `p` with pubkey hex                            |
-| 9002 | `edit-metadata`     | fields from `kind:39000` to be modified        |
-| 9005 | `delete-event`      | `e` with event id hex                          |
-| 9007 | `create-group`      |                                                |
-| 9008 | `delete-group`      |                                                |
-| 9009 | `create-invite`     |                                                |
+| kind | name            | tags                                                                             |
+| ---  | ---             | ---                                                                              |
+| 9000 | `put-user`      | `p` with pubkey hex and optional roles                                           |
+| 9001 | `remove-user`   | `p` with pubkey hex                                                              |
+| 9002 | `edit-metadata` | fields to be modified, and optionally `unrestricted`, `open`, `visible` `public` |
+| 9005 | `delete-event`  | `e` with event id hex                                                            |
+| 9007 | `create-group`  |                                                                                  |
+| 9008 | `delete-group`  |                                                                                  |
+| 9009 | `create-invite` | arbitrary `code`                                                                 |
 
 It's expected that the group state (of who is an allowed member or not, who is an admin and with which permission or not, what are the group name and picture etc) can be fully reconstructed from the canonical sequence of these events.
 
 ### Group metadata events
 
-These events contain the group id in a `d` tag instead of the `h` tag. They MUST be created by the relay master key only and a single instance of each (or none) should exist at all times for each group. They are merely informative but should reflect the latest group state (as it was changed by moderation events over time).
+These events contain the group id in a `d` tag instead of the `h` tag. They MUST be created by the relay master key only (as stated by the [NIP-11](11.md) `"self"` pubkey) and a single instance of each (or none) should exist at all times for each group. They are merely informative but should reflect the latest group state (as it was changed by moderation events over time).
 
 - *group metadata* (`kind:39000`) (optional)
 

46.md

@@ -97,18 +97,25 @@ Each of the following are methods that the _client_ sends to the _remote-signer_
 
 | Command                  | Params                                                                        | Result                                                                 |
 | ------------------------ | -------------------------------------------------                             | ---------------------------------------------------------------------- |
-| `connect`                | `[<remote-signer-pubkey>, <optional_secret>, <optional_requested_permissions>]`        | "ack" OR `<required-secret-value>`                                                                  |
+| `connect`                | `[<remote-signer-pubkey>, <optional_secret>, <optional_requested_perms>]`     | `"ack"` OR `<required-secret-value>`                                   |
 | `sign_event`             | `[<{kind, content, tags, created_at}>]`                                       | `json_stringified(<signed_event>)`                                     |
-| `ping`                   | `[]`                                                                          | "pong"                                                                 |
-| `get_public_key`         | `[]`                                                                          | `<user-pubkey>`                                                         |
+| `ping`                   | `[]`                                                                          | `"pong"`                                                               |
+| `get_public_key`         | `[]`                                                                          | `<user-pubkey>`                                                        |
 | `nip04_encrypt`          | `[<third_party_pubkey>, <plaintext_to_encrypt>]`                              | `<nip04_ciphertext>`                                                   |
 | `nip04_decrypt`          | `[<third_party_pubkey>, <nip04_ciphertext_to_decrypt>]`                       | `<plaintext>`                                                          |
 | `nip44_encrypt`          | `[<third_party_pubkey>, <plaintext_to_encrypt>]`                              | `<nip44_ciphertext>`                                                   |
 | `nip44_decrypt`          | `[<third_party_pubkey>, <nip44_ciphertext_to_decrypt>]`                       | `<plaintext>`                                                          |
+| `switch_relays`          | `[]`                                                                          | `["<relay-url>", "<relay-url>", ...]` OR `null`                        |
 
 ### Requested permissions
 
-The `connect` method may be provided with `optional_requested_permissions` for user convenience. The permissions are a comma-separated list of `method[:params]`, i.e. `nip44_encrypt,sign_event:4` meaning permissions to call `nip44_encrypt` and to call `sign_event` with `kind:4`. Optional parameter for `sign_event` is the kind number, parameters for other methods are to be defined later. Same permission format may be used for `perms` field of `metadata` in `nostrconnect://` string.
+The `connect` method may be provided with `optional_requested_perms` for user convenience. The permissions are a comma-separated list of `method[:params]`, i.e. `nip44_encrypt,sign_event:4` meaning permissions to call `nip44_encrypt` and to call `sign_event` with `kind:4`. Optional parameter for `sign_event` is the kind number, parameters for other methods are to be defined later. Same permission format may be used for `perms` field of `metadata` in `nostrconnect://` string.
+
+### Switching relays
+
+At all times, the _remote-signer_ should be in control of what relays are being used for the connection between it and the _client_. Therefore it should be possible for it to evolve its set of relays over time as old relays go out of operation and new ones appear. Even more importantly, in the case of the connection initiated by the _client_ the client may pick relays completely foreign to the _remote-signer_'s preferences, so it must be possible for it to switch those immediately.
+
+Therefore, compliant clients should send a `switch_relays` request immediately upon establishing a connection (always, or at reasonable intervals). Upon receiving such requests, the _remote-signer_ should reply with its updated list of relays, or `null` if there is nothing to be changed. Immediately upon receiving an updated relay list, the _client_ should update its local state and send further requests on the new relays. The `remote-signer` should then be free to disconnect from the previous relays if that is desired.
 
 ## Response Events `kind:24133`