upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPablo Fernandez <p@f7z.io>2024-01-08 16:19:46 +0000
committerPablo Fernandez <p@f7z.io>2024-01-08 16:19:46 +0000
commita411c4ac7f4531691e31faf39dff06d595d425ce (patch)
tree9a4043657a0071329d17ccaf171b8804c24fab3e
parentb3c0c4f64a1da331e0632d99f617a25e1d77cd28 (diff)
create_account command
-rw-r--r--46.md27
1 files changed, 27 insertions, 0 deletions
diff --git a/46.md b/46.md
index 1f8e6c8..9b633c2 100644
--- a/46.md
+++ b/46.md
@@ -32,6 +32,10 @@ nostrconnect://<client-key-hex>?relay=wss://...&metadata={"name":"...", "url": "
32 32
33The signer scans the QR code and sends a `connect` message to the client in the specified relays. 33The signer scans the QR code and sends a `connect` message to the client in the specified relays.
34 34
35### Using a NIP-05
36
37Clients 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.
38
35## Event payloads 39## Event payloads
36 40
37Event 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). 41Event 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:
64 68
65The signer key will always be the key of the user who controls the signer device. 69The signer key will always be the key of the user who controls the signer device.
66 70
71### Auth URL response
72A 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.
73
74When 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.
75
76#### Example flow:
77
78* User goes to a new client
79* Logins by typing their nip-05 "hello@example.com"
80* Client gets example.com/.well-known/nostr.json?name=hello
81* Client finds nip46 relays wss://relay.example.com and pubkey <123>
82* Client sends `connect` with remote pubkey `<123>`
83* Signer sends back `result: 'auth_url", error: "https://auth.examople.com/ABCD"`
84* Client opens popup `https://auth.examople.com/ABCD`
85* User authorizes the client to sign on behalf of pubkey <123>
86* Client's `connect` RPC call is `ack`ed.
87
67### Methods 88### Methods
68 89
69- **connect** 90- **connect**
@@ -96,4 +117,10 @@ The signer key will always be the key of the user who controls the signer device
96- **ping** 117- **ping**
97 - params: [] 118 - params: []
98 - result: `"pong"` 119 - result: `"pong"`
120- **create_account**
121 - params: `["username", "domain", "email"]
122 - result: `generated-pubkey`
123
124#### Account creation
125This 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`).
99 126