laantungir/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2026-02-12 10:54:32 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: simplify nip-47 (#2210)

Browse Source
This commit is contained in:
Roland
2026-02-11 20:45:14 +07:00
committed by GitHub
parent 567ad57a4b
commit e83326e6d4
1 changed files with 3 additions and 97 deletions
Download Patch File Download Diff File Expand all files Collapse all files

100
47.md
View File

@@ -28,7 +28,7 @@ Fundamentally NWC is communication between a **client** and **wallet service** b
4. Once the payment is complete the **wallet service** will send an encrypted `response` (kind 23195) to the **user** over the relay(s) in the URI.
5. The **wallet service** may send encrypted notifications (kind 23197 or 23196) of wallet events (such as a received payment) to the **client**.
5. The **wallet service** may send encrypted notifications (kind 23197) of wallet events (such as a received payment) to the **client**.
## Events
@@ -134,8 +134,6 @@ The content of notifications is encrypted with [NIP44](44.md) (or NIP-04 for leg
}
```
_Note on backwards-compatibility:_ If a **wallet service** supports both nip44 and nip04 for legacy client apps, it should publish both notification events for each notification - kind 23196 encrypted with NIP-04, and kind 23197 encrypted with NIP-44. It is up to the **client** to decide which event to listen to based on its supported encryption and declared supported encryption schemes of the **wallet service** in the `info` event.
### 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.
@@ -207,42 +205,6 @@ Response:
Errors:
- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.
### `multi_pay_invoice`
Description: Requests payment of multiple invoices.
Request:
```jsonc
{
"method": "multi_pay_invoice",
"params": {
"invoices": [
{"id":"4da52c32a1", "invoice": "lnbc1...", "amount": 123}, // bolt11 invoice and amount in msats, amount is optional
{"id":"3da52c32a1", "invoice": "lnbc50n1...", "metadata": {} }, // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc, optional
],
}
}
```
Response:
For every invoice in the request, a separate response event is sent. To differentiate between the responses, each
response event contains a `d` tag with the id of the invoice it is responding to; if no id was given, then the
payment hash of the invoice should be used.
```jsonc
{
"result_type": "multi_pay_invoice",
"result": {
"preimage": "0123456789abcdef...", // preimage of the payment
"fees_paid": 123, // value in msats, optional
}
}
```
Errors:
- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.
### `pay_keysend`
Request:
@@ -277,44 +239,6 @@ Response:
Errors:
- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.
### `multi_pay_keysend`
Description: Requests multiple keysend payments.
Has an array of keysends, these follow the same semantics as `pay_keysend`, just done in a batch
Request:
```jsonc
{
"method": "multi_pay_keysend",
"params": {
"keysends": [
{"id": "4c5b24a351", "pubkey": "03...", "amount": 123},
{"id": "3da52c32a1", "pubkey": "02...", "amount": 567, "preimage": "abc123..", "tlv_records": [{"type": 696969, "value": "77616c5f6872444873305242454d353736"}]},
],
}
}
```
Response:
For every keysend in the request, a separate response event is sent. To differentiate between the responses, each
response event contains a `d` tag with the id of the keysend it is responding to; if no id was given, then the
pubkey should be used.
```jsonc
{
"result_type": "multi_pay_keysend",
"result": {
"preimage": "0123456789abcdef...", // preimage of the payment
"fees_paid": 123, // value in msats, optional
}
}
```
Errors:
- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.
### `make_invoice`
Request:
@@ -671,23 +595,6 @@ The negotiation works as follows.
1. The **wallet service** includes an `encryption` tag in the `info` event. This tag contains a space-separated list of encryption schemes that the **wallet service** supports (eg. `nip44_v2 nip04`)
2. The **client application** includes an `encryption` tag in each request event. This tag contains the encryption scheme which should be used for the request. The **client application** should always prefer nip44 if supported by the **wallet service**.
### Info event
First, the **wallet service** adds an `encryption` tag to its `info` event containing a space-separated list of encryption schemes it supports. For example,
if a wallet service supports nip44, but also allows backwards-compatibility to nip04 client applications, its `encryption` tag in the `info` event might look something like:
```jsonc
{
"kind": 13194,
"tags": [
["encryption", "nip44_v2 nip04"],
// ...
],
"content": "pay_invoice get_balance make_invoice lookup_invoice list_transactions get_info",
// ...
}
```
When a **client application** establishes a connection, it should read the info event and look for the `encryption` tag.
**Absence of this tag implies that the wallet only supports nip04.**
@@ -714,7 +621,7 @@ If the **wallet service** does not support the specified encryption scheme, it w
### Notification events
As described above in the [Notifications](#notifications) section, if a **wallet service** supports both nip04 and nip44, it should publish two notification events for each notification - kind 23196 encrypted with NIP-04, and kind 23197 encrypted with NIP-44. If the **wallet service** only supports nip44, it should only publish kind 23197 events.
If a **wallet service** supports both nip04 and nip44, it should publish two notification events for each notification - kind 23196 encrypted with NIP-04, and kind 23197 encrypted with NIP-44. If the **wallet service** only supports nip44, it should only publish kind 23197 events.
The **client** should check the `encryption` tag in the `info` event to determine which encryption schemes the **wallet service** supports, and listen to the appropriate notification event.
@@ -785,6 +692,7 @@ Here are some properties that are recognized by some NWC clients:
* Calls `settle_hold_invoice` with the original preimage to release funds, or
* Calls `cancel_hold_invoice` with payment hash to abort.
### 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.
@@ -800,5 +708,3 @@ URI parameters:
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://...`)