coinos-ui.git/src/routes, branch master

nostr: fetch the encrypted key with the password when there's no session key

2026-10-13T23:23:39Z

Without the sk cookie from a password login (nostr logins, older sessions) the reveal button was hidden and signing failed. Ask for the password and get the key from /nsec instead. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01UjHzoBmW1iPpEe5qC2LDYB

nostr: sign with the session key instead of the encrypted key from /me

2026-10-08T19:15:17Z

Co-Authored-By: Claude Opus 5.5

send: explain duplicate submits instead of reporting a routing failure

2026-10-02T14:10:15Z

Resubmitting an invoice that was already paid, is still in flight, or is awaiting reconciliation came back as the generic "failed to route" error, which reads as if the payment never went out. Map those server responses to specific messages with a link to the payment history. Co-Authored-By: Claude Opus 5.5

Add a dismissable banner pointing to v3.coinos.io

2026-09-29T22:07:41Z

Co-Authored-By: Claude Opus 5.5

ecash: carry pasted tokens in the URL instead of storing them server-side

2026-09-27T21:46:30Z

The server no longer accepts anonymous token uploads. A pasted token now redirects straight to /ecash/, and the page asks the server for the token's status statelessly. Ids from previously shared links still resolve. Co-Authored-By: Claude Fable 5.1

invoice: a reusable bolt12 offer has no terminal paid state

2026-09-22T18:27:15Z

A bolt12 offer is a standing payment code. CLN derives the same offer_id from the same (amount, description), so re-creating one hands back the original record, whose `received` has accumulated over the offer's whole lifetime. The invoice layout read that as "this invoice was paid" and redirected to the success screen, so reopening a long-lived offer never showed the QR and left no way to copy the lno. Treat a payment as celebratory only when it arrives while the page is open: the socket handler now passes the amount of that payment as `?paid=`, and the layout uses it in place of the lifetime total for reusable offers. Single-use invoices keep the existing logic, so a partly-paid invoice still stays on the QR rather than celebrating early. The success screen showed lifetime `received` for the same reason, which misreported a single payment to a long-lived offer; it now renders the amount the socket reported, which is already net of tip. Co-Authored-By: Claude Opus 5 (1M context)

Web flasher moves from /pos to /flash; /pos redirects there.

2026-09-22T05:49:19Z

coinos v3 takes /pos for the point-of-sale till, so the terminal flasher needs its own address. Old links keep working through the redirect. Co-Authored-By: Claude Fable 5.1 Claude-Session: https://claude.ai/code/session_01Tmfg8k5f3TbNJS34qiqHAp

send: stop the Max buttons from cancelling their own submit, show LNURL action errors

2026-09-22T02:41:39Z

Choosing Max on the LNURL-pay page left the button spinning forever. Two things combined: The Max buttons set `loading` from their click handler. Svelte flushes `disabled={loading}` to the DOM before the browser runs the button's submit activation, and a disabled button submits nothing. Set loading from the form's onsubmit instead, the way the Send button always did. The /ln page never passed `form` into the Lnurlp and Lnurlw components, so any action failure (pay, max or withdraw) rendered nothing and never reset the spinner. Pass it through, and reset loading when a result arrives. Verified in headless Chrome against the dev stack: the bolt11 Max lands on the fee view, and the LNURL Max surfaces the server's error and re-enables the buttons. Co-Authored-By: Claude Fable 5.1

funds: remove the create, deposit, withdraw and gift buttons

2026-09-22T02:40:21Z

Funds are retired, and the server now refuses deposits, withdrawals and pre-authorizations outright, so every one of these buttons led to an error. Gone: "Create a fund" on the send screen, and Add/Take funds plus the gift link on a fund's page. A fund's page still shows its balance, managers, share link and payment history, so existing funds stay readable while they are settled out of band. Co-Authored-By: Claude Opus 5 (1M context)

send: quote the lightning routing fee up front and add Max to lightning sends

2026-09-22T02:21:43Z

The lightning send page now asks the server what the payment will cost before showing the Send button: the exact routing fee from the route query, the platform fee, and the total. The quoted fee is submitted as the maxfee, so what the user sees is what gets debited; advanced settings still let them override it, and if the quote fails the page falls back to the old 2% reserve. Max on the amount step asks the server for the largest amount whose amount + routing fee + platform fee lands exactly on the balance, and for an offer picks up the invoice fetched for that exact amount. LNURL-pay gets a Max button too. The invoice only exists once we name an amount, so the action fetches a probe invoice at the ceiling, lets the server solve for the amount, then fetches the real invoice for it. Co-Authored-By: Claude Fable 5.1