mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-11-10 14:19:08 -05:00
Fix linting of 47.md
This commit is contained in:
parent
73db1893c4
commit
5237c5258e
28
47.md
28
47.md
|
@ -1,8 +1,6 @@
|
||||||
NIP-47
|
# NIP-47
|
||||||
======
|
|
||||||
|
|
||||||
Nostr Wallet Connect
|
## Nostr Wallet Connect
|
||||||
--------------------
|
|
||||||
|
|
||||||
`draft` `optional` `author:kiwiidb` `author:bumi` `author:semisol` `author:vitorpamplona`
|
`draft` `optional` `author:kiwiidb` `author:bumi` `author:semisol` `author:vitorpamplona`
|
||||||
|
|
||||||
|
@ -12,12 +10,13 @@ This NIP describes a way for clients to access a remote Lightning wallet through
|
||||||
|
|
||||||
## Terms
|
## Terms
|
||||||
|
|
||||||
* **client**: Nostr app on any platform that wants to pay Lightning invoices
|
- **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).
|
- **wallet service**: Nostr app that typically runs on an always-on computer (eg. in the cloud or on a Raspberry Pi).
|
||||||
|
|
||||||
## Events
|
## Events
|
||||||
|
|
||||||
There are three event kinds:
|
There are three event kinds:
|
||||||
|
|
||||||
- `NIP-47 info event`: 13194
|
- `NIP-47 info event`: 13194
|
||||||
- `NIP-47 request`: 23194
|
- `NIP-47 request`: 23194
|
||||||
- `NIP-47 response`: 23195
|
- `NIP-47 response`: 23195
|
||||||
|
@ -29,6 +28,7 @@ Both the request and response events SHOULD contain one `p` tag, containing the
|
||||||
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:
|
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:
|
Request:
|
||||||
|
|
||||||
```jsonc
|
```jsonc
|
||||||
{
|
{
|
||||||
"method": "pay_invoice", // method, string
|
"method": "pay_invoice", // method, string
|
||||||
|
@ -39,6 +39,7 @@ Request:
|
||||||
```
|
```
|
||||||
|
|
||||||
Response:
|
Response:
|
||||||
|
|
||||||
```jsonc
|
```jsonc
|
||||||
{
|
{
|
||||||
"result_type": "pay_invoice", //indicates the structure of the result field
|
"result_type": "pay_invoice", //indicates the structure of the result field
|
||||||
|
@ -57,6 +58,7 @@ The `error` field MUST contain a `message` field with a human readable error mes
|
||||||
If the command was succesful, the `error` field must be null.
|
If the command was succesful, the `error` field must be null.
|
||||||
|
|
||||||
### Error codes
|
### Error codes
|
||||||
|
|
||||||
- `RATE_LIMITED`: The client is sending commands too fast. It should retry in a few seconds.
|
- `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.
|
- `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.
|
- `INSUFFICIENT_BALANCE`: The wallet does not have enough funds to cover a fee reserve or the payment amount.
|
||||||
|
@ -67,20 +69,22 @@ If the command was succesful, the `error` field must be null.
|
||||||
- `OTHER`: Other error.
|
- `OTHER`: Other error.
|
||||||
|
|
||||||
## Nostr Wallet Connect URI
|
## Nostr Wallet Connect URI
|
||||||
|
|
||||||
**client** discovers **wallet service** by scanning a QR code, handling a deeplink or pasting in a 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:
|
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.
|
- `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** MUST use this to sign events and encrypt payloads 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.
|
- 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 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.
|
- 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.
|
- 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. Due to this NIP using ephemeral events, it is recommended to pick relays that do not close connections on inactivity to not drop events.
|
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
|
### Example connection string
|
||||||
|
|
||||||
```sh
|
```sh
|
||||||
nostr+walletconnect:b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558e9d4?relay=wss%3A%2F%2Frelay.damus.io&secret=71a8c14c1407c113601079c4302dab36460f0ccd0ad506f1f2dc73b5100e4f3c
|
nostr+walletconnect:b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558e9d4?relay=wss%3A%2F%2Frelay.damus.io&secret=71a8c14c1407c113601079c4302dab36460f0ccd0ad506f1f2dc73b5100e4f3c
|
||||||
```
|
```
|
||||||
|
@ -92,6 +96,7 @@ nostr+walletconnect:b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558
|
||||||
Description: Requests payment of an invoice.
|
Description: Requests payment of an invoice.
|
||||||
|
|
||||||
Request:
|
Request:
|
||||||
|
|
||||||
```jsonc
|
```jsonc
|
||||||
{
|
{
|
||||||
"method": "pay_invoice",
|
"method": "pay_invoice",
|
||||||
|
@ -102,6 +107,7 @@ Request:
|
||||||
```
|
```
|
||||||
|
|
||||||
Response:
|
Response:
|
||||||
|
|
||||||
```jsonc
|
```jsonc
|
||||||
{
|
{
|
||||||
"result_type": "pay_invoice",
|
"result_type": "pay_invoice",
|
||||||
|
@ -112,6 +118,7 @@ Response:
|
||||||
```
|
```
|
||||||
|
|
||||||
Errors:
|
Errors:
|
||||||
|
|
||||||
- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.
|
- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.
|
||||||
|
|
||||||
## Example pay invoice flow
|
## Example pay invoice flow
|
||||||
|
@ -122,4 +129,5 @@ Errors:
|
||||||
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.
|
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
|
## 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.
|
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.
|
||||||
|
|
Loading…
Reference in New Issue
Block a user