auth_url fix

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

01.md

@@ -116,7 +116,7 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
   * `["REQ", <subscription_id>, <filters1>, <filters2>, ...]`, used to request events and subscribe to new updates.
   * `["CLOSE", <subscription_id>]`, used to stop previous subscriptions.
 
-`<subscription_id>` is an arbitrary, non-empty string of max length 64 chars. It represents a subscription per connection. Relays MUST manage `<subscription_id>`s independently for each WebSocket connection. `<subscription_id>`s are not guarantueed to be globally unique.
+`<subscription_id>` is an arbitrary, non-empty string of max length 64 chars. It represents a subscription per connection. Relays MUST manage `<subscription_id>`s independently for each WebSocket connection. `<subscription_id>`s are not guaranteed to be globally unique.
 
 `<filtersX>` is a JSON object that determines what events will be sent in that subscription, it can have the following attributes:
 

44.md

@@ -161,7 +161,7 @@ validation rules, refer to BIP-340.
 ### Implementation pseudocode
 
 The following is a collection of python-like pseudocode functions which implement the above primitives,
-intended to guide impelmenters. A collection of implementations in different languages is available at https://github.com/paulmillr/nip44.
+intended to guide implementers. A collection of implementations in different languages is available at https://github.com/paulmillr/nip44.
 
 ```py
 # Calculates length of the padded byte array.
@@ -286,7 +286,7 @@ Example of a test vector from the file:
 The file also contains intermediate values. A quick guidance with regards to its usage:
 
 - `valid.get_conversation_key`: calculate conversation_key from secret key sec1 and public key pub2
-- `valid.get_message_keys`: calculate chacha_key, chacha_nocne, hmac_key from conversation_key and nonce
+- `valid.get_message_keys`: calculate chacha_key, chacha_nonce, hmac_key from conversation_key and nonce
 - `valid.calc_padded_len`: take unpadded length (first value), calculate padded length (second value)
 - `valid.encrypt_decrypt`: emulate real conversation. Calculate pub2 from sec2, verify conversation_key from (sec1, pub2), encrypt, verify payload, then calculate pub1 from sec1, verify conversation_key from (sec2, pub1), decrypt, verify plaintext.
 - `valid.encrypt_decrypt_long_msg`: same as previous step, but instead of a full plaintext and payload, their checksum is provided.

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`).
 

50.md

@@ -41,7 +41,7 @@ implementation details between relays.
 Clients MAY verify that events returned by a relay match the specified query in a way that suits the
 client's use case, and MAY stop querying relays that have low precision.
 
-Relays SHOULD exclude spam from search results by default if they supports some form of spam filtering.
+Relays SHOULD exclude spam from search results by default if they support some form of spam filtering.
 
 ## Extensions
 

53.md

@@ -94,7 +94,7 @@ Common use cases include meeting rooms/workshops, watch-together activities, or
     ["title", "Adult Swim Metalocalypse"],
     ["summary", "Live stream from IPTV-ORG collection"],
     ["streaming", "https://adultswim-vodlive.cdn.turner.com/live/metalocalypse/stream.m3u8"],
-	["starts", "1687182672"]
+    ["starts", "1687182672"],
     ["status", "live"],
     ["t", "animation"],
     ["t", "iptv"],

57.md

@@ -111,6 +111,7 @@ When a client sends a `zap request` event to a server's lnurl-pay callback URL,
 5. There should be a `relays` tag with the relays to send the `zap receipt` to.
 6. If there is an `amount` tag, it MUST be equal to the `amount` query parameter.
 7. If there is an `a` tag, it MUST be a valid event coordinate
+8. There MUST be 0 or 1 `P` tags. If there is one, it MUST be equal to the `zap receipt`'s `pubkey`.
 
 The event MUST then be stored for use later, when the invoice is paid.
 
@@ -128,7 +129,7 @@ The following should be true of the `zap receipt` event:
 
 - The `content` SHOULD be empty.
 - The `created_at` date SHOULD be set to the invoice `paid_at` date for idempotency.
