mirror of
https://code.gri.mw/GUI/grim.git
synced 2026-07-13 10:18:54 +00:00
2ro
a7c2443f3b
Implements the Goblin-wallet half of the proof-on-request architecture (magick payment infra spec section 4/5): the buyer's wallet threads a native Grin payment proof per transaction, off by default and on only when the scanned pay URI asks for it, and auto-delivers the proof to the market and watcher on finalize. Person-to-person sends are unchanged. W1 pay-URI parser (payuri.rs): PayUri gains proof/order/notify, each fail-closed (a bad value drops to None and never blocks the payment). proof is a grin1/tgrin1 slatepack-address shape check, order is an opaque control-stripped routing key capped at 64 bytes, notify is an npub shape check. Unknown-param forward-compat and the magick interop tests still hold. 12 new parser tests. W2 proof threading: WalletTask::NostrSend carries proof/order/notify; the handler re-parses proof authoritatively into a SlatepackAddress and calls w.send(a, Some(addr)) instead of the hard-coded None, setting payment_proof_recipient_address. The order handle, watcher npub, and amount persist in TxNostrMeta (new serde-default fields) before dispatch, so a crash between send and finalize loses nothing. W3 review indicator: the send-review screen shows a small "proof included" row when proof mode is active. New t!() keys row_proof / row_proof_val in all six locales (drift test green). W4 proof delivery on finalize: when a finalized SEND was sent in proof mode, the wallet publishes the two contract events: a plain unencrypted kind-17 "payment sent" receipt to the app relays (payment-request tag = order handle; proof and kernel deliberately omitted to avoid leaking the buyer's sender address; flips the page to "detected", never "paid"), and a NIP-59 gift-wrapped kind-17 rumor to the notify npub carrying the full proof JSON plus a kernel-excess tag. Both are enrolled in the existing crash-safe reconcile pass and retried until a relay accepts them. wrapv3 gains wrap_kind() to gift-wrap an arbitrary rumor kind. Matching is by the payment-request (invoice number) tag alone; the wallet never learns magick's internal orderId. No merchant-side auto-receipt is built: the rewritten spec has the buyer publish on finalize instead.