Merge 5de76542c3 into 2ace01cf1a

47.md

@@ -667,3 +667,21 @@ Here are some properties that are recognized by some NWC clients:
   "sig": "31f57b369459b5306a5353aa9e03be7fbde169bc881c3233625605dd12f53548179def16b9fe1137e6465d7e4d5bb27ce81fd6e75908c46b06269f4233c845d8"
 }
 ```
+
+### Deep-links
+
+Wallet applications can register deeplinks in mobile systems to make it possible to create a linking UX that doesn't require the user scanning a QR code or pasting some code.
+
+`nostrnwc://connect` and `nostrnwc+{app_name}://connect` can be registered by wallet apps and queried by apps that want to receive an NWC pairing code.
+
+All URI parameters, MUST be URI-encoded.
+
+URI parameters:
+ * `appicon` -- URL to an icon of the client that wants to create a connection.
+ * `appname` -- Name of the client that wants to create a connection.
+ * `callback` -- URI schema the wallet should open with the connection string
+
+Once a connection has been created by the wallet, it should be returned to the client by opening the callback with the following parameters
+ * `value` -- NWC pairing code (e.g. `nostr+walletconnect://...`)
+
+

4e.md

@@ -40,9 +40,9 @@ There are probably other advantages to not tying the user's identity to the keys
 }
 ```
 
-5. Now **Bob** (keypairs `(b, B)`) will send a DM to **Alice**. Because Bob's client fetched Alice's `kind:10044` event, instead of computing the conversation key with `ecdh(b, A)` he does `ecdh(b, E) = S`
+5. Now **Bob** (keypair `(b, B)`) will send a DM to **Alice**. Because Bob's client fetched Alice's `kind:10044` event, instead of computing the conversation key with `ecdh(b, A)` he does `ecdh(b, E) = S`
-6. Because Alice knows `e` Alice can decrypt Bob's message doing `ecdh(e, B) = S` and all is good
+6. Because Alice knows `e`, she can decrypt Bob's message doing `ecdh(e, B) = S` and all is good
-7. Now the fun part starts: Alice has decided to use a client called **Tortilla** to chat on her phone, and **Tortilla* wants to do encryption stuff.
+7. Now the fun part starts: Alice has decided to use a client called **Tortilla** to chat on her phone, and **Tortilla** wants to do encryption stuff.
 8. **Tortilla** sees that Alice has a `kind:10044` published, which means **Tortilla** won't create a new key, **Tortilla** will have to ask for **Cope** to share that key securely. So **Tortilla** generates a local keypair `(t, T)` that won't be shown or leave the device ever, and **Tortilla** publishes an announcement (`kind:4454`) for that local key (signed by Alice):
 
 ```jsonc
@@ -56,22 +56,22 @@ There are probably other advantages to not tying the user's identity to the keys
 }
 ```
 
-9. **Tortilla** cannot proceed without known the secret key `e`, so it has to tell the user to turn **Cope** on.
+9. **Tortilla** cannot proceed without knowing the secret key `e`, so it has to tell the user to turn **Cope** on.
 10. Alice opens up **Cope** and **Cope** immediately looks for all `kind:4454` events from Alice, and sees that there is this app called "Tortilla on Android" signed by Alice herself, so **Cope** publishes the secret key `e`  nip44-encrypted to `ecdh(c, T)` -- in which `c` is the secret key of a keypair that **Cope** has just generated locally. **Cope** does that using a new event, `kind:4455`:
 
 ```jsonc
 {
   "kind": 4455,
-  "pubkey": "<A>"
+  "pubkey": "<A>",
   "tags": [
-    ["P", "<C>"]
+    ["P", "<C>"],
     ["p", "<T>"]
   ],
   "content": "<nip44(content=e, conversationkey=get_conversation_key(c, T))>"
 }
 ```
 
-12. Immediately **Tortilla** wakes up and sees the `kind:4455` that had just been published by **Cope**, decrypts the content using `ecdh(t, C)` and now **Tortilla** also knows the secret key `e`. **Tortilla** can now decrypt and encrypt the same things **Cope** could before.
+11. Immediately **Tortilla** wakes up and sees the `kind:4455` that has just been published by **Cope**, decrypts the content using `ecdh(t, C)` and now **Tortilla** also knows the secret key `e`. **Tortilla** can now decrypt and encrypt the same things **Cope** could before.
 
 ### The protocol flow again, now in a colorful infographic