Finishes the remaining #3 zap audit items.
- zapSplit: when the platform fee would pay the SAME Lightning address as the
creator (e.g. the creator is the platform operator), collapse to a single
full-amount payment instead of sending two invoices to one wallet — avoids an
extra routing fee and a confusing duplicate receipt for the same total.
- Audited split correctness: floor(amount*fee/100) with the creator taking the
remainder loses no sats; a sub-1-sat fee rounds to 0 and the whole zap goes to
the creator (no zero-amount platform send); fee is clamped 0–100 and a junk
override falls back to the default. The earlier "fee landed in my own wallet"
report is expected behavior (sender is the platform operator, or a self-zap),
not a bug.
- Cheat-resistant tests: testCreatorEqualsPlatformCollapsesToOnePayment and
testSplitRoundingPreservesEverySat in tests/zap-split.test.mjs.
- Receipt validation (9735) and NWC budget/retry UX confirmed already solid;
audit plan + TODO #3 closed.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
A static client can't fetch LNURL hosts that omit CORS headers, so zaps to
those creators fail. Add a browser-side reachability probe
(checkLightningAddressZappable) and surface it on both sides: the creator
is warned at wallet-connect time if their own address isn't browser-
zappable, and the zapper sees a heads-up when opening a non-reachable
creator's zap dialog.
Also fix encrypted settings restore: the "already offered" flag was
per-pubkey, so once storage was offered the wallet note was never offered
later. Track it per-item so the wallet is offered independently.
Zappability check extracted to walletZappabilityCheck.js for the size cap.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
- NWC connection was fully broken: parseNwcUri passed a hex secret to
nostr-tools getPublicKey (needs Uint8Array) and threw. Convert hex->bytes.
- A successful zap was shown as a red error when the kind-9735 receipt
couldn't be validated. The NWC preimage already proves payment, so a
paid-but-unconfirmed share is now a success-with-note, not a failure.
- Receipt discovery: query by the reliably-indexed #e/#a/#p tags instead of
#bolt11 (which most relays don't index), and poll a few times since the
receipt is published shortly after payment.
- In-flight "Sending..." status no longer mis-toned as a warning; success
path fully resets the form; an in-flight-open click no longer cancels the
open (which made the popover need many clicks); fee fallback verified
no-bypass.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Sending a zap to a creator whose LNURL endpoint is down or doesn't send
CORS headers (e.g. unitypay.cash/.well-known/lnurlp/<name>) made the browser
fetch reject with a raw "Failed to fetch", which bubbled up as the zap's
error toast — the "clunky errors" reported during the zap audit.
fetchPayServiceData now catches the network/CORS rejection and throws a
clear, coded error ("Couldn't reach this recipient's Lightning address. It
may be offline or blocking browser requests."), preserving the original as
`cause`. Non-OK HTTP and valid responses are unchanged.
Part of the zap audit (TODO #3). Also recorded: the video-modal popover
mis-positioning (3a) and that the deeper CORS issue (static client can't
fetch CORS-less LNURL hosts) may need a proxy — tracked separately.
Tests + mutation-verified. 1274 pass (known UploadModal flake).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
After a successful split zap, validation errored: "Unable to initialize a relay
pool for receipt validation." The validator built a fresh `new SimplePool()` and
required `pool.list()`, but nostr-tools 2.x removed SimplePool.list() (the rest of
the app only has it because js/nostr/toolkit.js shims it). So validation always
failed even though the payment went through.
Fix: resolveReceiptListPool() applies the app's legacy .list shim
(shimLegacySimplePoolMethods) to the freshly created pool, and the gate now
accepts a listEvents override instead of hard-requiring pool.list.
tests/zap-receipt-pool.test.mjs: 2.x pool gets .list shimmed; createPool override
shimmed; listEvents override leaves the pool as-is; null when neither available.
Mutation-verified (removing the shim fails it).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
- Introduce `js/constants.js` with semantic time constants (e.g., `ONE_MINUTE_MS`, `STANDARD_TIMEOUT_MS`) and feature-specific TTLs.
- Export `KIND_MUTE_LIST` from `js/nostrEventSchemas.js` to standardize NIP-51 mute list kind usage.
- Refactor `js/state/cache.js`, `js/nostr/cachePolicies.js`, `js/channelProfile.js`, and various services to use centralized constants instead of hardcoded magic numbers.
- Update `js/nostr/relayConstants.js` to derive values from the shared time constants.
- Replace duplicate definitions of timeouts and retry delays across the codebase.
Co-authored-by: PR0M3TH3AN <[email protected]>
Moves the repeatedly defined HEX64_REGEX constant to a shared utility
module to improve maintainability and consistency. Updates all consumers
to import from the new location.
Signed-off-by: Jules <[email protected]>
Co-authored-by: PR0M3TH3AN <[email protected]>
This patch updates `js/payments/zapSplit.js` and `js/payments/nwcClient.js` to replace legacy manual event signing (which relied on `nostr-tools` v1 methods `getEventHash` and `signEvent` that are missing in v2) with the centralized `signEventWithPrivateKey` helper from `js/nostr/publishHelpers.js`. This ensures compatibility with the installed `nostr-tools` version and resolves the error preventing zaps.