From d1f78e891d8d022041f6d289c9cbd86754822b28 Mon Sep 17 00:00:00 2001 From: shocknet-justin <34176400+shocknet-justin@users.noreply.github.com> Date: Tue, 3 Sep 2024 16:34:05 -0400 Subject: [PATCH] words --- 69.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/69.md b/69.md index cfe5554b..3491930e 100644 --- a/69.md +++ b/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: ` 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