[NIP 55] - Instructions on how to use the get_public_key method with content resolver (#2086)

45.md

@@ -14,17 +14,17 @@ Some queries a client may want to execute against connected relays are prohibiti
 
 ## Filters and return values
 
-This NIP defines the verb `COUNT`, which accepts a subscription id and filters as specified in [NIP 01](01.md) for the verb `REQ`. Multiple filters are OR'd together and aggregated into a single count result.
+This NIP defines the verb `COUNT`, which accepts a query id and filters as specified in [NIP 01](01.md) for the verb `REQ`. Multiple filters are OR'd together and aggregated into a single count result.
 
 ```
-["COUNT", <subscription_id>, <filters JSON>...]
+["COUNT", <query_id>, <filters JSON>...]
 ```
 
 Counts are returned using a `COUNT` response in the form `{"count": <integer>}`. Relays may use probabilistic counts to reduce compute requirements.
 In case a relay uses probabilistic counts, it MAY indicate it in the response with `approximate` key i.e. `{"count": <integer>, "approximate": <true|false>}`.
 
 ```
-["COUNT", <subscription_id>, {"count": <integer>}]
+["COUNT", <query_id>, {"count": <integer>}]
 ```
 
 Whenever the relay decides to refuse to fulfill the `COUNT` request, it MUST return a `CLOSED` message.
@@ -34,27 +34,27 @@ Whenever the relay decides to refuse to fulfill the `COUNT` request, it MUST ret
 ### Followers count
 
 ```
-["COUNT", <subscription_id>, {"kinds": [3], "#p": [<pubkey>]}]
-["COUNT", <subscription_id>, {"count": 238}]
+["COUNT", <query_id>, {"kinds": [3], "#p": [<pubkey>]}]
+["COUNT", <query_id>, {"count": 238}]
 ```
 
 ### Count posts and reactions
 
 ```
-["COUNT", <subscription_id>, {"kinds": [1, 7], "authors": [<pubkey>]}]
-["COUNT", <subscription_id>, {"count": 5}]
+["COUNT", <query_id>, {"kinds": [1, 7], "authors": [<pubkey>]}]
+["COUNT", <query_id>, {"count": 5}]
 ```
 
 ### Count posts approximately
 
 ```
-["COUNT", <subscription_id>, {"kinds": [1]}]
-["COUNT", <subscription_id>, {"count": 93412452, "approximate": true}]
+["COUNT", <query_id>, {"kinds": [1]}]
+["COUNT", <query_id>, {"count": 93412452, "approximate": true}]
 ```
 
 ### Relay refuses to count
 
 ```
-["COUNT", <subscription_id>, {"kinds": [4], "authors": [<pubkey>], "#p": [<pubkey>]}]
-["CLOSED", <subscription_id>, "auth-required: cannot count other people's DMs"]
+["COUNT", <query_id>, {"kinds": [1059], "#p": [<pubkey>]}]
+["CLOSED", <query_id>, "auth-required: cannot count other people's DMs"]
 ```

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://...`)
+
+

55.md

@@ -295,6 +295,8 @@ For the other types Signer Application returns the column "result"
 
 If the user chose to always reject the event, signer application will return the column "rejected" and you should not open signer application
 
+Clients SHOULD save the user pubkey locally and avoid calling the `get_public_key` after the user is logged in to the Client
+
 #### Methods
 
 - **get_public_key**
@@ -303,7 +305,7 @@ If the user chose to always reject the event, signer application will return the
     ```kotlin
     val result = context.contentResolver.query(
         Uri.parse("content://com.example.signer.GET_PUBLIC_KEY"),
-        listOf("login"),
+        listOf(hex_pub_key),
         null,
         null,
         null

60.md

@@ -28,9 +28,7 @@ This NIP doesn't deal with users' *receiving* money from someone else, it's just
     "content": nip44_encrypt([
         [ "privkey", "hexkey" ],
         [ "mint", "https://mint1" ],
-        [ "mint", "https://mint2" ],
-        [ "relay", "wss://relay1.example.com" ],
-        [ "relay", "wss://relay2.example.com" ]
+        [ "mint", "https://mint2" ]
     ]),
     "tags": []
 }
@@ -38,10 +36,9 @@ This NIP doesn't deal with users' *receiving* money from someone else, it's just
 
 The wallet event is an replaceable event `kind:17375`.
 
-Encrypted Tags:
+Tags:
 * `mint` - Mint(s) this wallet uses -- there MUST be one or more mint tags.
 * `privkey` - Private key used to unlock P2PK ecash. MUST be stored encrypted in the `.content` field. **This is a different private key exclusively used for the wallet, not associated in any way to the user's Nostr private key** -- This is only used for receiving [NIP-61](61.md) nutzaps.
-* `relay` - Relay(s) where the wallet's events (`kind:7374`, `kind:7375`, `kind:7376`) are published to and queried from. Clients MUST use these relays for all wallet operations. If no `relay` tags are present, clients SHOULD fall back to the user's [NIP-65](65.md) relay list.
 
 ### Token Event
 Token events are used to record unspent proofs.
@@ -107,14 +104,10 @@ All tags can be [NIP-44](44.md) encrypted. Clients SHOULD leave `e` tags with a
 Multiple `e` tags can be added, and should be encrypted, except for tags with the `redeemed` marker.
 
 ## Flow
-A client that wants to check for user's wallet information:
-
-1. Fetches the user's `kind:17375` wallet event from the user's [NIP-65](65.md) relays (or any known relays)
-2. Reads the `relay` tags from the wallet event to determine which relays to use for wallet operations
-3. If no `relay` tags are present, falls back to using the user's [NIP-65](65.md) relay list
+A client that wants to check for user's wallets information starts by fetching `kind:10019` events from the user's relays, if no event is found, it should fall back to using the user's [NIP-65](65.md) relays.
 
 ### Fetch wallet and token list
-Using the relays from the wallet event's `relay` tags (or NIP-65 relays if not specified), the client should fetch wallet and token events:
+From those relays, the client should fetch wallet and token events.
 
 `"kinds": [17375, 7375], "authors": ["<my-pubkey>"]`
 

66.md

@@ -53,7 +53,7 @@ Example:
     ["g", "ww8p1r4t8"],
     ["l", "en", "ISO-639-1"],
     ["t", "nsfw" ],
-    ["rtt-open", 234 ]
+    ["rtt-open", "234" ]
   ]
 }
 ```