laantungir/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2026-07-22 07:48:25 +00:00
Code Issues Packages Projects Releases Wiki Activity

NIP-46: add optional client metadata to connect request (#2381)

Browse Source
This commit is contained in:
DocNR
2026-06-23 07:40:17 -04:00
committed by GitHub
parent 3dc9705a4f
commit 2b1e71bf12
1 changed files with 12 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
46.md
View File

@@ -45,7 +45,7 @@ _remote-signer_ provides connection token in the form:
bunker://<remote-signer-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
```
_user_ passes this token to _client_, which then sends `connect` request to _remote-signer_ via the specified relays. Optional secret can be used for single successfully established connection only, _remote-signer_ SHOULD ignore new attempts to establish connection with old secret.
_user_ passes this token to _client_, which then sends `connect` request to _remote-signer_ via the specified relays. When connecting this way _client_ SHOULD include `optional_client_metadata` in the `connect` request (see [Client metadata](#client-metadata)), since unlike `nostrconnect://` this token carries no information identifying _client_. Optional secret can be used for single successfully established connection only, _remote-signer_ SHOULD ignore new attempts to establish connection with old secret.
### Direct connection initiated by the _client_
@@ -97,7 +97,7 @@ 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_perms>]` | `"ack"` OR `<required-secret-value>` |
| `connect` | `[<remote-signer-pubkey>, <optional_secret>, <optional_requested_perms>, <optional_client_metadata>]` | `"ack"` OR `<required-secret-value>` |
| `sign_event` | `[<{kind, content, tags, created_at}>]` | `json_stringified(<signed_event>)` |
| `ping` | `[]` | `"pong"` |
| `get_public_key` | `[]` | `<user-pubkey>` |
@@ -112,6 +112,16 @@ Each of the following are methods that the _client_ sends to the _remote-signer_
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.
### Client metadata
The `connect` method may be provided with `optional_client_metadata` so that _remote-signer_ can identify and label the connection. It is a JSON-stringified object whose fields mirror the `nostrconnect://` query parameters, all optional:
- `name` - the name of the _client_ application
- `url` - the canonical url of the _client_ application
- `image` - a small image representing the _client_ application
This is most useful for a connection initiated by _remote-signer_ (the `bunker://` flow), where — unlike `nostrconnect://` — _remote-signer_ has no other source for this information. To send metadata without requesting permissions, an empty string MUST be passed for `optional_requested_perms` so that the metadata occupies the fourth position. The metadata is _client_-supplied and unauthenticated; _remote-signer_ SHOULD treat it as a display hint only and MUST NOT use it for authorization decisions.
### 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.