From 993b3a841c4a708b6a31e7b239c5f1d799691ee4 Mon Sep 17 00:00:00 2001
From: shocknet-justin <34176400+shocknet-justin@users.noreply.github.com>
Date: Tue, 3 Sep 2024 12:51:33 -0400
Subject: [PATCH] better other nips descriptions

---
 69.md | 42 ++++++++++++++++++++++++++++++++++++------
 1 file changed, 36 insertions(+), 6 deletions(-)

diff --git a/69.md b/69.md
index 7f6a940d..43bd6960 100644
--- a/69.md
+++ b/69.md
@@ -27,7 +27,7 @@ The static payment code is a bech32 (per [NIP-19](19.md)) encoded string prefixe
   - `0`: Fixed price
   - `1`: Variable price
   - `2`: Spontaneous payment (payer specifies the amount)
-- `4`: The price in sats (optional).
+- `4`: The price in sats (optional for display purposes).
 
 If neither the price nor the pricing type flag is present, the sender may assume it is a spontaneous payment offer.
 
@@ -42,11 +42,11 @@ noffer1...
   4: <price_in_sats> (optional)
 ```
 
-### NIP-05 Integration
+## Integration with other NIPs
 
-To support trust-optimized Lightning Addresses, services can add a `nip69` field in the NIP-05 content to contain an offer for spontaneous payments. This field will provide the offer on name-based lookups.
+### NIP-01 User Metadata
 
-Example NIP-05 content with `nip69` field:
+Example user metadata content with `nip69` field:
 ```json
 {
   "pubkey": "hex_pub",
@@ -56,6 +56,10 @@ Example NIP-05 content with `nip69` field:
 }
 ```
 
+### NIP-05 "Lightning Addresses"
+
+To support trust-minimized Lightning Addresses, services can add a `nip69` field in the NIP-05 content to contain an offer for spontaneous payments. This field will provide the offer on name-based lookups.
+
 Example NIP-05 Service Response with Offers
 
 
@@ -70,7 +74,33 @@ Example NIP-05 Service Response with Offers
 }
 ```
 
-### Process Flow
+### NIP-57 Zaps
+
+Instead of using the LNURL-pay callback, the "zap" flow can be initiated as content payload to an Offer:
+
+1. The client creates a kind 9734 zap request event as specified in NIP-57.
+2. Instead of sending this to an LNURL-pay endpoint, the client sends it as the `zap` part of the encrypted content in a NIP-69 payment request.
+3. The receiver processes the NIP-69 payment request, decrypts the content, extracts the kind 9734 event, and uses it to generate the invoice.
+4. The receiver responds with the invoice as specified in NIP-69.
+5. Once paid, the receiver generates and publishes the kind 9735 zap receipt as specified in NIP-57.
+
+Example NIP-57 zap request:
+
+```json
+{
+  "id": "<event_id>",
+  "pubkey": "<sender_pubkey>",
+  "created_at": 1234567890,
+  "kind": 21001,
+  "tags": [
+    ["p", "<receiver_pubkey>"]
+  ],
+  "content": "<NIP-44 encrypted {\"offer\":\"<offer_string>\",\"zap\":<kind 9734 zap request event>}>",
+  "sig": "<signature>"
+}
+```
+
+## General Process Flow
 
 1. **Payer Scans or Clicks the Static Payment Code**
 2. **Payer's Wallet Decodes the Payment Code**
@@ -231,4 +261,4 @@ Future versions of this NIP may consider additional features such as:
 
 ## Reference Implementation
 
-Lightning.Pub / ShockWallet offers branches
\ No newline at end of file
+Lightning.Pub / ShockWallet noffer branches
\ No newline at end of file