From a411c4ac7f4531691e31faf39dff06d595d425ce Mon Sep 17 00:00:00 2001 From: Pablo Fernandez Date: Mon, 8 Jan 2024 16:19:46 +0000 Subject: [PATCH] create_account command --- 46.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/46.md b/46.md index 1f8e6c8..9b633c2 100644 --- a/46.md +++ b/46.md @@ -32,6 +32,10 @@ nostrconnect://?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: ""`. 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 when 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.examople.com/ABCD"` +* Client opens popup `https://auth.examople.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: `["username", "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`).