| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
esptool-js leaves the chip in the ROM bootloader stub after writeFlash,
so the device appeared dead until power-cycled. Pulse RTS the way
esptool.py does, drop the port (the C3 re-enumerates), and show a
"device restarted" message next to the Connect button.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_014gVYGi29FjTeLdNTiutkZx
|
| |
|
|
|
|
|
|
|
|
| |
The flasher hex-encoded whatever the /flash endpoint returned, so a
server error body was written to devices as the config partition.
Check the response status, require a 128KB image with the LittleFS
magic, and surface the error above the form instead.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_014gVYGi29FjTeLdNTiutkZx
|
| |
|
|
|
|
|
| |
account, tell names.coinos.io which v3 identity may claim it (MIGRATE_TOKEN), with retries; without the grant the registrar squat guard refused every migrated claim
Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01MrkLsNScXe9b6BviUSdmMr
|
| |
|
|
|
|
|
|
|
|
| |
"Move my balance and address to coinos v3" wrapped on a phone; the
paragraph above already says what happens, so the button is just
"Migrate". The destination row went with it — it only ever said "your
coinos v3 wallet".
Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Wvj4aoeMZwA7VUGdJP9Swi
|
| |
|
|
|
|
|
|
|
|
| |
Renaming to <name>v2 was a hack for freeing the username, and v3/v4/v9
fallbacks made it worse. The page now sweeps the balance and sets the
new `migrated` flag: the registrar takes over receiving for the name
while the old account keeps working here, unchanged.
Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Wvj4aoeMZwA7VUGdJP9Swi
|
| |
|
|
|
|
|
|
|
|
| |
The server enforces /^[\p{L}\p{N}]{2,24}$/u, so <name>_v2 was rejected
outright. Candidates are <name>v2, v3, … each trimmed to fit the 24-char
limit (so a long username still lands inside it), and the rename walks
to the next one if a retired name is already taken.
Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Wvj4aoeMZwA7VUGdJP9Swi
|
| |
|
|
|
|
|
|
|
|
| |
It's an npub-shaped placeholder, and the whole point of the page is that
the user keeps their real username — seeing "[email protected]" as the
destination just reads as a mistake. The row says "your coinos v3
wallet" instead.
Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Wvj4aoeMZwA7VUGdJP9Swi
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two fixes from the first live test:
The POST went out from the browser, where $lib/utils' base is "" — so
it hit the SvelteKit page route and came back "POST method not allowed".
Payments in this app all run server-side with auth(cookies), because
that's where the session token is usable; /migrate is a form action now
like the rest of the send flows.
And the routing reserve is gone: the ASP's node has two direct channels
to ln.coinos.io, so a sweep is one hop and costs nothing. It sends the
full balance, only retrying 0.5% lighter if a payment actually comes
back short.
Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Wvj4aoeMZwA7VUGdJP9Swi
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
coinos v3 links here with ?to=<the user's new payment address>&back=<url>.
The user is already signed in on this site, so no password or key has to
travel anywhere: we fetch an invoice from the v3 registrar for the
balance (less a small routing reserve), pay it, then rename the account
to <username>_v2 — which releases the username so v3's registrar will
let them claim it. Old account stays, renamed, and stops receiving.
Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Wvj4aoeMZwA7VUGdJP9Swi
|
| |
|
|
|
|
|
|
|
|
| |
Addresses at our own domain used to have the domain stripped and get
paid internally on the assumption that every one of them was ours. v3
payment addresses live at the same domain, so check the account exists
first and otherwise leave the address intact — it then flows through
the normal lightning-address path.
Co-Authored-By: Claude Fable 5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Lightning/bolt12 sends now start unconfirmed (server sets confirmed=false
until the HTLC settles and the preimage arrives). Reflect that in the UI:
the payment list and detail page show 'Pending' for an unsettled send, and
the detail page shows a pending note in place of the empty preimage. Prevents
the misleading 'Sent/completed with no preimage' state for held HTLCs (e.g.
Ark hold invoices that stay in-flight for hours).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
- parse lno= from BIP-321 bitcoin: URIs; send page parses offers for
preview now that /parse handles them
- settings/nostr shows the user's standing lno1 offer with copy/QR and a
button to publish it as a kind 10058 offer list for NIP-177 zaps
- new locale strings translated
Co-Authored-By: Claude Fable 5 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The merchant receive and invoice pages mutated the $derived `invoice`
proxy (setType/setAmount/setMemo) then POSTed it. Mutating a $derived
and JSON.stringify-ing it serializes unreliably, so a stale type
(on-chain when lightning was expected) and a stale/10x-shifted amount
could leak from a prior interaction into POST /invoice (funk POS bug).
Build the body as { ...$state.snapshot(invoice), ...changes } so the
intended type/amount/address_type reliably win; update() takes the
plain body. Front-end only.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Co-Authored-By: Claude Opus 4.6 <[email protected]>
|
| |
|
|
| |
Co-Authored-By: Claude Opus 4.6 <[email protected]>
|
| | |
|
| | |
|
| |
|
|
| |
Co-Authored-By: Claude Opus 4.6 <[email protected]>
|
| |
|
|
| |
Co-Authored-By: Claude Opus 4.6 <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|