From e2f088286fcd324bb4754dcdf5ff10f4dc823b5b Mon Sep 17 00:00:00 2001 From: Semisol <45574030+Semisol@users.noreply.github.com> Date: Thu, 30 Mar 2023 00:35:13 +0300 Subject: [PATCH 1/7] NIP-47 Wallet Connect --- 47.md | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 47.md diff --git a/47.md b/47.md new file mode 100644 index 0000000..326100d --- /dev/null +++ b/47.md @@ -0,0 +1,112 @@ +NIP-47 +====== + +Nostr Wallet Connect +-------------------- + +`draft` `optional` `author:kiwiidb` `author:bumi` `author:semisol` `author:vitorpamplona` + +## Rationale + +Paying zaps should be possible without the user needing to open a different app to only pay a Lightning invoice. +This NIP describes a way for users to control a remote Lightning node or a custodial Lightning wallet. When self-hosting, this setup does not require the user to run their own server, thereby bypassing certain hurdles that are commonly encountered when trying to connect to a Lightning node remotely. + +## Terms + +* **client**: Nostr app on any platform that wants to pay Lightning invoices +* **wallet service**: Nostr app that typically runs on an always-on computer (eg. in the cloud or on a Raspberry Pi). + +## Events + +There are two event kinds: +- `NIP-47 request`: 23194 +- `NIP-47 response`: 23195 + +Both the request and response events SHOULD only contain one `p` tag, containing the public key of the **wallet service** if this is a request, and the public key of the **client** if this is a response. + +The content is encrypted with [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md), and is a JSON object. The content depends on the kind. + +Request: +```jsonc +{ + "cmd": "pay_invoice", // command, string + "data": { // data, object + "invoice": "lnbc50n1..." // command-related data + } +} +``` + +Response: +```jsonc +{ + "status": "ok", // status, "ok" | "error" + "event": "0123456789abcdef...", // event the command is in response to, string + "data": { // response data + "preimage": "0123456789abcdef..." // command-related data + } +} +``` + +The data field SHOULD contain a `message` field with a human readable error message if the status is `error`. + +## Nostr Wallet Connect URI +**client** discovers **wallet service** by scanning a QR code, handling a deeplink or pasting in a URI. + +The **wallet service** generates this connection URI with protocol `nostr+walletconnect:` and base path it's hex-encoded `pubkey` with the following query string parameters: + +- `relay` Required. URL of the relay where the **wallet service** is connected and will be listening for events. May be more than one. +- `secret` Required. 32-byte randomly generated hex encoded string. The **client** should use this to sign events when communicating with the **wallet service**. + - Authorization does not require passing keys back and forth. + - The user can have different keys for different applications. Keys can be revoked and created at will and have arbitrary constraints (eg. budgets). + - The key is harder to leak since it is not shown to the user and backed up. + - It improves privacy because the user's main key would not be linked to their payments. + +The **client** should then store this connection and use it when the user wants to perform actions like paying an invoice. Optionally it can display metadata about the connected **wallet service** from it's profile (name, image, url). + +### Example connection string +```sh +nostrwalletconnect:b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558e9d4?relay=wss%3A%2F%2Frelay.damus.io&secret=71a8c14c1407c113601079c4302dab36460f0ccd0ad506f1f2dc73b5100e4f3c +``` + +## Commands + +### `pay_invoice` + +Description: Requests payment of an invoice. + +Request: +```jsonc +{ + "invoice": "lnbc50n1..." // BOLT11 invoice, string +} +``` + +Response: +```jsonc +{ + "preimage": "0123456789abcdef..." // preimage after payment, string +} +``` + +### `balance` + +Description: Requests the balance of the wallet. + +Request: an empty JSON object. + +Response: +```jsonc +{ + "balance": 100000 // balance in msat, int +} +``` + +## Example pay invoice flow + +0. The user scans the QR code generated by the **wallet service** with their **client** application, they follow a `nostrwalletconnect:` deeplink or configure the connection details manually. +1. **client** sends an event to with **wallet service** service with kind `23194`. The content is a `pay_invoice` request. The private key is the secret from the connection string above. +2. **nostr-wallet-connect-service** verifies that the author's key is authorized to perform the payment, decrypts the payload and sends the payment. +3. **nostr-wallet-connect-service** responds to the event by sending an event with kind `23195` and content being a response either containing an error message or a preimage. + +## Using a dedicated relay +This NIP does not specify any requirements on the type of relays used. However, if the user is using a custodial service it might make sense to use a relay that is hosted by the custodial service. The relay may then enforce authentication to prevent metadata leaks. Not depending on a 3rd party relay would also improve reliability in this case. From 961f28285a739000277f489573f5b4c22053f27c Mon Sep 17 00:00:00 2001 From: Semisol <45574030+Semisol@users.noreply.github.com> Date: Thu, 30 Mar 2023 01:23:04 +0300 Subject: [PATCH 2/7] NIP-47: Fix up some things --- 47.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/47.md b/47.md index 326100d..96bf906 100644 --- a/47.md +++ b/47.md @@ -65,7 +65,7 @@ The **client** should then store this connection and use it when the user wants ### Example connection string ```sh -nostrwalletconnect:b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558e9d4?relay=wss%3A%2F%2Frelay.damus.io&secret=71a8c14c1407c113601079c4302dab36460f0ccd0ad506f1f2dc73b5100e4f3c +nostr+walletconnect:b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558e9d4?relay=wss%3A%2F%2Frelay.damus.io&secret=71a8c14c1407c113601079c4302dab36460f0ccd0ad506f1f2dc73b5100e4f3c ``` ## Commands @@ -103,10 +103,10 @@ Response: ## Example pay invoice flow -0. The user scans the QR code generated by the **wallet service** with their **client** application, they follow a `nostrwalletconnect:` deeplink or configure the connection details manually. +0. The user scans the QR code generated by the **wallet service** with their **client** application, they follow a `nostr+walletconnect:` deeplink or configure the connection details manually. 1. **client** sends an event to with **wallet service** service with kind `23194`. The content is a `pay_invoice` request. The private key is the secret from the connection string above. -2. **nostr-wallet-connect-service** verifies that the author's key is authorized to perform the payment, decrypts the payload and sends the payment. -3. **nostr-wallet-connect-service** responds to the event by sending an event with kind `23195` and content being a response either containing an error message or a preimage. +2. **wallet service** verifies that the author's key is authorized to perform the payment, decrypts the payload and sends the payment. +3. **wallet service** responds to the event by sending an event with kind `23195` and content being a response either containing an error message or a preimage. ## Using a dedicated relay This NIP does not specify any requirements on the type of relays used. However, if the user is using a custodial service it might make sense to use a relay that is hosted by the custodial service. The relay may then enforce authentication to prevent metadata leaks. Not depending on a 3rd party relay would also improve reliability in this case. From c232c9a46a279883f7d8e07db9f2ae6a79a784c6 Mon Sep 17 00:00:00 2001 From: Semisol <45574030+Semisol@users.noreply.github.com> Date: Mon, 3 Apr 2023 22:18:11 +0300 Subject: [PATCH 3/7] NIP-47: feedbacj --- 47.md | 69 ++++++++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 52 insertions(+), 17 deletions(-) diff --git a/47.md b/47.md index 96bf906..fd85e13 100644 --- a/47.md +++ b/47.md @@ -8,8 +8,7 @@ Nostr Wallet Connect ## Rationale -Paying zaps should be possible without the user needing to open a different app to only pay a Lightning invoice. -This NIP describes a way for users to control a remote Lightning node or a custodial Lightning wallet. When self-hosting, this setup does not require the user to run their own server, thereby bypassing certain hurdles that are commonly encountered when trying to connect to a Lightning node remotely. +This NIP describes a way for clients to access a remote Lightning wallet through a standardized protocol. Custodians may implement this, or the user may run a bridge that bridges their wallet/node and the Nostr Wallet Connect protocol. ## Terms @@ -47,7 +46,17 @@ Response: } ``` -The data field SHOULD contain a `message` field with a human readable error message if the status is `error`. +The data field SHOULD contain a `message` field with a human readable error message and a `code` field with the error code if the status is `error`. + +### Error codes +- `RATE_LIMITED`: The client is sending commands too fast. It should retry in a few seconds. +- `NOT_IMPLEMENTED`: The command is not known or is intentionally not implemented. +- `INSUFFICIENT_BALANCE`: The wallet does not have enough funds to cover a fee reserve or the payment amount. +- `QUOTA_EXCEEDED`: The wallet has exceeded +- `RESTRICTED`: This public key is not allowed to do this operation. +- `UNAUTHORIZED`: This public key has no wallet connected. +- `INTERNAL`: An internal error. +- `OTHER`: Other error. ## Nostr Wallet Connect URI **client** discovers **wallet service** by scanning a QR code, handling a deeplink or pasting in a URI. @@ -61,7 +70,7 @@ The **wallet service** generates this connection URI with protocol `nostr+wallet - The key is harder to leak since it is not shown to the user and backed up. - It improves privacy because the user's main key would not be linked to their payments. -The **client** should then store this connection and use it when the user wants to perform actions like paying an invoice. Optionally it can display metadata about the connected **wallet service** from it's profile (name, image, url). +The **client** should then store this connection and use it when the user wants to perform actions like paying an invoice. Due to this NIP using ephemeral events, it is recommended to pick relays that do not close connections on inactivity to not drop events. ### Example connection string ```sh @@ -70,6 +79,45 @@ nostr+walletconnect:b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558 ## Commands +### `get_info` + +Description: Get information about the wallet and service. + +Request: Empty object. + +Response: +```jsonc +{ + "balance": 100000, // balance in msat, int + // this should be capped at the quota allowed for this client + // to not report unspendable balance. + "implemented_commands": ["get_info", "pay_invoice"] // commands supported, string array + // extensions can be specified via command+extension: + // get_info+node_info +} +``` + +### `create_invoice` + +Description: Requests creation of an invoice. + +Request: +```jsonc +{ + "amount": 1000, // amount in msat, int + // must be a whole number of sats unless + // create_invoice+msat_amount is implemented. + "description": "memo" // a description, string, optional +} +``` + +Response: +```jsonc +{ + "invoice": "lnbc50n1..." // BOLT11 invoice, string +} +``` + ### `pay_invoice` Description: Requests payment of an invoice. @@ -88,19 +136,6 @@ Response: } ``` -### `balance` - -Description: Requests the balance of the wallet. - -Request: an empty JSON object. - -Response: -```jsonc -{ - "balance": 100000 // balance in msat, int -} -``` - ## Example pay invoice flow 0. The user scans the QR code generated by the **wallet service** with their **client** application, they follow a `nostr+walletconnect:` deeplink or configure the connection details manually. From de095e47580e63d91faf541e6a0c84ae5c0ca8fd Mon Sep 17 00:00:00 2001 From: kiwiidb <33457577+kiwiidb@users.noreply.github.com> Date: Thu, 27 Apr 2023 16:21:15 +0200 Subject: [PATCH 4/7] NIP-47: Implement feedback Co-authored-by: Semisol --- 47.md | 79 ++++++++++++++++++++--------------------------------------- 1 file changed, 27 insertions(+), 52 deletions(-) diff --git a/47.md b/47.md index fd85e13..083dabe 100644 --- a/47.md +++ b/47.md @@ -17,19 +17,22 @@ This NIP describes a way for clients to access a remote Lightning wallet through ## Events -There are two event kinds: +There are three event kinds: +- `NIP-47 info event`: 13194 - `NIP-47 request`: 23194 - `NIP-47 response`: 23195 -Both the request and response events SHOULD only contain one `p` tag, containing the public key of the **wallet service** if this is a request, and the public key of the **client** if this is a response. +The info event should be a replaceable event that is published by the **wallet service** on the relay to indicate which commands it supports. The content should be +a plaintext string with the supported commands, space-seperated, eg. `pay_invoice get_balance`. Only the `pay_invoice` command is described in this NIP, but other commands might be defined in different NIPs. +Both the request and response events SHOULD contain one `p` tag, containing the public key of the **wallet service** if this is a request, and the public key of the **client** if this is a response. The response event SHOULD contain an `e` tag with the id of the request event it is responding to. -The content is encrypted with [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md), and is a JSON object. The content depends on the kind. +The content of requests and responses is encrypted with [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md), and is a JSON-RPCish object with a semi-fixed structure: Request: ```jsonc { - "cmd": "pay_invoice", // command, string - "data": { // data, object + "method": "pay_invoice", // method, string + "params": { // params, object "invoice": "lnbc50n1..." // command-related data } } @@ -38,21 +41,26 @@ Request: Response: ```jsonc { - "status": "ok", // status, "ok" | "error" - "event": "0123456789abcdef...", // event the command is in response to, string - "data": { // response data + "result_type": "pay_invoice", //indicates the structure of the result field + "error": { //object, non-null in case of error + "code": "UNAUTHORIZED", //string error code, see below + "message": "human readable error message" + }, + "result": { // result, object. null in case of error. "preimage": "0123456789abcdef..." // command-related data } } ``` -The data field SHOULD contain a `message` field with a human readable error message and a `code` field with the error code if the status is `error`. +The `result_type` field MUST contain the name of the method that this event is responding to. +The `error` field MUST contain a `message` field with a human readable error message and a `code` field with the error code if the command was not succesful. +If the command was succesful, the `error` field must be null. ### Error codes - `RATE_LIMITED`: The client is sending commands too fast. It should retry in a few seconds. - `NOT_IMPLEMENTED`: The command is not known or is intentionally not implemented. - `INSUFFICIENT_BALANCE`: The wallet does not have enough funds to cover a fee reserve or the payment amount. -- `QUOTA_EXCEEDED`: The wallet has exceeded +- `QUOTA_EXCEEDED`: The wallet has exceeded its spending quota. - `RESTRICTED`: This public key is not allowed to do this operation. - `UNAUTHORIZED`: This public key has no wallet connected. - `INTERNAL`: An internal error. @@ -64,7 +72,7 @@ The data field SHOULD contain a `message` field with a human readable error mess The **wallet service** generates this connection URI with protocol `nostr+walletconnect:` and base path it's hex-encoded `pubkey` with the following query string parameters: - `relay` Required. URL of the relay where the **wallet service** is connected and will be listening for events. May be more than one. -- `secret` Required. 32-byte randomly generated hex encoded string. The **client** should use this to sign events when communicating with the **wallet service**. +- `secret` Required. 32-byte randomly generated hex encoded string. The **client** MUST use this to sign events and encrypt payloads when communicating with the **wallet service**. - Authorization does not require passing keys back and forth. - The user can have different keys for different applications. Keys can be revoked and created at will and have arbitrary constraints (eg. budgets). - The key is harder to leak since it is not shown to the user and backed up. @@ -79,45 +87,6 @@ nostr+walletconnect:b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558 ## Commands -### `get_info` - -Description: Get information about the wallet and service. - -Request: Empty object. - -Response: -```jsonc -{ - "balance": 100000, // balance in msat, int - // this should be capped at the quota allowed for this client - // to not report unspendable balance. - "implemented_commands": ["get_info", "pay_invoice"] // commands supported, string array - // extensions can be specified via command+extension: - // get_info+node_info -} -``` - -### `create_invoice` - -Description: Requests creation of an invoice. - -Request: -```jsonc -{ - "amount": 1000, // amount in msat, int - // must be a whole number of sats unless - // create_invoice+msat_amount is implemented. - "description": "memo" // a description, string, optional -} -``` - -Response: -```jsonc -{ - "invoice": "lnbc50n1..." // BOLT11 invoice, string -} -``` - ### `pay_invoice` Description: Requests payment of an invoice. @@ -125,14 +94,20 @@ Description: Requests payment of an invoice. Request: ```jsonc { - "invoice": "lnbc50n1..." // BOLT11 invoice, string + "method": "pay_invoice", + "params": { + "invoice": "lnbc50n1..." // bolt11 invoice + } } ``` Response: ```jsonc { - "preimage": "0123456789abcdef..." // preimage after payment, string + "result_type": "pay_invoice", + "result": { + "preimage": "0123456789abcdef..." // preimage of the payment + } } ``` From 5a8c463641b3dbaf927f7e0479ff046f0f6fb646 Mon Sep 17 00:00:00 2001 From: Semisol <45574030+Semisol@users.noreply.github.com> Date: Thu, 27 Apr 2023 17:24:20 +0300 Subject: [PATCH 5/7] NIP-47: Add error for payment failed --- 47.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/47.md b/47.md index 083dabe..aa58b5c 100644 --- a/47.md +++ b/47.md @@ -111,6 +111,9 @@ Response: } ``` +Errors: +- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar. + ## Example pay invoice flow 0. The user scans the QR code generated by the **wallet service** with their **client** application, they follow a `nostr+walletconnect:` deeplink or configure the connection details manually. From 7f75d0db33435fe9fcb6c04f18d0e610b17cebb4 Mon Sep 17 00:00:00 2001 From: mplorentz Date: Mon, 1 May 2023 14:15:06 -0400 Subject: [PATCH 6/7] Change NIP-21 URL->URI I think the `nostr:...` scheme is not actually a Uniform Resource Locator, because it doesn't tell you where the data is located. For instance if I see the string `nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9` I understand that this identifies a Nostr keypair but I don't know where to find data for that keypair. The scheme does fall under the definition of a Uniform Resource Identifier, or maybe even the stricter class Uniform Resource Name. But nobody talks about URNs, so maybe best to just use the less-specific term "URI" here. --- 21.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/21.md b/21.md index bfbb3ae..6246eb4 100644 --- a/21.md +++ b/21.md @@ -1,12 +1,12 @@ NIP-21 ====== -`nostr:` URL scheme +`nostr:` URI scheme ------------------- `draft` `optional` `author:fiatjaf` -This NIP standardizes the usage of a common URL scheme for maximum interoperability and openness in the network. +This NIP standardizes the usage of a common URI scheme for maximum interoperability and openness in the network. The scheme is `nostr:`. From d7c189d70bd1f9489a388920bc325576bd9cf8e4 Mon Sep 17 00:00:00 2001 From: "Robert C. Martin" Date: Tue, 2 May 2023 09:41:59 -0500 Subject: [PATCH 7/7] NIP11 example using curl. (#490) --- 11.md | 88 +++++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 58 insertions(+), 30 deletions(-) diff --git a/11.md b/11.md index a377364..8951835 100644 --- a/11.md +++ b/11.md @@ -69,18 +69,18 @@ are rejected or fail immediately. ```json { ... - "limitation": { - "max_message_length": 16384, - "max_subscriptions": 20, - "max_filters": 100, - "max_limit": 5000, - "max_subid_length": 100, - "min_prefix": 4, - "max_event_tags": 100, - "max_content_length": 8196, - "min_pow_difficulty": 30, - "auth_required": true, - "payment_required": true, + limitation: { + max_message_length: 16384, + max_subscriptions: 20, + max_filters: 100, + max_limit: 5000, + max_subid_length: 100, + min_prefix: 4, + max_event_tags: 100, + max_content_length: 8196, + min_pow_difficulty: 30, + auth_required: true, + payment_required: true, } ... } @@ -141,11 +141,11 @@ all, and preferably an error will be provided when those are received. ```json { ... - "retention": [ - { "kinds": [0, 1, [5, 7], [40, 49]], "time": 3600 }, - { "kinds": [[40000, 49999]], "time": 100 }, - { "kinds": [[30000, 39999]], "count": 1000 }, - { "time": 3600, "count": 10000 } + retention: [ + { kinds: [0, 1, [5, 7], [40, 49]], time: 3600 }, + { kinds: [[40000, 49999], time: 100 }, + { kinds: [[30000, 39999], count: 1000 }, + { time: 3600, count: 10000 } ] ... } @@ -154,7 +154,7 @@ all, and preferably an error will be provided when those are received. `retention` is a list of specifications: each will apply to either all kinds, or a subset of kinds. Ranges may be specified for the kind field as a tuple of inclusive start and end values. Events of indicated kind (or all) are then limited to a `count` -and/or time period. +and or time period. It is possible to effectively blacklist Nostr-based protocols that rely on a specific `kind` number, by giving a retention time of zero for those `kind` values. @@ -175,8 +175,8 @@ It is not possible to describe the limitations of each country's laws and policies which themselves are typically vague and constantly shifting. Therefore, this field allows the relay operator to indicate which -countries' laws might end up being enforced on them, and then -indirectly on their users' content. +country's' laws might end up being enforced on them, and then +indirectly on their users's content. Users should be able to avoid relays in countries they don't like, and/or select relays in more favourable zones. Exposing this @@ -185,7 +185,7 @@ flexibility is up to the client software. ```json { ... - "relay_countries": [ "CA", "US" ], + relay_countries: [ 'CA', 'US' ], ... } ``` @@ -208,9 +208,9 @@ To support this goal, relays MAY specify some of the following values. ```json { ... - "language_tags": [ "en", "en-419" ], - "tags": [ "sfw-only", "bitcoin-only", "anime" ], - "posting_policy": "https://example.com/posting-policy.html", + language_tags: [ 'en', 'en-419' ], + tags: [ 'sfw-only', 'bitcoin-only', 'anime' ], + posting_policy: 'https://example.com/posting-policy.html', ... } ``` @@ -220,7 +220,7 @@ To support this goal, relays MAY specify some of the following values. the major languages spoken on the relay. - `tags` is a list of limitations on the topics to be discussed. - For example `sfw-only` indicates that only "Safe For Work" content + For example `sfw-only` indicates hat only "Safe For Work" content is encouraged on this relay. This relies on assumptions of what the "work" "community" feels "safe" talking about. In time, a common set of tags may emerge that allow users to find relays that suit @@ -245,12 +245,40 @@ Relays that require payments may want to expose their fee schedules. ```json { ... - "payments_url": "https://my-relay/payments", - "fees": { - "admission": [{ "amount": 1000000, "unit": "msats" }], - "subscription": [{ "amount": 5000000, "unit": "msats", "period": 2592000 }], - "publication": [{ "kinds": [4], "amount": 100, "unit": "msats" }], + payments_url: "https://my-relay/payments", + fees: { + "admission": [{ amount: 1000000, unit: 'msats' }], + "subscription": [{ amount: 5000000, unit: 'msats', period: 2592000 }], + "publication": [{ kinds: [4], amount: 100, unit: 'msats' }], }, ... } ``` + +### Examples ### +As of 2 May 2023 the following `curl` command provided these results. + + >curl -H "Accept: application/nostr+json" https://eden.nostr.land + + {"name":"eden.nostr.land", + "description":"Eden Nostr Land - Toronto 1-01", + "pubkey":"00000000827ffaa94bfea288c3dfce4422c794fbb96625b6b31e9049f729d700", + "contact":"me@ricardocabral.io", + "supported_nips":[1,2,4,9,11,12,15,16,20,22,26,28,33,40], + "supported_nip_extensions":["11a"], + "software":"git+https://github.com/Cameri/nostream.git", + "version":"1.22.6", + "limitation":{"max_message_length":1048576, + "max_subscriptions":10, + "max_filters":2500, + "max_limit":5000, + "max_subid_length":256, + "min_prefix":4, + "max_event_tags":2500, + "max_content_length":65536, + "min_pow_difficulty":0, + "auth_required":false, + "payment_required":true}, + "payments_url":"https://eden.nostr.land/invoices", + "fees":{"admission":[{"amount":5000000,"unit":"msats"}], + "publication":[]}}