Sync with upstream including CONFLICT

11.md

@@ -262,15 +262,15 @@ processed by appropriate client software.
 
 Relays that require payments may want to expose their fee schedules.
 
-```json
+```jsonc
 {
   "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" }],
   },
-  ...
+  // other fields...
 }
 ```
 

17.md

@@ -47,7 +47,7 @@ An optional `subject` tag defines the current name/topic of the conversation. An
 
 Following [NIP-59](59.md), the **unsigned** `kind:14` chat message must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
 
-```js
+```jsonc
 {
   "id": "<usual hash>",
   "pubkey": randomPublicKey,

22.md

@@ -13,7 +13,7 @@ It uses `kind:1111` with plaintext `.content` (no HTML, Markdown, or other forma
 Comments MUST point to the root scope using uppercase tag names (e.g. `K`, `E`, `A` or `I`)
 and MUST point to the parent item with lowercase ones (e.g. `k`, `e`, `a` or `i`).
 
-```js
+```jsonc
 {
   kind: 1111,
   content: '<comment>',
@@ -56,7 +56,7 @@ If the parent item is an event, a `p` tag set to the parent event's author SHOUL
 
 A comment on a blog post looks like this:
 
-```js
+```jsonc
 {
   kind: 1111,
   content: 'Great blog post!',
@@ -79,7 +79,7 @@ A comment on a blog post looks like this:
 
 A comment on a [NIP-94](94.md) file looks like this:
 
-```js
+```jsonc
 {
   kind: 1111,
   content: 'Great file!',
@@ -100,7 +100,7 @@ A comment on a [NIP-94](94.md) file looks like this:
 
 A reply to a comment looks like this:
 
-```js
+```jsonc
 {
   kind: 1111,
   content: 'This is a reply to "Great file!"',
@@ -121,7 +121,7 @@ A reply to a comment looks like this:
 
 A comment on a website's url looks like this:
 
-```js
+```jsonc
 {
   kind: 1111,
   content: 'Nice article!',
@@ -142,7 +142,7 @@ A comment on a website's url looks like this:
 
 A podcast comment example:
 
-```js
+```jsonc
 {
   id: "80c48d992a38f9c445b943a9c9f1010b396676013443765750431a9004bdac05",
   pubkey: "252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111",
@@ -164,7 +164,7 @@ A podcast comment example:
 
 A reply to a podcast comment:
 
-```js
+```jsonc
 {
   kind: 1111,
   content: "I'm replying to the above comment.",

24.md

@@ -6,7 +6,11 @@ NIP-24
 
 `draft` `optional`
 
+<<<<<<< HEAD
 このNIPはイベントに加えられる追加の任意のフィールドを定義する。
+=======
+This NIP keeps track of extra optional fields that can added to events which are not defined anywhere else but have become _de facto_ standards and other minor implementation possibilities that do not deserve their own NIP and do not have a place in other NIPs.
+>>>>>>> upstream/master
 
 kind 0
 ======

29.md

@@ -64,39 +64,7 @@ These are the events expected to be found in NIP-29 groups.
 
 ### Normal user-created events
 
-These events generally can be sent by all members of a group and they require the `h` tag to be present so they're attached to a specific group.
-
-- _chat message_ (`kind:9`)
-
-This is the basic unit of a _chat message_ sent to a group.
-
-```jsonc
-  "kind": 9,
-  "content": "hello my friends lovers of pizza",
-  "tags": [
-    ["h", "<group-id>"],
-    ["previous", "<event-id-first-chars>", "<event-id-first-chars>", /*...*/]
-  ]
-  // other fields...
-```
-
-- _thread root post_ (`kind:11`)
-
-This is the basic unit of a forum-like root thread post sent to a group.
-
-```jsonc
-  "kind": 11,
-  "content": "hello my friends lovers of pizza",
-  "tags": [
-    ["h", "<group-id>"],
-    ["previous", "<event-id-first-chars>", "<event-id-first-chars>", /*...*/]
-  ]
-  // other fields...
-```
-
-- _other events_:
-
-Groups may also accept other events, like [NIP-22](22.md) comments as threaded replies to both chats messages and threads, long-form articles, calendar, livestreams, market announcements and so on. These should be as defined in their respective NIPs, with the addition of the `h` tag.
+Groups may accept any event kind, including chats, threads, long-form articles, calendar, livestreams, market announcements and so on. These should be as defined in their respective NIPs, with the addition of the `h` tag.
 
 ### User-related group management events
 
@@ -141,7 +109,7 @@ These are events expected to be sent by the relay master key or by group admins
 
 Clients can send these events to a relay in order to accomplish a moderation action. Relays must check if the pubkey sending the event is capable of performing the given action based on its role and the relay's internal policy (see also the description of `kind:39003`).
 
-```json
+```jsonc
 {
   "kind": 90xx,
   "content": "optional reason",

46.md

@@ -58,7 +58,7 @@ nostrconnect://<client-pubkey>?relay=<wss://relay-to-connect-on>&metadata=<json
 
 ## Request Events `kind: 24133`
 
-```js
+```jsonc
 {
     "kind": 24133,
     "pubkey": <local_keypair_pubkey>,
@@ -136,7 +136,7 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted
 
 ### Signature request
 
-```js
+```jsonc
 {
     "kind": 24133,
     "pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86",
@@ -156,7 +156,7 @@ The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted
 
 ### Response event
 
-```js
+```jsonc
 {
     "kind": 24133,
     "pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
@@ -196,7 +196,7 @@ _client_ should display (in a popup or new tab) the URL from the `error` field a
 ### Announcing _remote-signer_ metadata
 
 _remote-signer_ MAY publish it's metadata by using [NIP-05](05.md) and [NIP-89](89.md). With NIP-05, a request to `<remote-signer>/.well-known/nostr.json?name=_` MAY return this:
-```
+```jsonc
 {
     "names":{
         "_": <remote-signer-app-pubkey>,

47.md

@@ -8,32 +8,42 @@ Nostr Wallet Connect
 
 ## Rationale
 
-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.
+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
 
-* **client**: Nostr app on any platform that wants to pay Lightning invoices.
-* **user**: The person using the **client**, and want's to connect their wallet app to their **client**.
+* **client**: Nostr app on any platform that wants to interact with a lightning wallet.
+* **user**: The person using the **client**, and wants to connect their wallet to their **client**.
 * **wallet service**: Nostr app that typically runs on an always-on computer (eg. in the cloud or on a Raspberry Pi).  This app has access to the APIs of the wallets it serves.
 
 ## Theory of Operation
- 1. **Users** who wish to use this NIP to send lightning payments to other nostr users must first acquire a special "connection" URI from their NIP-47 compliant wallet application.  The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means. 
+ 1. **Users** who wish to use this NIP to allow **client(s)** to interact with their wallet must first acquire a special "connection" URI from their NIP-47 compliant wallet application.  The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means. 
 
- 2. The **user** should then copy this URI into their **client(s)** by pasting, or scanning the QR, etc.  The **client(s)** should save this URI and use it later whenever the **user** makes a payment.  The **client** should then request an `info` (13194) event from the relay(s) specified in the URI.  The **wallet service** will have sent that event to those relays earlier, and the relays will hold it as a replaceable event.  
+ 2. The **user** should then copy this URI into their **client(s)** by pasting, or scanning the QR, etc.  The **client(s)** should save this URI and use it later whenever the **user** (or the **client** on the user's behalf) wants to interact with the wallet.  The **client** should then request an `info` (13194) event from the relay(s) specified in the URI.  The **wallet service** will have sent that event to those relays earlier, and the relays will hold it as a replaceable event.  
 
  3. When the **user** initiates a payment their nostr **client** create a `pay_invoice` request, encrypts it using a token from the URI, and sends it (kind 23194) to the relay(s) specified in the connection URI.  The **wallet service** will be listening on those relays and will decrypt the request and then contact the **user's** wallet application to send the payment.  The **wallet service** will know how to talk to the wallet application because the connection URI specified relay(s) that have access to the wallet app API.  
 
- 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.  
+ 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 23196) of wallet events (such as a received payment) to the **client**.
 
 ## Events
 
-There are three event kinds:
+There are four event kinds:
 - `NIP-47 info event`: 13194
 - `NIP-47 request`: 23194
 - `NIP-47 response`: 23195
+- `NIP-47 notification event`: 23196
+
+### Info Event
+
+The info event should be a replaceable event that is published by the **wallet service** on the relay to indicate which capabilities it supports.
+
+The content should be a plaintext string with the supported capabilities space-separated, eg. `pay_invoice get_balance notifications`.
 
-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-separated, eg. `pay_invoice get_balance`. Only the `pay_invoice` command is described in this NIP, but other commands might be defined in different NIPs.
+If the **wallet service** supports notifications, the info event SHOULD contain a `notifications` tag with the supported notification types space-separated, eg. `payment_received payment_sent`.
+
+### Request and Response Events
 
 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 **user** if this is a response. The response event SHOULD contain an `e` tag with the id of the request event it is responding to.
 Optionally, a request can have an `expiration` tag that has a unix timestamp in seconds. If the request is received after this timestamp, it should be ignored.
@@ -68,6 +78,22 @@ The `result_type` field MUST contain the name of the method that this event is r
 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 successful.
 If the command was successful, the `error` field must be null.
 
+### Notification Events
+
+The notification event SHOULD contain one `p` tag, the public key of the **user**.
+
+The content of notifications 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:
+
+```jsonc
+{
+    "notification_type": "payment_received", //indicates the structure of the notification field
+    "notification": {
+        "payment_hash": "0123456789abcdef..." // notification-related data
+    }
+}
+```
+
+
 ### 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.
@@ -120,7 +146,8 @@ Response:
 {
     "result_type": "pay_invoice",
     "result": {
-        "preimage": "0123456789abcdef..." // preimage of the payment
+        "preimage": "0123456789abcdef...", // preimage of the payment
+        "fees_paid": 123, // value in msats, optional
     }
 }
 ```
