A tap or click on a block or a shard cell now pins its details. The panel stays until a tap or click lands
anywhere else, Escape, the close control, or the block scrolls out of the strip (then a 200 ms fade, no snap).
Another block switches the pin. The pinned block carries a molten ring. The pinned panel sits at a fixed
spot at the top left of the strip, so new blocks never move it, and shows a PINNED label and a 32 px close
control for a thumb.
Hover is unchanged on pointer devices: another block shows its floating panel for as long as the pointer is on
it, then the panel returns to the pinned block. Hover never clears a pin.
Pointer events only: one pointer, down to up, under 10 px of travel counts as a tap, so a scroll on a phone
never pins, and a touch tap fires once (the canvas ignores click). A touch gets a wider hit radius than a
pointer; the hover radius is as before.
Verified with real mouse, touch and key input through CDP on the cached headless Chromium against the local
page fed by igneum.network/api/live: 20 of 20 checks at 1200 px and 375 px, no console errors.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Pages
- site/miner.html (/miner): hero with the live dashboard, "Hash, prove, get paid", every feature in six groups with one
line each (one click and GPU detection, one client with identities and the hourly swap table, signed updates at a safe
moment, variant racing / fleet tuning / efficiency sweep / latency / remote signed jobs, watchdog and clock check with
the recoveries table, the log and the bench table), "Why Igneum Ember stays ahead" (the six levers of 4 Oct 2026 with
their measured state; the latency row labelled approximate, from the 0.3.6 plan), the dev fee section with the exact
wording of docs/design/miner-dev-fee.md, Get the miner. Every number links to its /bench entry.
- site/wallet.html (/wallet): hero with the wallet window, the three finality states with the verified-final transaction,
the four checks the wallet makes, features (create or import with Argon2id + XChaCha20-Poly1305, send with the fee
shown, QR drawn locally, history with rewards, node source order, MetaMask export), the timed first run on a test
network (5 Oct 2026, wallet-v1 log entry), Get the wallet.
- site/index.html: the miner and wallet sections become summaries, each with a framed screenshot, pills and a Read more
link; #mine and #wallet anchors kept.
- site/partials/nav.html: Miner and Wallet entries, the CTA to /miner#get; the Miners entry goes (the bench page is
linked from /miner, the footer and the Miner entry marks it current). The bar needs 941 px for eight items on one
line, so the menu now applies up to 940 px (head.html) and labels never wrap.
- site/partials/footer.html: a Run column (the miner, the wallet, the GPU bench table, the dev fee).
- site/build.mjs: PRODUCT table, the one place the miner's name lives (full "Igneum Ember", name "Ember", app "Igneum
Miner" for the bundle and window, caption for screenshots); every <span data-product> is stamped at build. miner.html
and wallet.html registered; /miners marks the Miner nav entry; journey entries lose a leading comma left by a
stripped bracket.
Visuals (site/img, WebP, 2x, under 101 KB each)
- miner-dashboard.webp: real screenshot of the miner app on this Mac (live devnet, Apple M5 Max), footer with the host
name and the address cropped, the machine id removed before capture.
- wallet-home.webp and wallet-final.webp: real screenshots of Igneum Wallet v1 (release build from wallet-v1) on a
private test network driven by tools/wallet-testnet/run.mjs; the throwaway addresses are replaced by example strings.
- Drawn in CSS: the device frames, the three finality states, the hash / prove / get paid steps, the dev-fee switch.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
the project lead, 5 October 2026: "why is it taking so long for pc2 and pc1s tasks to spin up?". The PCs have no inbound ports
and one miner is off the LAN, so one thread per app now long-polls the relay's public /wake with the last stamp
(GET <url>?since=<stamp>, held up to 45 s there). A changed stamp sends Event::Wake and the engine fetches the jobs
file at once (signature check unchanged); a wake during a fetch in flight fetches again right after it. The first
reply only seeds the stamp. Backoff 5, 15, then 60 s while the relay is unreachable, a 10 s floor between requests,
a full hold when the relay has no stamp yet: never a busy loop. One log line per wake, one when it falls back, one
on recovery. IGNEUM_APP_JOBS_WAKE_URL overrides the URL (set and empty: no waker).
CHECK_EVERY_S 600 -> 120: the poll is the fallback now; the first poll stays 40 to 60 s after start. An unchanged
file is no longer logged on every poll. Remote jobs off stops the waker too.
Unit tests: the stamp logic (seed, same, changed, empty), the backoff sequence and the recovery flag, the floor,
the URL and query. cargo test -p igneum-app: 60 + 22 pass; cargo build --release -p igneum-app: finished.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
publish-jobs.sh --deploy POSTs the new stamp (published_at plus 8 hex of the file's sha256) and the added id to the
relay's /wake once the live file verifies. The relay token goes in a 600-mode header file, never on the command line
or the screen. Prints "woke the apps (stamp ...)" or a one-line warning; the apps' 2-minute poll still catches it.
tools/jobs.mjs status reads relay_wake (one row per publish with the ids it added) and prints "woken +N s after the
publish" for a machine's latest job that a publish added; nothing when the table does not exist yet.
docs/plans/release-0.3.6.md: "Instant jobs" section with the design, the expected latency and a TODO row per machine
for the measured number once 0.3.6 is live. packaging/ota/README.md: the 10-minute poll is history.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
GET /wake?since=<stamp> is public (the apps hold no token) and rate limited (30 a minute per IP). It holds up to
45 s, re-reading the stamp every 2 s, and answers {stamp, at, added, changed, held_ms} the moment the stored stamp
differs from since, else the unchanged stamp at the deadline. POST /r/<token>/wake {stamp, added} (the relay's
auth, also x-relay-token or x-igneum-key on /wake) records a stamp; one row per stamp in relay_wake, created by the
first POST. maxDuration 60 s for api/wake.mjs in vercel.json. api/relay.mjs is untouched.
The handler lives in lib/wake.mjs with its dependencies injected; relay/test/wake.test.mjs drives it with a fake
database, a fake clock and a fake sleep (the hold, the change, the deadline, the rate limit, the hold cap, auth, a
database error). CI's site job runs it with the other relay tests.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The first PC build (job build-20261005-075300) failed in 52 s: the node's crates depend on ../../../../igneum-pow,
which the zip did not carry, and the engine embeds brand/igneum-coin-1024.png, which the staged brand/ lacked.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
s8-steady.mjs: two nodes, one honest vmine miner at 1 block/s, no flood,
RSS and cache-build count every 60 s, vmmap -summary at 0, 500, 1,000 and
1,500 blocks. Both builds ran 1,500 blocks on the 60x profile: before
41 to 1,342 MB by 514 blocks (9 cache builds, five 256 MiB chunks resident:
KEEP 4 plus one evicted chunk the allocator keeps) then flat, 27 builds in
1,529 blocks; after 319 MB at 510 blocks (1 build), 589 at 1,029 (the second
day's cache, by design), 603 at 1,526, 2 builds. Residual 30 MB per 1,000
blocks on both builds, read as the consensus database and caches filling,
not the PoW cache. JSON and vmmap files under
docs/benchmarks/memory-floods-2026-10-04/.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
s6 +6/+3/+1 MB per load, s7 302 to 318 MB, 0 cache builds, epochs 0 to 3
rolled, 202 blocks accepted; the pass-1 column stays beside it. Result JSON
after-{s6-exhaustion,s7-flood}.json added. The s6 one-instant sink check is
noted as a harness flake.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Report docs/review/redteam-2026-10-04.md: finality attacks s1-s8 plus 34% withholding, 50/50 long partition, F23 and
F24 custom runs, ordering harness, execution suite and EVM smoke, proving hostile tests and a proof flood, difficulty v2
timestamp forging in the simulator. New fails: the fast-time harnesses corrupt the u64::MAX sentinels of the override
(F25), a block or transaction flood grows the node by hundreds of MB in a minute (M30), the coinbase does not fit the
204-byte limit on mainnet, testnet and simnet parameters (M31). F23 and F24 reproduced on this build; F21's bound
measured at one window of the side's own DAA. Scenario scripts under tools/finality-attacks/redteam/.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
tools/harness: IGNEUM_HARNESS_BASE_PORT and IGNEUM_HARNESS_TMP move the test
network's ports and data directory so two agents can run it at once; the u64
sentinel round-trip in overrideParams is fixed with the BigInt reviver from
tools/finality-attacks (ledger F25); s6 records rss_start, rss_delta and
cache_builds per load and reports per-load growth (the old row subtracted one
baseline taken before all three loads, which is how the mempool flood was
read as +270 MB); s7 counts "PoW cache built" lines beside every RSS sample;
--live-only skips the s7 simulator part.
docs/bench-log.md: the 4 October 2026 (night) entry: the floods' growth was
one 256 MiB PoW cache per epoch roll (the engine kept a cache per (epoch,
day) pair, KEEP 4), measured before and after the fork fix (fork branch
fud-memory, 796f758d): submit load +263/+257 MB with 1/1 builds before,
+9/+2 MB with 0/0 after; block flood 302 to 1,085 MB with 3/3 builds before,
300 to 315 MB with 0/0 after. Result JSON under
docs/benchmarks/memory-floods-2026-10-04/.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
attacks.py scenario 2 under rule v2 and Kaspa's DAA: a pulse never earns more blocks per hash than steady mining
(weight per hash 0.26 and 0.98); the economy simulator at the devnet's 124 MH/s; finality_sim scenario A (the
window is full on day 35 to 41 from zero history). The first fast-time s5 attempt failed on an override field the
integration build does not know; the re-run on the finality-fixes build is queued.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
