laantungir/amethyst
1
0
Fork 0
mirror of https://github.com/vitorpamplona/amethyst.git synced 2026-08-08 23:54:39 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(bolt12): record nwc#2 resolution — Phase 2 unblocked

Browse Source 
Maintainer confirmed payer_note maps to invreq_payer_note for BOLT12 and
payer_proof is returned for successful BOLT12 payments. Notes the
validate-before-publish fail-safe so a non-conforming wallet never yields an
invalid receipt.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SpgpWLKzgD7vS9Fs4CXTR3
This commit is contained in:
Claude
2026-07-24 22:29:30 +00:00
parent d58bca4177
commit c7415f1559
1 changed files with 19 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
amethyst/plans/2026-07-24-nwc-bolt12-pay.md
+19 -4
View File
@@ -116,9 +116,24 @@ but is **not** wired into the pay path — we'd add the gate ourselves.
4. **Maturity.** Both nwc#2 and NIP-2421 are unmerged; few/no wallets implement
`pay` today. Gate hard on capability (Phase 3) and keep the intent fallback.
## Resolution of risks #1/#2 (nwc#2 maintainer, 2026-07-24)
Asked on the nwc#2 thread. Maintainer confirmed:
- **`payer_note` → `invreq_payer_note`**: "that is the intention" for BOLT12 (the
field doubles as a general memo). So our zap binding
(`invreq_payer_note == nostr:nipXX:<intent-id>`) is the intended target.
- **`payer_proof`**: "should be returned for successful bolt12 payments"; the
"optional if unavailable" wording only covers non-BOLT12 instruction types.
Both are informal maintainer intent, not yet spec text, so a non-conforming wallet
is still possible. That's fine: after a `pay` returns, we run the returned
`payer_proof` through `Bolt12ZapValidator` **before** publishing a kind:9736. A
wallet that misroutes the note fails the binding check and we publish nothing —
Phase 2 fails safe, never emitting an invalid receipt.
## Recommendation
Phase 0 is safe, self-contained, and unblocks everything — do it regardless.
Phase 1 (in-app pay) is low-risk and immediately useful. **Hold Phase 2 until
risk #1 is resolved** — it's the high-value piece (real zap sending) but its
correctness depends on a binding the current nwc#2 text doesn't guarantee.
Phase 0 (done) and Phase 1 (done) shipped. **Phase 2 is now unblocked.** Build it
with the validate-before-publish gate above; degrade to "paid, no zap receipt"
when the proof is absent or fails validation.