@@ -155,7 +182,8 @@ payment hash of the invoice should be used.
 {
     "result_type": "multi_pay_invoice",
     "result": {
-        "preimage": "0123456789abcdef..." // preimage of the payment
+        "preimage": "0123456789abcdef...", // preimage of the payment
+        "fees_paid": 123, // value in msats, optional
     }
 }
 ```
@@ -189,6 +217,7 @@ Response:
     "result_type": "pay_keysend",
     "result": {
         "preimage": "0123456789abcdef...", // preimage of the payment
+        "fees_paid": 123, // value in msats, optional
     }
 }
 ```
@@ -225,7 +254,8 @@ pubkey should be used.
 {
     "result_type": "multi_pay_keysend",
     "result": {
-        "preimage": "0123456789abcdef..." // preimage of the payment
+        "preimage": "0123456789abcdef...", // preimage of the payment
+        "fees_paid": 123, // value in msats, optional
     }
 }
 ```
@@ -394,6 +424,59 @@ Response:
             "block_height": 1,
             "block_hash": "hex string",
             "methods": ["pay_invoice", "get_balance", "make_invoice", "lookup_invoice", "list_transactions", "get_info"], // list of supported methods for this connection
+            "notifications": ["payment_received", "payment_sent"], // list of supported notifications for this connection, optional.
+    }
+}
+```
+
+## Notifications
+
+### `payment_received`
+
+Description: A payment was successfully received by the wallet.
+
+Notification:
+```jsonc
+{
+    "notification_type": "payment_received",
+    "notification": {
+        "type": "incoming",
+        "invoice": "string", // encoded invoice
+        "description": "string", // invoice's description, optional
+        "description_hash": "string", // invoice's description hash, optional
+        "preimage": "string", // payment's preimage
+        "payment_hash": "string", // Payment hash for the payment
+        "amount": 123, // value in msats
+        "fees_paid": 123, // value in msats
+        "created_at": unixtimestamp, // invoice/payment creation time
+        "expires_at": unixtimestamp, // invoice expiration time, optional if not applicable
+        "settled_at": unixtimestamp, // invoice/payment settlement time
+        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc.
+    }
+}
+```
+
+### `payment_sent`
+
+Description: A payment was successfully sent by the wallet.
+
+Notification:
+```jsonc
+{
+    "notification_type": "payment_sent",
+    "notification": {
+        "type": "outgoing",
+        "invoice": "string", // encoded invoice
+        "description": "string", // invoice's description, optional
+        "description_hash": "string", // invoice's description hash, optional
+        "preimage": "string", // payment's preimage
+        "payment_hash": "string", // Payment hash for the payment
+        "amount": 123, // value in msats
+        "fees_paid": 123, // value in msats
+        "created_at": unixtimestamp, // invoice/payment creation time
+        "expires_at": unixtimestamp, // invoice expiration time, optional if not applicable
+        "settled_at": unixtimestamp, // invoice/payment settlement time
+        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc.
     }
 }
 ```
@@ -407,3 +490,24 @@ Response:
 
 ## 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.
+
+## Appendix
+
+### Example NIP-47 info event
+
+```jsonc
+{
+  "id": "df467db0a9f9ec77ffe6f561811714ccaa2e26051c20f58f33c3d66d6c2b4d1c",
+  "pubkey": "c04ccd5c82fc1ea3499b9c6a5c0a7ab627fbe00a0116110d4c750faeaecba1e2",
+  "created_at": 1713883677,
+  "kind": 13194,
+  "tags": [
+    [
+      "notifications",
+      "payment_received payment_sent"
+    ]
+  ],
+  "content": "pay_invoice pay_keysend get_balance get_info make_invoice lookup_invoice list_transactions multi_pay_invoice multi_pay_keysend sign_message notifications",
+  "sig": "31f57b369459b5306a5353aa9e03be7fbde169bc881c3233625605dd12f53548179def16b9fe1137e6465d7e4d5bb27ce81fd6e75908c46b06269f4233c845d8"
+}
+```