feat: Lightning Wallet (NWC) — link, send, receive, pay cards, receive-only agents#2635
Closed
marcopesani wants to merge 3 commits into
Closed
feat: Lightning Wallet (NWC) — link, send, receive, pay cards, receive-only agents#2635marcopesani wants to merge 3 commits into
marcopesani wants to merge 3 commits into
Conversation
Design for per-user (and receive-only per-agent) Lightning wallets via NIP-47 Nostr Wallet Connect, with a two-plane architecture (off-Buzz NWC transport + on-Buzz discovery/UX) and a ports/adapters domain so custodial or LDK backends slot in as a single WalletService adapter later. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Fold the architectural dry-run findings back into the design: name the four driver-facing ports the acceptance harness forces (WalletConnector, PaymentStore, SecretStore, ProfilePublisher), make send two-phase, add the lightning-invoice dependency, require bolt11 on confirmable requests, enforce receive-only at agent provisioning, fix the lud16 source and lookup_invoice mapping, and re-map the acceptance harness accordingly. Co-authored-by: Cursor <cursoragent@cursor.com>
Author
|
Closing — development continues on the fork until ready. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lightning Wallet (NWC)
Implements docs/lightning-wallet-nwc.md: every user (and, receive-only, every agent) can link an external Lightning wallet over NIP-47 Nostr Wallet Connect. Buzz never holds funds — money moves client-side between the user's wallet service and the wallet's relay.
Scope: Rust domain +
buzz-walletcrate, NWC/LNURL adapters, a local mock NWC wallet for e2e, event kinds 40009/40010 + relay ingest +users.lud16, Tauri backend, desktop UI,buzz walletCLI, receive-only agent provisioning. Mobile (Flutter) is deferred to a follow-up PR; this PR ships the shared conformance vectors (testdata/wallet/) it will consume.Each unit below lands as its own commit only after an independent verificator run (tests re-run, acceptance scenarios mapped to named tests, fmt/clippy clean). Proof bundles (logs, scenario→test tables, screenshots) are posted as PR comments and linked here as they land.
Unit checklist
buzz-corepayment domain (Amount, verify, validation, kinds 40009/40010, shared vectors)buzz-walletports +WalletError+ scriptable fakes + in-memoryPaymentStore(claim_paying)link+receive_modeuse-casesprepare_send/confirm/cancel), bolt11 decode + validationreconcile+check_incomingNwcWalletService(nwc 0.44) +HttpLnurlResolver+ capturing-HTTP adapter testsbuzz-mock-wallet— local NWC wallet (loopback relay + daemon, real bolt11/preimages)build_profilelud16, ingest allowlists, migrationusers.lud16nwc:{community_id}secret, durablePaymentStore, community reset, reconcile hooke-join + Playwright screenshotsbuzz walletCLI +BUZZ_NWC_URI/ 0600 secret + TESTING.md runbookjust ci+just testgreen, doc de-drafted, PR readyAcceptance criteria coverage
The Gherkin features in the doc are the contract; the coverage table (scenario → named test) is filled in per unit as proofs land: Link, Receive, Send to a lightning address, Payment lifecycle, Payment requests in chat, Trust is local, Agents are receive-only, Relay ingest of payment kinds, Preimage vectors.
Hard rules enforced throughout
pay_invoicefires at most once per attempt.h-scoped.