1 files changed, 3 insertions, 97 deletions

diff --git a/47.md b/47.md
index 76c8f50..6830820 100644
--- a/47.md
+++ b/47.md
@@ -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://...`)
-
-