auth_url fix

Co-authored-by: monlovesmango <96307647+monlovesmango@users.noreply.github.com>

46.md

@@ -32,6 +32,10 @@ nostrconnect://<client-key-hex>?relay=wss://...&metadata={"name":"...", "url": "
 
 The signer scans the QR code and sends a `connect` message to the client in the specified relays.
 
+### Using a NIP-05
+
+Clients can choose to connect with a backend with just a NIP-05 for the target user. The user enters a NIP-05 Nostr Address, which the client uses to resolve to a pubkey. NIP-05's nostr.json SHOULD include a `nip46` root element of the pubkey and the relays that should be used to communicate with the remote signer for this pubkey.
+
 ## Event payloads
 
 Event payloads are [NIP-04](04.md)-encrypted JSON blobs that look like JSONRPC messages (their format is specified inside the `.content` of the event formats nelow).
@@ -64,6 +68,23 @@ And the events the remote signer sends to the client have the following format:
 
 The signer key will always be the key of the user who controls the signer device.
 
+### Auth URL response
+A signer can reply with a `result: "auth_url", error: "<url>"`. This response can provide an easier way for the user to authorize this client to perform an action. Clients can redirect/popup this URL so the user can take an action directly on the signer backend.
+
+When redirecting, the client can choose to add a `callbackUrl` query string parameter to tell the signer where to send the user after an action has been performed.
+
+#### Example flow:
+
+* User goes to a new client
+* Logins by typing their nip-05 "hello@example.com"
+* Client gets example.com/.well-known/nostr.json?name=hello
+* Client finds nip46 relays wss://relay.example.com and pubkey <123>
+* Client sends `connect` with remote pubkey `<123>`
+* Signer sends back `result: "auth_url", error: "https://auth.example.com/some-long-secret-path"`
+* Client opens popup for `auth_url` (for example `https://auth.example.com/ABCD`)
+* User authorizes the client to sign on behalf of pubkey <123>
+* Client's `connect` RPC call is `ack`ed.
+
 ### Methods
 
 - **connect**
@@ -96,4 +117,10 @@ The signer key will always be the key of the user who controls the signer device
 - **ping**
   - params: []
   - result: `"pong"`
+- **create_account**
+  - params: `["name", "domain", "email"]
+  - result: `generated-pubkey`
+
+#### Account creation
+This method creates a new key inside the backend. All params are optional. Username+domain can be specified so a NIP-05 record is created to point to this key. Email is an optional parameter that allows the backend to check if this user has already created an account in this backend. The `create_account` method should be sent to the pubkey of the bunker, which should match the root NIP-05 entry (`_@domain`).