words

69.md

@@ -52,7 +52,7 @@ Example user metadata content with `nip69` field:
   "pubkey": "hex_pub",
   "kind": 0,
   "content": "{\"name\": \"bob\", \"nip05\": \"bob@example.com\", \"nip69\": \"noffer1...\"}"
-  ...
+  // ...
 }
 ```
 
@@ -100,7 +100,7 @@ Example NIP-57 zap request:
 }
 ```
 
-There is no requirement on the service to acknowledge the zap request content, given that spontaneous payments are default behavior. Service implementations and clients should however consider offer identifiers, where `startsWith("zap")`, to indicate that the service will honor zap requests. A service should not error if no zap request is attached to a zap named offer, rather just treat it any other spontaneous payment.
+There is no inherent requirement on the service to acknowledge zap requests, since spontaneous payments are default behavior. However, both Clients and Service implementations SHOULD consider offer identifiers, where `startsWith("zap")`, indication that the service will honor zap requests for that offer. A service should not error if no zap request was included by the sender on a zap indicated offer, the service should treat it as any other spontaneous payment.
 
 ## General Process Flow
 
@@ -197,9 +197,9 @@ Clients implementing this NIP may:
 1. Support both this protocol and LNURL for backward compatibility during the transition period.
 2. Implement additional features such as multi-recipient payments or integration with other Lightning-related NIPs.
    - Ex: If an offer lists multiple recipient keys, a client might "for each" over them to pay multiple recipients.
-3. Use Addressable Events: Nest offers in addressable event for marketplace products where the offer may change more frequently than the product due to price, receiving key, or relay URL associated with the offer.
-4. **Attempt Payments by Name**: Use the combination of NIP-05 and NIP-69 to attempt payments by name-based lookups.
-5. Prefix and Parse `noffer` strings with existing `lightning:` link handlers, just as they would invoices or legacy LNURL strings.
+3. Use Addressable Events to nest offers in marketplace products etc where the offer variables might change more frequently than the product or service associated with it.
+4. **Attempt Payments by Name**: Wallets might first attempt the combination of NIP-05 and NIP-69 before falling back to LNURL on name-based lookups.
+5. Prefix and parse `noffer` strings with existing `lightning:` link handlers, just as they would invoices or legacy LNURL strings.
 
 ### Prohibited
 
@@ -215,7 +215,7 @@ Clients implementing this NIP MUST NOT:
 Services implementing this NIP may:
 
 1. Use an account identifier as a default offer string for spontaneous payments without explicit user setup.
-2. **NIP-05 Integration**: Add a `nip69` field in the NIP-05 content to provide the offer on name-based lookups for trust-optimized Lightning Addresses.
+2. **NIP-05 Integration**: Add a `nip69` field in the NIP-05 content to provide the offer on name-based lookups for trust-minimized Lightning Addresses.
 
 ## Error Handling
 
@@ -252,7 +252,7 @@ Clients MUST handle these error responses gracefully and display appropriate mes
 
 ## Transition from LNURL
 
-LNURL services wishing to migrate to Nostr Offer STRings should consider adding a `noffer` tag to their responses.
+LNURL services wishing to signal the upgrade should add `nip69: <noffer>` to the inital GET response described in [LUD-06](https://github.com/lnurl/luds/blob/luds/06.md). Clients seeing this new value on a LNURL server should automatically upgrade the payment flow that was instantiated by the user for that address.
 
 ## Future Considerations