remove description_hash requirement to match LUD06 update

57.md

@@ -17,7 +17,7 @@ Having lightning receipts on nostr allows clients to display lightning payments
 3. When a user (the "sender") indicates they want to send a zap to another user (the "recipient"), the client should create a `zap request` event as described in Appendix A of this NIP and sign it.
 4. Instead of publishing the `zap request`, the `9734` event should instead be sent to the `callback` url received from the lnurl pay endpoint for the recipient using a GET request. See Appendix B for details and an example.
 5. The recipient's lnurl server will receive this `zap request` and validate it. See Appendix C for details on how to properly configure an lnurl server to support zaps, and Appendix D for details on how to validate the `nostr` query parameter.
-6. If the `zap request` is valid, the server should fetch a description hash invoice where the description is this `zap request` note and this note only. No additional lnurl metadata is included in the description. This will be returned in the response according to [LUD06](https://github.com/lnurl/luds/blob/luds/06.md).
+6. If the `zap request` is valid, the server should fetch an invoice which will be returned in the response according to [LUD06](https://github.com/lnurl/luds/blob/luds/06.md).
 7. On receiving the invoice, the client MAY pay it or pass it to an app that can pay the invoice.
 8. Once the invoice is paid, the recipient's lnurl server MUST generate a `zap receipt` as described in Appendix E, and publish it to the `relays` specified in the `zap request`.
 9. Clients MAY fetch `zap receipt`s on posts and profiles, but MUST authorize their validity as described in Appendix F. If the `zap request` note contains a non-empty `content`, it may display a zap comment. Generally clients should show users the `zap request` note, and use the `zap receipt` to show "zap authorized by ..." but this is optional.
@@ -116,22 +116,20 @@ The event MUST then be stored for use later, when the invoice is paid.
 
 ### Appendix E: Zap Receipt Event
 
-A `zap receipt` is created by a lightning node when an invoice generated by a `zap request` is paid. `Zap receipt`s are only created when the invoice description (committed to the description hash) contains a `zap request` note.
+A `zap receipt` is created by a lightning node when an invoice generated by a `zap request` is paid.
 
 When receiving a payment, the following steps are executed:
 
-1. Get the description for the invoice. This needs to be saved somewhere during the generation of the description hash invoice. It is saved automatically for you with CLN, which is the reference implementation used here.
+1. Parse the bolt11 description as a JSON nostr event. This SHOULD be validated based on the requirements in Appendix D, either when it is received, or before the invoice is paid.
-2. Parse the bolt11 description as a JSON nostr event. This SHOULD be validated based on the requirements in Appendix D, either when it is received, or before the invoice is paid.
+2. Create a nostr event of kind `9735` as described below, and publish it to the `relays` declared in the `zap request`.
-3. Create a nostr event of kind `9735` as described below, and publish it to the `relays` declared in the `zap request`.
 
 The following should be true of the `zap receipt` event:
 
 - The content SHOULD be empty.
 - The `created_at` date SHOULD be set to the invoice `paid_at` date for idempotency.
 - `tags` MUST include the `p` tag AND optional `e` tag from the `zap request`.
-- The `zap receipt` MUST have a `bolt11` tag containing the description hash bolt11 invoice.
+- The `zap receipt` MUST have a `bolt11` tag containing the bolt11 invoice.
-- The `zap receipt` MUST contain a `description` tag which is the JSON-encoded invoice description.
+- The `zap receipt` MUST contain a `description` tag which is the JSON-encoded `zap request`.
-- `SHA256(description)` MUST match the description hash in the bolt11 invoice.
 - The `zap receipt` MAY contain a `preimage` tag to match against the payment hash of the bolt11 invoice. This isn't really a payment proof, there is no real way to prove that the invoice is real or has been paid. You are trusting the author of the `zap receipt` for the legitimacy of the payment.
 
 The `zap receipt` is not a proof of payment, all it proves is that some nostr user fetched an invoice. The existence of the `zap receipt` implies the invoice as paid, but it could be a lie given a rogue implementation.