aboutsummaryrefslogtreecommitdiffstats
path: root/src/app.js
Commit message (Collapse)AuthorAgeFilesLines
* Drop npub-locked gifts; collapse Nostr login behind a buttonAdam Soltys2026-08-011-5/+0
| | | | | | | | | | | | | | Gifts are plain bearer links again: the recipient-npub field, the one-time claim code, the DM delivery, the /lg/ claim route and the NIP-07 in-place decrypt are all gone, along with the crypto that only they used. Unclaimed gifts remain reclaimable by the sender, so nothing can be stranded by the removal. The unlock screen shows a single 'Sign in with Nostr' button that reveals the login options when tapped, instead of the full card competing with create/import. Co-Authored-By: Claude Fable 5 <[email protected]>
* Log in with Nostr, and link a wallet to a Nostr accountAdam Soltys2026-08-011-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Three ways in: a NIP-07 browser extension, a NIP-46 remote signer (Amber, Amethyst — paste its bunker:// address), or a pasted nsec/hex key that lives in memory for the session and is never stored. How an account gets a wallet depends on what we can see, and the two cases are genuinely different: * We hold the key (pasted nsec): the seed is DERIVED from it — sha256("coinos:wallet-seed:v1" | privkey) as BIP-39 entropy. The same Nostr key always opens the same wallet, on any device, with nothing stored anywhere. * We only have a signer: deriving is impossible (we never see the key, and neither signatures nor NIP-44 ciphertexts reproduce), so the seed is ASSOCIATED instead — generated once and published as a replaceable event encrypted to the user's own key, which only their signer can decrypt. Later logins find and decrypt it. The second path means the Nostr key can recover the money; the UI says so before publishing anything. Linking an already-open wallet uses the same publish path and refuses to overwrite an account's existing wallet. Co-Authored-By: Claude Fable 5 <[email protected]>
* Username onboarding + the payment address leads ReceiveAdam Soltys2026-08-011-3/+12
| | | | | | | | | | | | | | | New wallets must pick a username before entering the wallet: the onboarding gate renders a claim screen until a name exists. Imported seeds skip it — the registrar's new /pubkey lookup recovers the name owned by the wallet's key, so nothing is retyped. If claiming errors (registrar or ark unreachable) a do-it-later escape appears rather than locking anyone away from funds; the prompt returns next open. The Receive tab now defaults to the payment address — name QR + copy — with the on-chain address and other modes behind it, and the claim form inline for wallets that skipped onboarding. Co-Authored-By: Claude Fable 5 <[email protected]>
* Bigger header logoAdam Soltys2026-08-011-1/+1
| | | | Co-Authored-By: Claude Fable 5 <[email protected]>
* Fix the logo symbol: drop the background disc pathAdam Soltys2026-08-011-1/+1
| | | | | | | With the root filled currentColor, the disc covered the ring and half-moon; the drawn symbol needs only the outline paths. Co-Authored-By: Claude Fable 5 <[email protected]>
* Use the official coinos wordmark SVG in the headerAdam Soltys2026-08-011-2/+1
| | | | | | | The full logo from coinos.io (symbol + wordmark as drawn paths) at 28px, inheriting the ink color for both themes; replaces the mark + text pair. Co-Authored-By: Claude Fable 5 <[email protected]>
* The coinos mark in the headerAdam Soltys2026-08-011-1/+1
| | | | | | | Inline single-color SVG of the brand symbol (ring + half-moon) that inherits the ink color, next to the lowercase wordmark. Co-Authored-By: Claude Fable 5 <[email protected]>
* Simplify: one Lightning path, one balance, fewer featuresAdam Soltys2026-08-011-28/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Dropped: silent payments (feature, wallet chains, scan worker, indexer config), Boltz submarine/reverse swaps (feature + swap.js + tools), the third-party ark swap bridge (config, client flows, settings card — the ASP's own Lightning send is the one path now), and the Consolidate coins settings action. The NWC pouch is gone with them: background answering now spends the WHOLE ark balance. The IndexedDB record mirrors the real manager state plus the chain-3 keys for its live coins and a change-index window; the worker pays through the ASP exactly like the open app, and the app folds the worker's spends, change, and key allocations back in on connect (additive merge + reconcile against the server). A leftover chain-6 pouch from the short-lived pouch era is swept home automatically using the keys stored in its own record. The stated tradeoff: same-origin script access now reaches the ark balance, not a carve-out — the ark balance is walking-around money, the on-chain wallet's keys are never mirrored, and per-connection NWC budgets remain the enforced ceiling. Bundle: 726KB -> 602KB. Co-Authored-By: Claude Fable 5 <[email protected]>
* Re-render the send form when a destination annotation appearsAdam Soltys2026-07-311-2/+6
| | | | | | | | | The lightning-address zap button is computed at render time, but onInput only re-rendered when on-chain validity flipped — an lnaddr never does, so the button never appeared. Track sendFormNote presence like readiness and re-render on a flip. Verified with a headless-browser check. Co-Authored-By: Claude Fable 5 <[email protected]>
* Fix send-form UX around lightning pays; harden ln state machinesAdam Soltys2026-07-311-6/+14
| | | | | | | | | | | | | | | | | | | - a rejected cosign (gRPC INVALID_ARGUMENT) returns the input vtxo to spendable and fails the action instead of leaving it pending forever — the stuck-pending state that pushed small zaps onto Boltz's 25k minimum - ark ln-pay now takes over when funds are settling (retrying quote) rather than falling through to Boltz - typing a destination clears stale send errors (also cleared on tab switch); paste path likewise - typed lightning addresses no longer auto-advance mid-keystroke (the matcher fired at `[email protected]` before `.com`, yanking the form away): the send form offers an explicit "Zap <addr>" button; pasted/scanned addresses still advance immediately - ln-recv: HTLC vtxos anchored to a not-yet-confirmed pool round park and retry instead of throwing; the requested HTLC expiry is anchored on first prepare so retries can't inflate it past the server's grant Co-Authored-By: Claude Fable 5 <[email protected]>
* Coalesce background renders so user input takes priorityAdam Soltys2026-07-081-1/+19
| | | | | | | | | | | | | | | | | Every wallet.emit() re-rendered the whole screen synchronously. On refocus after the PWA was backgrounded, a burst of emits (WS reconnect, the wake scan's several emits, syncFromNostr merge, each live device snapshot) fired a dozen full-screen rebuilds back-to-back, starving input — navigation lagged ~2s until the burst drained. Route the subscription through scheduleRender(), which coalesces emits into at most one render per animation frame. Direct user actions still call render() synchronously and cancel any pending frame, so a tap or navigation always renders immediately and takes priority over background repaints. rAF also skips rendering while hidden and fires once on refocus. Co-Authored-By: Claude Opus 4.8 <[email protected]>
* History: Bitcoin logo for on-chain rows instead of up/down arrowsAdam Soltys2026-07-061-1/+6
| | | | | | | | | Plain on-chain sends/receives fell through to ↓/↑ arrows in the row circle; now they show the Bitcoin mark like the other rails (ark/sp/ gift). Direction stays legible via the green/red circle tint and the signed amount. Consistent icon column across every payment type. Co-Authored-By: Claude Fable 5 <[email protected]>
* History: Ark glyph in the row circle (no text chip); real Bitcoin logoAdam Soltys2026-07-061-1/+2
| | | | | | | | | | | Off-chain Ark rows (arkHistoryItem) showed an arrow + a redundant 'Ark' text chip; now the Ark mark sits in the direction-colored circle and the chip is gone — the label + signed amount carry direction. The detail header gets the badge instead of the chip. And the receive selector's Bitcoin option uses coinos's real bitcoin.svg (orange disc + tilted white B) instead of a bare ₿ character. Co-Authored-By: Claude Fable 5 <[email protected]>
* Icons in the receive selector and on silent-payment history rowsAdam Soltys2026-07-061-3/+36
| | | | | | | | | | | | | | The receive address-type picker was a native <select>, which can't render SVG in <option>s. Replace it with a lightweight custom dropdown (icon-select) that shows a glyph per rail — ₿ Bitcoin, ⚡ Lightning, the Second mark for Ark, 🕶️ Silent payment — closing on select or an outside tap. Receive modes gained an icon field; the address option is built in app.js. Silent-payment receipts (which merge into history as on-chain-looking rows) now get a rail glyph + SP tag via a decorateTxRow so they're distinguishable, matching how ark/gift rows already decorate. Co-Authored-By: Claude Fable 5 <[email protected]>
* Ark icon: Second's logo instead of the crossed-swords placeholderAdam Soltys2026-07-061-1/+2
| | | | | | | | | | | | | | The ⚔ was a U+2694 emoji stand-in. Swap in Second's actual mark (second.tech logo: a triangle with an evenodd inner cutout) as two format.js helpers — ARK_ICON (dark rounded-square app badge + white mark, for card/section headers) and ARK_MARK (bare currentColor glyph, for the history-row circle). Wired into the Ark settings card, the boarding/withdrawal/exit history rows + detail section, and the How-it-works Ark section; the gift source toggle drops the emoji for plain 'Ark'. Verified the badge renders (18px, #00090C square, white evenodd mark). Co-Authored-By: Claude Fable 5 <[email protected]>
* Docs: How-it-works covers Lightning/Ark/SP/gifts; README rewriteAdam Soltys2026-07-051-2/+16
| | | | | | | | | | | The in-app page grows plain-language cards for Lightning swaps, Ark (instant off-chain, the unilateral escape hatch, expiry housekeeping, fees), silent payments, and gift links. The README catches up with reality: the native-JS Ark client headlines the feature list, and the modular HAL_FEATURES build system gets its own section — every feature is a plugin behind a build seam, and excluded code never ships. Co-Authored-By: Claude Fable 5 <[email protected]>
* Per-wallet networkAdam Soltys2026-07-051-9/+23
| | | | | | | | | | | | | | | | | | The network is now a property of each wallet, not a global mode. Every new wallet is born on the currently-selected network; activating a wallet activates its network (features re-init through the same networkChanged hooks the Settings switch uses); the Settings network card moves the ACTIVE wallet and sets the default for new ones. The stamp persists everywhere accounts do — session, durable directory, and vault — and legacy accounts adopt the current global once. Gift claims compose: an ark gift lists only wallets on its network as claim targets, and when none exist the fresh claim wallet is simply born on the gift's network — existing wallets keep theirs, so opening a foreign-network gift never disturbs anything. The wallet switcher tags non-mainnet wallets with their network. Co-Authored-By: Claude Fable 5 <[email protected]>
* Ark gifts: instant off-chain bearer gifts inside the gift flowAdam Soltys2026-07-051-1/+5
| | | | | | | | | | | | | | | | | | | | | | Ark can't presign a bearer spend, so an ark gift is a vtxo sent to an ephemeral ark identity whose seed IS the link (/ag/<code>: net, amount, 32-byte secret). The claimer rebuilds the identity, reads its mailbox, and sweeps to their own ark address — instant, free, and it works for a brand-new empty wallet with zero on-chain footprint. The sender keeps the secret, which is what makes revoke possible (first cosign wins). The gift form gains an On-chain/Ark source toggle when ark balance exists; ark gifts skip the lock/split logic entirely. Claim, choose- wallet, already-claimed, and nostr-locked (/lg/) flows all branch by code kind; unclaimed ark gifts list with one-tap revoke and lazily mark themselves claimed via GetVtxoStatus. Features stay decoupled: gifts asks for ark support via the new ctx.hook seam, so either feature builds alone. Also restores goHome in the feature ctx — lost in the plugin-seam extraction, it made the already-claimed screen throw on render. Co-Authored-By: Claude Fable 5 <[email protected]>
* Per-network nostr sync + honest balance loading stateAdam Soltys2026-07-041-4/+10
| | | | | | | | | | | | One shared d-tag let a network switch apply the mainnet snapshot to a signet wallet (the flash of wrong balance) and clobber mainnet state on the relays. Each network now syncs its own replaceable event (mainnet keeps the legacy bare tag), snapshots carry netName, and a foreign-net snapshot is never applied. The balance card spins until cache, Nostr, or a scan has populated this network once — 'scanning' alone missed the cache/Nostr window after wallet.load(). Co-Authored-By: Claude Fable 5 <[email protected]>
* Features phase 2b: silent payments + nostr sync leave the core walletAdam Soltys2026-07-041-70/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | wallet.js drops from 2,374 to ~1,970 lines, holding only BIP84 on-chain logic plus generic feature seams. New seams added this pass: registerBalanceExtra extra confirmed/pending buckets registerInputProvider extra spendable inputs for buildTx registerSendPreparer destinations needing post-selection derivation registerInputSigner non-BIP84 input signing registerHistoryProvider / registerScanHook / registerRealtimeHook / registerLoadHook / registerCacheExtension / registerCacheSavedHook src/features/sp-wallet.js: the whole BIP-352 engine — key derivation, worker-accelerated indexer scanning, the live indexer WebSocket, SP outputs as spendable inputs, sp1 send preparation, and per-output-key signing — installs via those seams (installSpWallet). src/features/sync.js: nostr identity + encrypted cross-device state sync plus its Settings card, installed via load/cache-saved/realtime hooks. profileChip/nostrProfile move here-adjacent (into gifts, the only other nostr consumer), so core app.js no longer imports nostr at all. buildTx/sign are now feature-agnostic (input providers + preparers + signers); _recomputeBalance* use the balance-extra registry, so a core build with no SP no longer calls a missing spBalance() (that regression dropped the minimal build into offline mode — caught by the smoke test). New coverage: tools/sp-test.js drives two browser "devices" through an SP send, indexer discovery, and an SP-input spend on the ark regtest chain (needs tools/sp-indexer.js pointed at bitcoind:18543). Minimal smoke now also asserts no SP/nostr code ships. Minimal profile: 314KB, down from 412KB (full: 580KB). All suites green: minimal smoke, sp-test, ark UI, gift lifecycle. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Build profiles: HAL_FEATURES selects which features shipAdam Soltys2026-07-041-5/+2
| | | | | | | | | | | | | | | | | | | | | | build.js swaps src/features/index.js for a generated module importing only the enabled features (gifts,swaps,ark,sp — unset means all, "none" means a plain on-chain wallet), so excluded feature code and its network endpoints never enter the bundle. Minimal profile: 476KB vs 577KB, with the Ark/gRPC, Boltz, and MuSig2 code verifiably absent. `bun run build:minimal` builds it. tools/minimal-smoke.js proves the minimal profile end-to-end: no receive-mode dropdown, no gift button, no swap/Ark/SP settings cards, no page errors, and a plain on-chain receive still lands. The two blessed profiles are full (everything, the existing e2e suites) and minimal (this smoke test); other combos should work but aren't CI'd. Gift and SP primitives still live inside wallet.js, so those bytes remain in the minimal bundle for now — extracting them is the next step if we want the core leaner still. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Features: extract gifts behind the plugin seamAdam Soltys2026-07-041-749/+48
| | | | | | | | | | | | | | | | | | | | | | The whole gift surface moves to src/features/gifts.js (~800 lines): create/split/lock flows, link viewing, revoke/reclaim, history rows + detail page, claim-tx row decoration and tx-detail section, the claim flow (fresh or existing wallet, nostr-locked gifts, claim codes, NIP-07 extension), the boot URL handling (/g/, /lg/, #gift=), the post-claim celebration, and the locked-in-gifts balance line. New seams this required: screenView (full-screen feature views), bootUrl (URL takeover at startup), giftOpened (claim pre-check on wallet activation), sendFormExtras, decorateTxRow, and multi-section txDetailSection. Account access goes through explicit ctx accessors (getAccounts/setAccounts) — the moved code briefly relied on an accidental cross-module binding that broke activeAccount() during claims; caught by the gift e2e. app.js: 4,206 → 3,000 lines. Ark + gift browser suites pass. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Features: extract swaps, Ark, and SP behind a plugin seamAdam Soltys2026-07-041-619/+73
| | | | | | | | | | | | | | | | | | | | | | | First step toward optional build profiles. app.js gains a small feature registry (ctx + FEATURES + hook helpers); swaps/Ark/silent-payments UI moves wholesale to src/features/{swaps,ark,sp}.js, each exporting a factory returning integration hooks: init/stop/networkChanged wallet lifecycle receiveModes/receiveTakeover receive tab isSendDest/matchSendText/ interceptReview/sendView/ hideSendControls/sendFormNote send flow historyEntries/historyDetail/ txDetailSection history balanceLines/settingsCards balance card + settings No behavior change: ark + gift browser e2e suites pass, and a probe confirms LN receive, all receive modes, and the three settings cards render as before. Gifts extraction and build flags come next. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* History: gifts are timeline entries, not a separate sectionAdam Soltys2026-07-041-52/+81
| | | | | | | | | | | | | | | Gift links now sort into the send/receive timeline like any entry: a clickable row (🎁, status tag, age, amount) opening a detail page that carries the date/status plus the actions that used to crowd the list row (view gift link, cancel/reclaim with the existing confirm flow). A claimed gift merges into its claim transaction's row — labeled as the gift, clickable to the tx detail, which gains a "This transaction delivered your gift" section (claim txid resolved via outspend and cached on the gift record). The old pinned gifts header and the paginated all-gifts view are gone. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Gift claim: instant 'Payment received!' after claimingAdam Soltys2026-07-041-2/+35
| | | | | | | | | | | | Claiming into an existing wallet used to drop onto the Receive tab (address/QR visibly rotating) until the background scan noticed the credit and fired the celebration. The claim already knows it succeeded and for how much, so the celebration now shows immediately; the scan runs behind it and its receive-index advance is acknowledged so the generic celebration doesn't fire a second time. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Gift claim: name the real failure when the funding tx isn't visibleAdam Soltys2026-07-041-1/+14
| | | | | | | | | | | | | | Claiming a gift whose funding tx is unknown to the claimer's data source (different network/chain, or not yet propagated) used to fail with the misleading "already been claimed". Now: - the claim screen probes the funding tx up front (esplora's status/ outspend endpoints don't 404 for unknown txids, so outspend alone can't detect this) and shows a network/data-source notice, and - a missing-inputs broadcast rejection maps to the same explanation instead of the generic already-claimed message. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Gift claim: correct copy when claiming into an existing walletAdam Soltys2026-07-041-1/+3
| | | | | | | | | "Claim it into a brand-new wallet that only you control." only fits the new-wallet path; claiming into an existing wallet now says which wallet it lands in ("Claim it into your wallet "Wallet 1"."). Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Gift claim: make the wallet chooser read as a choiceAdam Soltys2026-07-041-3/+7
| | | | | | | | | | | | The existing-wallet buttons looked like inert inputs. Now: a "Receive into one of your wallets:" label, a chevron on each wallet row so it reads as tappable, and an "or" divider before the new-wallet button. (tools/ark/gift-shot.js: screenshot harness that mints a real regtest gift and opens its link.) Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Ark: 'Sent!' screen matches the receive celebrationAdam Soltys2026-07-041-3/+7
| | | | | | | | Tap anywhere to proceed instead of a Done button, and the sent amount shows in red (amount-neg) rather than green. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Ark: real-time receives over the SubscribeMailbox gRPC streamAdam Soltys2026-07-041-1/+4
| | | | | | | | | | | | grpcStream() parses gRPC-web frames incrementally off fetch's body stream; the manager keeps a long-lived SubscribeMailbox subscription (auto-reconnect, 3s backoff) whose messages flow through the same duplicate-safe processing as the poll. Receives now land the moment the sender delivers (~sub-second) instead of on the next poll; the poll stays as fallback and to drive in-flight boards/refreshes. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Ark: history rows open a detail viewAdam Soltys2026-07-041-3/+43
| | | | | | | | | | | Ark movements are clickable like on-chain txs. The detail view shows amount, date, status, the destination address (sends, copyable), the vtxo id, and for boards the funding txid with copy + explorer link. Movements now record those fields at completion time; older records without them still render (amount/date/status only). Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Ark: hide fee-rate, coin control, Max, and add-recipient for Ark sendsAdam Soltys2026-07-041-4/+6
| | | | | | | | | An arkoor send has no mining fee and no coin selection, so pasting an Ark address now shows just the amount field plus a hint line; the irrelevant on-chain controls stay hidden. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Ark: boarding success screen with txid link instead of a toastAdam Soltys2026-07-041-2/+21
| | | | | | | | | | Broadcasting a board now lands on a checkmark screen showing the amount that will arrive (after the board fee), a note about the confirmation, and the funding txid with copy + explorer link; Done returns to the Receive tab. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Ark: give the boarding/refresh toasts time to be readAdam Soltys2026-07-031-4/+4
| | | | | | | | toast() takes an optional duration; the two informational Ark messages (full sentences, not confirmations) show for 5s instead of 1.6s. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Ark: boarding lives on the Receive tab's Ark viewAdam Soltys2026-07-031-14/+19
| | | | | | | | | | | Selecting Ark on Receive now shows the address plus an inline "move on-chain funds into Ark" form (with available balance / minimum hints). The Settings card slims down to server choice, coin count, in-progress operations, and refresh/consolidate; the balance already shows on the balance card. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Ark: connect lazily — only dial the server once the wallet uses ArkAdam Soltys2026-07-031-14/+57
| | | | | | | | | | | Opening a wallet no longer contacts the ASP unless it already holds vtxos / history / unfinished operations. Fresh wallets connect on first use instead: selecting Ark on the Receive tab, confirming an Ark send, or the Connect button on the Settings card. connectArk() is idempotent and generation-guarded against wallet switches mid-dial. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Ark: drop the activity list from the Settings cardAdam Soltys2026-07-031-9/+0
| | | | | | | | History is the home for Ark movements now; the Settings card keeps balance, coin count, board, refresh, and in-progress operations. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Ark: show Ark movements in the History tabAdam Soltys2026-07-031-6/+35
| | | | | | | | | Receives, sends, and boards interleave with on-chain transactions in one time-sorted, paginated timeline, each tagged 'Ark'. Refreshes are internal churn and stay in the Settings activity list only. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Ark: 'Payment received!' celebration for Ark receivesAdam Soltys2026-07-031-0/+19
| | | | | | | | | Same card and tap-to-acknowledge flow as on-chain receives; the ack persists in the ark state (shows exactly once) and a 2h recency guard keeps old payments from celebrating when a wallet is opened later. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Ark: wire into the wallet UIAdam Soltys2026-07-031-3/+253
| | | | | | | | | | | | | | | | | | | | - Settings: Ark server card (off by default, per-network presets incl. Second mainnet + local regtest, custom URLs) with balance, coin count, board form (on-chain -> Ark; funding output pinned to vout 0 via the new buildTx noSort option), refresh/consolidate, and recent activity. - Receive: Ark option in the address-type dropdown (QR + copy). - Send: t?ark1 addresses are recognized in the normal send form and route to an Ark confirmation (no mining fee) with a success view. - Balance card: Ark balance line under the on-chain figure. - ArkManager lifecycle: per-wallet instance created on account activation, background sync every 5s (regtest) / 30s, state persisted under the wallet cache key. Verified end-to-end in a real browser (tools/ark/ui-test.js, puppeteer against the regtest stack): receive, send, board, and refresh all green. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01QFAcD4V284DvYZZHP7Rxxy
* Swaps: reuse the generic 'Payment received' screen for LN receivesAdam Soltys2026-06-301-12/+7
| | | | | | | | | | | | A reverse-swap claim is an on-chain receive, so instead of a separate LN 'Received!' card (which stacked with the generic celebration and needed suppression), credit the claimed coin to the wallet the instant we broadcast the claim — new wallet.creditReceive() mirrors the instant-payment watcher path (adds the utxo + pending row, advances the receive index, emits). The generic 'Payment received!' then fires immediately with the right amount, one screen, one tap. Dropped the LN success card + the suppression logic. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* Receive: don't stack the generic celebration over the Lightning 'Received!'Adam Soltys2026-06-301-2/+6
| | | | | | | | | | A reverse-swap claim is also an on-chain receive, so after the LN 'Received!' card the generic 'Payment received' celebration would fire too — making the first Done tap appear to do nothing (it just revealed the second screen). Suppress the generic celebration while the LN claim card is shown, and have its Done ack the generic one as well, so a single tap dismisses both. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* Send progressive disclosure, swap context in tx detail, LN amount placeholderAdam Soltys2026-06-291-48/+59
| | | | | | | | | | | | | | | | | | - Send: show only the destination input ('Address or Lightning invoice') until a valid on-chain/SP address is entered, then reveal amount + fee rate + coin selection + Review. A pasted bolt11 still auto-advances to its own confirmation, so those controls never appear for it. New wallet.isOnchainAddress() validator + a destReady() gate; recipient onInput/paste re-render only when validity flips. - History: stop listing swaps at the top. Instead, a send/receive that was part of a swap shows its Lightning context (invoice, swap fee, status, refund) on the tx detail screen via swaps.findByTxid(). Removed the dead swapListView. - Lightning receive: drop the '50000' amount placeholder — a bare number looked like a value was already entered; the min/max hint below covers it. Verified in-browser: controls hidden until a valid address, then revealed; LN receive placeholder empty; no errors. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* Copy: 'The swap provider pays the invoice once the on-chain lockup confirms'Adam Soltys2026-06-291-1/+1
| | | | Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* Receive: drop the dropdown label, rename 'Address' → 'Bitcoin address'Adam Soltys2026-06-291-4/+2
| | | | | | | | The 'Receive over' label was redundant above a self-explanatory dropdown; remove it (and the now-unused i18n key). Rename the first option to 'Bitcoin address' so it's clear alongside Lightning and Silent payment. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* Swaps: say 'Swap fee' / provider-agnostic copy instead of naming BoltzAdam Soltys2026-06-291-1/+1
| | | | | | | | | The fee label and status copy shouldn't hardcode the provider, since the swap backend is configurable. 'Boltz fee' → 'Swap fee', and the pay/settle messages no longer name Boltz. (The settings card still says 'Boltz-compatible provider', which is an accurate description of the API standard.) Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* Receive dropdown, drop the Swap tab, auto-detect pasted invoicesAdam Soltys2026-06-291-39/+28
| | | | | | | | | | | | | | | | | - Receive: replace the 3-button segmented control (too wide on mobile) with a compact 'Receive over' dropdown that scales to more address types. - Remove the standalone Swap tab. Paying an invoice now lives in Send; the in-flight/recent swap list folds into the top of History. Deleted the dead swapTab + doSubmarine. - Send: as soon as a valid bolt11 is pasted/typed/scanned into the recipient field, jump straight to the Lightning confirmation (submarine-swap quote with itemized cost) — the invoice's baked-in amount is used, so the amount field is skipped entirely. Wired into the recipient onInput, the paste button, and QR scan. Verified in-browser: Swap tab gone, dropdown renders, and a pasted 60k invoice auto-progresses to 'Pay over Lightning' with the Boltz fee shown, no Review tap. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* Send: pay a pasted Lightning invoice via an auto submarine swap (itemized cost)Adam Soltys2026-06-291-0/+54
| | | | | | | | | | | | | | | | | Paste a bolt11 into the normal Send recipient field and Review now detects it and routes through a Boltz submarine swap — no 'swap' concept surfaced. Split startSubmarine into quoteSubmarine (POST + build-but-don't-broadcast the funding tx) and fundQuotedSubmarine, so the review shows an itemized cost before committing: Amount + Boltz fee + on-chain network fee = Total. Pay funds the lockup; Boltz pays the invoice once it confirms. Verified on regtest: a 60,000-sat invoice quotes to Amount 60,000 / Boltz 362 / network 442 / Total 60,804, with a Pay button. Lightning-address (LNURL) input + removing the standalone Swap tab are the remaining pieces. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* Receive: add a Lightning option (reverse swap) next to Address + Silent paymentAdam Soltys2026-06-281-35/+69
| | | | | | | | | | | | Receive now has a segmented [Address | Lightning | Silent payment] toggle. 'Lightning' takes an amount and creates a Boltz reverse-swap bolt11 to share; when it's paid, Boltz locks up on-chain and the SwapManager claims it into this wallet automatically (shown live, then 'Received!'). Gated to non-watch-only wallets (a reverse swap needs our keys). Removed the duplicate 'Receive over Lightning' card from the Swap tab. Verified in-browser on regtest: real limits (Min 50,000) load via the proxy and an invoice is created. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* Swaps: gate 'Receive over Lightning' on watch-only (was throwing 'uint8array ↵Adam Soltys2026-06-281-9/+15
| | | | | | | | | | | | expected') A watch-only wallet has no private key, so swapNode().privateKey is null and startReverse's sha256(node.privateKey) threw 'uint8array expected'. The receive card wasn't gated by watchOnly (the pay card already was). Hide both for watch-only and show a prompt to re-enter the recovery phrase, since swaps need the key to derive the preimage and claim on-chain. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
generated by cgit v1.2.3 (git 2.51.0) at 2026-10-17 20:37:43 +0000