2.80.1 2026-10-05
Two bugs in yesterday's proof-of-work work, both reported from use rather than caught by a test. Both are fixed, and both now have a test that fails without the fix. The form refused every normal submission. The widget starts solving when the form is focused. No POST, no enquiry, no ticket. It now starts the solve only when the widget is idle, and otherwise waits for the one already running. Why no test caught it: the end-to-end test used a cheap challenge, which finishes solving before the button is pressed, so the race never happened. The new test uses a deliberately expensive one and submits while the solve is still running. The verification box was unreadable on the dark theme. altcha 3.x renamed its CSS custom properties and our stylesheet still set the 2.x names. A custom property the widget does not read is not an error — it is ignored — so the text colour was never set and the widget drew its own default dark text on our dark card. It rendered, it worked, and on the beta form it looked like nothing was there.
2.80.0 2026-10-05
No ALTCHA Cloud, no Sentinel, no account, no external verifier, no CDN.
- Areas changed
Proof of work on the public forms ALTCHA, run entirely by us, Two fixes found on the way, What changed for visitors
2.79.7 2026-09-28
The copy is two sentences rather than one: "reload the page or email us" reads as a single choice about reloading.
2.79.6 2026-09-28
Found while verifying 2.79.5's CTA fix with script disabled. Reload the page and try again." Reloading does not bring the script back, so the advice cannot work and the visitor is in a loop with no exit. This was not introduced by 2.79.5, but it matters more because of it: fixing the CTAs is precisely what makes a scriptless visitor reach the form easily, and then find it dead. No address is published yet -- that is waiting on a mailbox somebody actually reads. Setting the registry key is the whole change; the rendering, the escaping and the test for it are in place and both branches were exercised.
2.79.5 2026-09-28
On a phone without JavaScript, clicking the CTA scrolled to the form and then covered it. The nav is open by default in the markup and closed by script, which is the right way round -- a visitor with no script still has a menu -- but the header is sticky and an open menu is 419px of it, so it followed the page down and sat on top of whatever the anchor had just jumped to. The form heading, the intro and the first two fields were all behind it. Screenshotted before and after. The anchor names the form rather than the section. And there is a second CTA, at the foot of the page after the FAQ, because a reader who has got that far should not have to scroll back up to act. The "Apply" step in What happens next is a link to the form for the same reason.
2.79.4 2026-09-26
Shipped in 2.79.3 and caught by looking at the live page: a deadline announced as 31 January rendered as "Applications close on February 1, 2027". The stored value is the boundary — midnight at the start of the following day — because that is what a comparison needs. The page was localising that instant in the reader's browser, and every reader east of the program's timezone, UTC included, sees the next day. A calendar deadline should not go through timezone arithmetic at all. A test pins the case that was wrong: a boundary of 08:00 UTC on 1 February is a deadline of "January 31, 2027".
- Areas changed
A deadline is a day, and the page was showing the wrong one, Applications close on 31 January 2027, without a job to miss