Rebase and add notification details

47.md

@@ -25,7 +25,7 @@ This NIP describes a way for clients to access a remote lightning wallet through
  
  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**.
+ 5. The **wallet service** may send encrypted notifications (kind 23197 or 23196) of wallet events (such as a received payment) to the **client**.
 
 ## Events
 
@@ -33,7 +33,7 @@ There are four event kinds:
 - `NIP-47 info event`: 13194
 - `NIP-47 request`: 23194
 - `NIP-47 response`: 23195
-- `NIP-47 notification event`: 23196
+- `NIP-47 notification event`: 23197 (23196 in v0)
 
 ### Info Event
 
@@ -115,9 +115,9 @@ 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 notification event is a kind 23197 event (23196 in v0) 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:
+The content of notifications is encrypted with [NIP44](https://github.com/nostr-protocol/nips/blob/master/44.md) (or NIP-04 in v0), and is a JSON-RPCish object with a semi-fixed structure:
 
 ```jsonc
 {
@@ -128,6 +128,7 @@ The content of notifications is encrypted with [NIP04](https://github.com/nostr-
 }
 ```
 
+_Note on backwards-compatibility:_ If a **wallet service** supports both v0 (or no version tag) and v1+ of the protocol, it should publish both notification events for each notification - kind 23196 encrypted with NIP-04 for v0, and kind 23197 encrypted with NIP-44 for v1. It is up to the **client** to decide which event to listen to based on its supported version and declared supported versions 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.
@@ -530,7 +531,7 @@ Versioning for NIP-47 allows the protocol to evolve and even make breaking chang
 Major version bumps imply breaking changes that are incompatible with the previous major version. Minor version bumps, however, only include non-breaking feature additions or improvements which
 can maintain full compatibility with the previous minor version.
 
-**Note:** Version 0.0 or absence of a version specification implies the version of NIP-47 prior to adding the versioning system. This is the protocol as defined at commit hash `e655247`.
+**Note:** Version 0.0 or absence of a version specification implies the version of NIP-47 prior to adding the versioning system. This is the protocol as defined at commit hash `32b9f3f`.
 
 Versioning works as follows.
 
@@ -581,13 +582,20 @@ the request event might look like:
 
 If the **wallet service** does not support the specified version, it will return an `UNSUPPORTED_VERSION` error. Absence of the `v` tag indicates use of version 0.
 
+### Notification events
+
+As described above in the [Notifications](#notifications) section, if a **wallet service** supports both v0 and v1+ of the protocol, it should publish two notification events for each notification - kind 23196 encrypted with NIP-04 for v0, and kind 23197 encrypted with NIP-44 for v1. If the **wallet service** only supports v1+, it should only publish kind 23197 events.
+
+The **client** should check the `v` tag in the `info` event to determine which version of the protocol the **wallet service** supports, and listen to the appropriate notification event. Clients that support both v0 and v1+ can choose to only listen to 23197 events for simplicity.
+
 ### Changelog
 
 - **0.0**:
-  - Initial version using the protocol as defined at commit hash `e655247`. Uses NIP-04 for encryption.
+  - Initial version using the protocol as defined at commit hash `32b9f3f`. Uses NIP-04 for encryption and kind 23196 for notifications.
 - **1.0**
   - Adds versioning system.
   - Uses NIP-44 for encryption.
+  - Moves to kind-23197 notification events, encrypted with NIP-44.
 
 ## 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.
@@ -603,6 +611,7 @@ This NIP does not specify any requirements on the type of relays used. However,
   "created_at": 1713883677,
   "kind": 13194,
   "tags": [
+    [ "v", "1.3 0.0"],
     [
       "notifications",
       "payment_received payment_sent"

README.md

@@ -180,6 +180,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `22242`       | Client Authentication           | [42](42.md)                            |
 | `23194`       | Wallet Request                  | [47](47.md)                            |
 | `23195`       | Wallet Response                 | [47](47.md)                            |
+| `23196`       | NWC Notification (v0)           | [47](47.md)                            |
+| `23197`       | NWC Notification (v1+)          | [47](47.md)                            |
 | `24133`       | Nostr Connect                   | [46](46.md)                            |
 | `24242`       | Blobs stored on mediaservers    | [Blossom][blossom]                     |
 | `27235`       | HTTP Auth                       | [98](98.md)                            |