Mirror/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2025-02-23 05:39:01 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

review comments

Browse Source
This commit is contained in:
Jeremy Klein 2025-02-13 09:39:49 -08:00
parent 9c9b0b422f
commit 2f32650832
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
47.md
View File

@ -53,7 +53,7 @@ It should also contain supported encryption modes as described in the [Encryptio
{
"kind": 13194,
"tags": [
["encryption", "nip44 nip04"], // List of supported encryption schemes as described in the Encryption section.
["encryption", "nip44_v2 nip04"], // List of supported encryption schemes as described in the Encryption section.
["notifications", "payment_received payment_sent"]
// ...
],
@ -78,11 +78,11 @@ Example request:
{
"kind" 23194,
"tags": [
["encryption", "nip44"],
["encryption", "nip44_v2"],
["p", "03..." ] // public key of the wallet service.
// ...
],
"content": nip44_encrypt({
"content": nip44_encrypt({ // Encryption type corresponds to the `encryption` tag.
"method": "pay_invoice", // method, string
"params": { // params, object
"invoice": "lnbc50n1..." // command-related data
@ -97,7 +97,7 @@ Example response:
{
"kind" 23195,
"tags": [
["encryption", "nip44"],
["encryption", "nip44_v2"],
["p", "03..." ] // public key of the requesting client app
["e", "1234"] // id of the request event this is responding to
// ...
@ -543,11 +543,11 @@ Notification:
## Encryption
The initial version of NWC used [NIP-04](04.md) for encryption which has been deprecated and replaced by [NIP-44](44.md). NIP-44 should always be preferred for encryption, but there may be legacy cases
where wither the **wallet service** or **client** has not yet migrated to NIP-44. The **wallet service** and **client** should negotiate the encryption method to use based on the `encryption` tags in the `info` event.
where the **wallet service** or **client** has not yet migrated to NIP-44. The **wallet service** and **client** should negotiate the encryption method to use based on the `encryption` tag in the `info` event.
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 nip04`)
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
@ -559,7 +559,7 @@ if a wallet service supports nip44, but also allows backwards-compatibility to n
{
"kind": 13194,
"tags": [
["encryption", "nip44 nip04"],
["encryption", "nip44_v2 nip04"],
// ...
],
"content": "pay_invoice get_balance make_invoice lookup_invoice list_transactions get_info",
@ -582,7 +582,7 @@ For example, if the client application supports nip44, the request event might l
{
"kind": 23194,
"tags": [
["encryption", "nip44"],
["encryption", "nip44_v2"],
// ...
],
// ...
@ -611,7 +611,7 @@ This NIP does not specify any requirements on the type of relays used. However,
"created_at": 1713883677,
"kind": 13194,
"tags": [
[ "encryption", "nip44 nip04" ],
[ "encryption", "nip44_v2 nip04" ],
[
"notifications",
"payment_received payment_sent"