-- `tags` MUST include the `p` tag AND optional `e` tag from the `zap request` AND optional `a` tag from the `zap request`.
+- `tags` MUST include the `p` tag (zap recipient) AND optional `e` tag from the `zap request` AND optional `a` tag from the `zap request` AND optional `P` tag from the pubkey of the zap request (zap sender).
 - The `zap receipt` MUST have a `bolt11` tag containing the description hash bolt11 invoice.
 - The `zap receipt` MUST contain a `description` tag which is the JSON-encoded invoice description.
 - `SHA256(description)` MUST match the description hash in the bolt11 invoice.
@@ -148,13 +149,13 @@ Example `zap receipt`:
     "kind": 9735,
     "tags": [
       ["p", "32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245"],
+      ["P", "97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322"],
       ["e", "3624762a1274dd9636e0c552b53086d70bc88c165bc4dc0f9e836a1eaf86c3b8"],
       ["bolt11", "lnbc10u1p3unwfusp5t9r3yymhpfqculx78u027lxspgxcr2n2987mx2j55nnfs95nxnzqpp5jmrh92pfld78spqs78v9euf2385t83uvpwk9ldrlvf6ch7tpascqhp5zvkrmemgth3tufcvflmzjzfvjt023nazlhljz2n9hattj4f8jq8qxqyjw5qcqpjrzjqtc4fc44feggv7065fqe5m4ytjarg3repr5j9el35xhmtfexc42yczarjuqqfzqqqqqqqqlgqqqqqqgq9q9qxpqysgq079nkq507a5tw7xgttmj4u990j7wfggtrasah5gd4ywfr2pjcn29383tphp4t48gquelz9z78p4cq7ml3nrrphw5w6eckhjwmhezhnqpy6gyf0"],
-      ["description", "{\"pubkey\":\"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245\",\"content\":\"\",\"id\":\"d9cc14d50fcb8c27539aacf776882942c1a11ea4472f8cdec1dea82fab66279d\",\"created_at\":1674164539,\"sig\":\"77127f636577e9029276be060332ea565deaf89ff215a494ccff16ae3f757065e2bc59b2e8c113dd407917a010b3abd36c8d7ad84c0e3ab7dab3a0b0caa9835d\",\"kind\":9734,\"tags\":[[\"e\",\"3624762a1274dd9636e0c552b53086d70bc88c165bc4dc0f9e836a1eaf86c3b8\"],[\"p\",\"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245\"],[\"relays\",\"wss://relay.damus.io\",\"wss://nostr-relay.wlvs.space\",\"wss://nostr.fmt.wiz.biz\",\"wss://relay.nostr.bg\",\"wss://nostr.oxtr.dev\",\"wss://nostr.v0l.io\",\"wss://brb.io\",\"wss://nostr.bitcoiner.social\",\"ws://monad.jb55.com:8080\",\"wss://relay.snort.social\"]]}"],
+      ["description", "{\"pubkey\":\"97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322\",\"content\":\"\",\"id\":\"d9cc14d50fcb8c27539aacf776882942c1a11ea4472f8cdec1dea82fab66279d\",\"created_at\":1674164539,\"sig\":\"77127f636577e9029276be060332ea565deaf89ff215a494ccff16ae3f757065e2bc59b2e8c113dd407917a010b3abd36c8d7ad84c0e3ab7dab3a0b0caa9835d\",\"kind\":9734,\"tags\":[[\"e\",\"3624762a1274dd9636e0c552b53086d70bc88c165bc4dc0f9e836a1eaf86c3b8\"],[\"p\",\"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245\"],[\"relays\",\"wss://relay.damus.io\",\"wss://nostr-relay.wlvs.space\",\"wss://nostr.fmt.wiz.biz\",\"wss://relay.nostr.bg\",\"wss://nostr.oxtr.dev\",\"wss://nostr.v0l.io\",\"wss://brb.io\",\"wss://nostr.bitcoiner.social\",\"ws://monad.jb55.com:8080\",\"wss://relay.snort.social\"]]}"],
       ["preimage", "5d006d2cf1e73c7148e7519a4c68adc81642ce0e25a432b2434c99f97344c15f"]
     ],
     "content": "",
-    "sig": "b0a3c5c984ceb777ac455b2f659505df51585d5fd97a0ec1fdb5f3347d392080d4b420240434a3afd909207195dac1e2f7e3df26ba862a45afd8bfe101c2b1cc"
   }
 ```