https://api.tangled.org/xrpc/org.tangled.temp.git.getBlob?repo=did%3Aplc%3Apomgtubhgnuew7wmpwgk7dzd&path=CloudronVersions.json
Description
HeCAPTe provides a stateless spam-prevention mechanism that respects user privacy. Unlike traditional CAPTCHAs that rely on tracking user behavior or forcing users to complete busywork, HeCAPTe requires the user’s system to solve a computational puzzle (Equihash). This “Proof-of-Work” approach makes it computationally expensive for bots to generate mass requests while remaining quick for legitimate human users on modern devices.
- Humane: Requires no additional human interaction and presents no impediment to accessibility. Doesn’t try to extract value from the user by having them train image recognition models. Doesn’t infuriate vision-impaired users with audio from the first prototype of the telephone.
- Embeddable: Requires nothing more than one small Go binary, a few static files (including the .wasm solver), and an SQLite database. Even the cheapest VPS can run it without a hitch.
- Cost-Asymmetric: Expensive to solve, cheap to verify.
- Proof-of-work: HeCAPTe uses Equihash, a memory-hard proof-of-work algorithm. Unlike simple SHA256-based puzzles, Equihash’s memory requirements make it significantly more costly to solve at scale.
- Turing exam: Not quite a Turing test. Any one user submission is not, as per the original CAPTCHA vision, “proof” of humanity—but in a world with advanced OCR, services that have underpaid laborers type in answers for fractions of a penny, and even tiny local AI models that can easily solve most natural language puzzles, that vision is likely dead anyway.
Don’t try to barricade the way for bots and stop humans along the way; just make it more expensive to spam you than they could possibly get back as profit.
Recent Changes
Security and correctness fixes across the admin surface. Every admin request body is capped at 64 KiB before the CSRF check parses it, which closes an unauthenticated memory and temp-file amplification on the passkey login routes. The first-run admin password is now claimed with one atomic database write, so two processes sharing one database cannot both take the admin account. A passkey ceremony session is consumed in a single statement, so one token cannot drive two ceremonies. The security preset and the Equihash parameters it selects are read and written as one snapshot, so a torn write cannot weaken the difficulty below what the dashboard shows. A failing passkey user-ID write now reports an error at the start of the ceremony instead of a generic failure later. Documentation now states that only the module handshake is enforced, and that the worker capability struct is not read by the server. In-flight challenges remain valid, and no configuration changes are needed after the update.