nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-14 07:49:07 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

better other nips descriptions

Browse Source
This commit is contained in:
shocknet-justin 2024-09-03 12:51:33 -04:00
parent 4693f53e92
commit 993b3a841c
1 changed files with 36 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
69.md
View File

@ -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
Lightning.Pub / ShockWallet noffer branches