aboutsummaryrefslogtreecommitdiffstats
path: root/src/features/zaps.js
Commit message (Collapse)AuthorAgeFilesLines
* Max fills the amount in the unit the field shows: in fiat that's money ↵Adam Soltys6 days1-4/+4
| | | | | | floored to the cent (so it never parses back above the maximum), not a BTC figure under a CAD label. One ctx.amountField helper for the ark send/LN Max, the gift Max and fixed-amount zap/BOLT 12 fills Co-Authored-By: Claude Opus 5.5 <[email protected]>
* History: a Lightning payment still settling (a zap, mostly) shows at once as ↵Adam Soltys7 days1-1/+1
| | | | | | | | a pending Sent row with the recipient's face, and gives way to its completed row One-tap zaps now record who they went to, so their rows carry a face too. Co-Authored-By: Claude Opus 5.5 <[email protected]>
* Send: a lightning address moves on to the amount by itselfAdam Soltys12 days1-0/+6
| | | | | | | | | | | | | - Pasted with the keyboard (not only the Paste button) it is complete text: it advances at once, as a paste always did through the button. - Typed and then left alone for 0.9s, it is checked quietly (names: our registrar or BIP-353 DNS; zaps: the LNURL-pay endpoint answers) and the form moves on only if something answers. A half-typed domain answers nothing, so it just waits, with no error; finishing it moves on. - tools/send-lnaddr-advance-test.js (live registrar/DNS, [email protected]). Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Dmcrt9KyNDKVWFKnb8BREo
* Add cooperative coin exits and clarify profile, preview and zap controlsAdam Soltys13 days1-3/+5
|
* Clear abandoned payments, reset profile Pay and restore native messaging BackAdam Soltys13 days1-0/+1
|
* Zaps: the sound can be switched off — from the held bolt or Settings → ↵Adam Soltys2026-09-191-1/+5
| | | | | | | | | | Nostr. A prefs flag (zapSound, absent = on) synced with the zap amount. The strike and the tally are unchanged; only the clip stays quiet, and the clip chunk is not even fetched while it's off. Co-Authored-By: Claude Fable 5.1 <[email protected]>
* Zaps: the sound, the sender, and one action bar for every post.Adam Soltys2026-09-181-3/+6
| | | | | | | | | | | | | | | | | | Tap feedback: a bolt strike, the amount popping off the button, the post trembling, and the zap.mp3 clip. The clip is 62KB of base64 and messages.js is boot code, so it is its own chunk, fetched once a zappable post is on screen and played inside the tap once loaded; the standalone build inlines it. Ark zap receipts are signed by the wallet key, which has no profile: they now carry the login identity as the sender (NIP-57's P tag), readers prefer it, and our own older receipts read as us. The action bar is the same six slots on every post: the zap button and the who-reacted chevron are always there (inert until they have something to do), so the first zap no longer reflows the row, and you can zap your own posts and messages. Community rows centre their unread dot off the edge. Also in here: reactions with custom emoji, reply-composer focus under the tapped post, profile fetch retry, and Lightning zap failures that say so. Co-Authored-By: Claude Fable 5.1 <[email protected]>
* The zap chip lands on the tap and pulses until the payment settles.Adam Soltys2026-09-101-1/+5
| | | | | | | | | | | | | | | | | | | A zap took a few seconds to pay and its public receipt trailed that by seconds more, so the tally chip appeared long after the tap — the tap looked ignored, and the only way to tell it had worked was the toast. Now the chip appears on the tap carrying your amount, breathing while the payment is in flight; it goes solid the moment the payment lands, and steps aside when the real receipt arrives (which is also how it avoids counting your zap twice). The ark and Lightning one-tap flows report their outcome back — a failure, or a fallback into the form, takes the chip straight off again rather than leaving it pulsing. An unreported zap gives up after 45s. A zap sent from the form reports too, so the tally shows it right away instead of waiting on a relay. Reduced-motion gets a dimmed chip, no pulse. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_019mrt228Upn9nNCwGixzSLx
* Tap payments: no recipient-form flash before the pay animation.Adam Soltys2026-09-071-8/+22
| | | | | | | | | A scanned/tapped/pasted payment (NFC LNURL, a pasted lnurl/lnaddr) briefly showed the recipient form — heading, recipient chip, "finding…" spinner and a Back button — while the LNURL was fetched over the network, before flowing into the pay animation + success. That resolving skeleton read as a form the user had to look at on every tap. Now a tap carries a `tap` flag (set for the scan/paste/NFC entry points: matchSendText with !typed, lnAddressFallback, offers), and during resolve/invoice it renders a minimal centered paying shell — the same autopay-card the ark pay animation uses (spinner-ring ⚡ badge, no Back button) — so a tap goes straight spinner → animation → success with no form in between. Typed lightning addresses keep the normal form (they still resolve through the send form, not a tap). The resolved recipient name/amount arrive on the next screen; the shared card class makes the handoff into the ark autopay animation seamless. Co-Authored-By: Claude Opus 4.8 <[email protected]> Claude-Session: https://claude.ai/code/session_01MGzU12QrAA4G6BYGzGVdXz
* LNURL/merchant payments read as PAYMENTS, not zaps, and skip redundant ↵Adam Soltys2026-09-061-7/+47
| | | | | | | steps. (1) Terminology: a payment is a "zap" only when it targets a nostr person or note (npub / note-zap with an eventId, captured as z.social at begin); paying a lightning address, LNURL or merchant now says "Pay over Lightning" / "Pay" everywhere — amount screen, review title, success screen — even when the endpoint supports zap receipts. (2) A fixed-amount payment (min==max — a POS tag, paywall, bolt card) has nothing to type, so the amount screen is skipped and the flow goes straight to the quote/review; the two perceived confirmations collapse to one. (3) Per-recipient auto-pay budget: the review offers "Auto-pay <merchant> up to N next time" (ctx.lnBudget/setLnBudget in prefs, synced), and a fixed charge within a set budget pays as soon as the quote lands — no tap. Guarded: only fixed amounts, only within the budget, only when funds cover it; over budget / no funds / quote error all fall back to the normal review, and social zaps are untouched. Verified with a driven-feature harness (fake ctx + local LNURL server): fixed skips to startLnPay with social=false/fixedSat set, a covering budget sets autopay, variable still shows the amount screen titled/buttoned "Pay" Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01MGzU12QrAA4G6BYGzGVdXz
* Settings: lay the payment-address sections out as cards; zap settings under ↵Adam Soltys2026-09-051-2/+2
| | | | | | | | | | | | Nostr Custom name, point of sale, the terminal's tap-to-pay link, own node and own domain each get a card on Settings → Payments instead of hiding in collapsed sections. The one-tap zap amount and the CLINK zap code move to Settings → Nostr, where the other nostr settings are. Co-Authored-By: Claude Fable 5.1 <[email protected]> Claude-Session: https://claude.ai/code/session_01VMi2Y1oKPZ3TeeFmLej47y
* LNURL payments name the merchant: after the pay-params fetch, the metadata's ↵Adam Soltys2026-09-051-0/+24
| | | | | | | text/identifier (the lightning address) replaces the bech32 blob as the payee's name and address on the amount screen, with the text/plain description as fallback. And when the address is a coinos name — whether it arrived as an lnurl's metadata, a typed [email protected], or an intent — the registrar is asked who owns it and the screen wears their AVATAR via the same profileChip the npub zap flow already uses; the pubkey also lets a NIP-57 zap request attribute to the right person. Lookup is fire-and-forget so the amount screen never waits on it Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01MGzU12QrAA4G6BYGzGVdXz
* Chat goes full-bleed on phones like the notes feed — the home list, ↵Adam Soltys2026-09-051-0/+7
| | | | | | | community rooms and DM threads (now sharing a chat-page class) drop their card walls and run edge to edge under 520px — and the type steps up a notch: bubbles 14→15px, names 13→14px, timestamps 11→12px. Plus: a fixed-price LNURL (minSendable == maxSendable — bolt-card top-ups, paywalls, static charges) no longer prompts for an amount — resolve() fills it and locks the field via the same fixedSat machinery fixed-amount BOLT 12 offers already use (disabled input, adjusted hints, confirm bypass) Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01MGzU12QrAA4G6BYGzGVdXz
* Handle lightning:lnurl1… links properly. Two faults: (1) an intent often ↵Adam Soltys2026-09-051-3/+12
| | | | | | | arrives BEFORE the paying feature is ready — ark connects lazily, so zaps' matchSendText declined and the raw URI fell through into the recipient field as dead text; the intent dispatcher now keeps re-offering the text to the feature chain for up to 20s and sweeps the leftover raw text out of the recipient when a feature claims it (the zap amount screen takes over). (2) When the fallback button did render, it read "⚡ Zap lightning:lnurl1dp68gurn8ghj7…<overflow>" — zapDisplay now names targets like a human: the address when there is one, a shortened bech32 otherwise, on both the send-form button and the amount screen Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01MGzU12QrAA4G6BYGzGVdXz
* Max reaches every Lightning amount form: amountless bolt11s, ark zaps, and ↵Adam Soltys2026-09-021-0/+7
| | | | | | | lightning-address zaps all fill spendable-minus-estimated-fees (sum over the 24-input cap, schedule fee plus the routing reserve, real quote confirms at pay time) — emptying Spending over Lightning stops being arithmetic homework Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01MrkLsNScXe9b6BviUSdmMr
* The wallet learns to read BOLT 12 for itself: offers and invoices decode ↵Adam Soltys2026-08-291-1/+54
| | | | | | | client-side, and every invoice the ASP fetches over onion messages is verified here — payment hash read from the raw TLVs, offer terms mirrored byte-for-byte, the issuer's schnorr signature checked against LDK's exact merkle construction (proven against a live CLN-signed fixture) — so no server can hand back an invoice whose preimage it already holds. Paste an lno1 or resolve a name whose record carries one and the existing HTLC pay flow carries it (captaind's Invoice enum takes lni strings natively); a name's owner may now publish their OWN node's offer in their DNS record, retiring the registrar's stand-in — senders fetch invoices straight from their node and no coinos service ever touches the money. The /lnquote fallback prices blinded paths by entry node + advertised payinfo Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_019WboeoetMF3MTmgT7Ew8yi
* An address can point home: a name's owner may register their own CLINK offer ↵Adam Soltys2026-08-291-2/+60
| | | | | | | code and the registrar asks THEIR node for invoices — delivered there first, float as fallback, and no invoice is relayed or paid unless it demands exactly the sats owed on the right network. hal learns to pay pasted noffer1 codes through the zap flow (fixed, variable and payer-chosen pricing, amount verified before the HTLC locks). The depth advisory slims to one line — an uncooperative exit's price and a Manage link — and the new coins screen shows each vtxo's amount, expiry and arkoor depth beside what renewal costs and buys Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_019WboeoetMF3MTmgT7Ew8yi
* An empty Spending stops being a dead end: the zap button becomes the door to ↵Adam Soltys2026-08-171-10/+14
| | | | | | | boarding, prefilled with what the payment needs and open to more Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01JtaatFfAbx91Nh3xqKVqKz
* The social layer grows up: a header magnifier finds anyone on nostr, ⚡ ↵Adam Soltys2026-08-151-2/+50
| | | | | | | zaps your saved amount in one tap (asking once if you haven't picked one), and tapping a note opens its thread Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_014tE4U5nEjGTQy8PwYqamfv
* Profiles wear their latest notes, each one zappable; a zap with no ark ↵Adam Soltys2026-08-081-5/+8
| | | | | | address to land on becomes a gift only their key can open Co-Authored-By: Claude Fable 5 <[email protected]>
* Zap: resolve inside a skeleton of the card that's comingAdam Soltys2026-08-031-5/+14
| | | | | | | | | | | | | | The inline-progress attempt still read as a flash — the send form was visible behind it with the raw npub, its verification block and the gift button, then all of that was replaced. Now both resolution phases (ark advert, then lightning) render the SHAPE of the destination card: same title, same recipient chip, a spinner where the amount form will be, and a working Back. The card fills in instead of the screen changing twice, and the two flows share one title so it never re-titles at the handoff. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Wvj4aoeMZwA7VUGdJP9Swi
* Pay screens: bigger recipient chip, no loading-screen flashesAdam Soltys2026-08-031-5/+10
| | | | | | | | | | | | Resolving a recipient (ark advert → BIP-353 → lightning) no longer takes over the screen twice on the way: both steps keep the send form in place and report progress as one inline line, so picking someone goes straight to something actionable. The recipient chip on the zap card gets a large variant — a 30px avatar and full-size name, since it's who the money is going to. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Wvj4aoeMZwA7VUGdJP9Swi
* Zap screens show the recipient, cap amounts to Spending, faster searchAdam Soltys2026-08-031-6/+20
| | | | | | | | | | | | | | | | | | | The zap flows (ark-direct and Lightning) show the recipient's avatar chip instead of a bare name, and their LNURL ceiling is now capped by our own Spending balance — when Spending can't cover their minimum the amount field is replaced by a plain "not enough in Spending" notice rather than an impossible "min 1 · max 0" range. The confirm path enforces the same cap. Recipient search feels instant now: the first short query fires after 120ms (the wait users actually notice) and longer mid-word queries wait 500ms to skip characters still being typed; cached prefixes stay instant. Onboarding success screen: check below the title and larger. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Wvj4aoeMZwA7VUGdJP9Swi
* Profiles: view pages, editable own kind 0, zap recipients in historyAdam Soltys2026-08-021-1/+1
| | | | | | | | | | | | | | | | | | | Tapping any avatar or author name (chat rooms, DM threads, the chat home) opens a profile page: avatar, name, nip05, lightning address, about, npub, with Message and Pay actions (Pay runs the npub payment cascade). Your own profile — reachable from your avatar on the chat home — gets an editor for name, about, picture, and lightning address (prefilled with your coinos address); saving merges over the newest published kind 0 so fields we don't understand survive the round trip. Zaps now remember who they went to: the ark feature keys the recipient by what the movement already records (destination address or invoice) and history rows wear a clickable avatar chip that opens the profile. The messages feature exposes showProfile/profileChip seams so any feature can do the same. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Wvj4aoeMZwA7VUGdJP9Swi
* Payment names: ₿[email protected] via BIP-353 DNS payment instructionsAdam Soltys2026-08-011-0/+9
| | | | | | | | | | | | | | | | | | | | Receiving: a Settings card claims a username, signed with the wallet's nostr key; the new names registrar (names/server.js, deployed at names.halwallet.app) enforces first-come ownership by that key and mirrors the claim into a DNSSEC-signed TXT record at <name>.user._bitcoin-payment.halwallet.app whose BIP-21 URI carries the wallet's reusable ark address. The record re-registers itself if the ark address ever changes, and a collapsible hint shows the single CNAME a user adds to serve the same name from their own domain (BIP-353 supports delegation when both zones are DNSSEC-signed). Sending: a pasted name@domain resolves over DNS first — two independent DoH resolvers must agree and both report the DNSSEC AD flag (full client-side chain validation is the stated follow-up) — an ark= instruction pays natively, an on-chain path fills the send form, and a name with no DNS record falls back to the Lightning-address zap flow. Co-Authored-By: Claude Fable 5 <[email protected]>
* Fix send-form UX around lightning pays; harden ln state machinesAdam Soltys2026-07-311-13/+21
| | | | | | | | | | | | | | | | | | | - 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]>
* Add NIP-57 Lightning zaps (npub / lightning address / lnurl)Adam Soltys2026-07-301-0/+163
Send a Lightning zap to a nostr npub, a lightning address (name@domain), or an lnurl. New src/lnurl.js does the resolution half — target → LNURL-pay params → signed kind-9734 zap request → callback → bolt11 — and the new zaps feature (src/features/zaps.js) drives the amount/comment UI, then hands the invoice to the existing Boltz submarine-swap flow via a new swaps.startLnPay hook, so there's one tested pay/review/confirm/success path. Routing: a bolt11 is still caught by swaps; an npub still prefers an instant free Ark zap when Ark can serve it, and only falls through to a Lightning zap otherwise — ark's "no Ark address" screen also offers an explicit "Zap over Lightning" fallback (gated on the zaps feature's canLnZap). A real zap receipt is attributed only when the server advertises allowsNostr and we know the recipient's pubkey; otherwise it degrades to a plain LNURL-pay. Nostr seam gains nostrSign (finalize without publishing), nostrProfile (kind-0 with lud16/lud06), and nostrRelays. Lightning addresses are debounced in matchSendText since their regex matches mid-typing. Verified: unit tests for parse/encode/zap-request; a live resolve→signed 9734→payable mainnet bolt11 against coinos; and an in-browser DOM smoke (zap form + LNURL params over CORS + allowsNostr hint + handoff). Co-Authored-By: Claude Opus 4.8 <[email protected]>
generated by cgit v1.2.3 (git 2.51.0) at 2026-10-15 05:13:05 +0000