altcha

ALTCHA is an open-source, self-hosted CAPTCHA alternative distributed as a Web Component (<altcha-widget>) that verifies visitors are human through a Proof-of-Work (PoW) challenge instead of image puzzles, cookies, or device fingerprinting. The widget solves the challenge locally using Web Workers running one of several hash algorithms (PBKDF2, SHA, Argon2, Scrypt), then submits a signed payload your server verifies with a companion library.

Because verification runs entirely client-side against a server-issued, HMAC-signed challenge, ALTCHA needs no API keys, no third-party service dependency, and collects no personal data — making it GDPR, HIPAA, and WCAG 2.2 AA compliant out of the box. It ships pre-built server-side libraries in ten languages, framework starters for React, Vue, Svelte, Solid, Lit, and Angular, and supports pluggable code challenges, data obfuscation, and full theming for teams that need more than a basic checkbox.

What You Get

• <altcha-widget> Web Component - a drop-in custom element that works with any frontend stack via a single import 'altcha'.
• Multiple PoW algorithms - PBKDF2 and SHA bundled by default, with separately-importable Argon2 and Scrypt workers for hardware-resistant, memory-bound verification.
• Ten official server libraries - HMAC challenge creation and solution verification for TypeScript, PHP, Go, Python, Java, Ruby, Elixir, Rust, Dart, and C++.
• Built-in accessibility fallback - an image/audio ‘enter the code’ challenge for cases where PoW alone isn’t sufficient, meeting WCAG 2.2 AA.
• Plugin system - a BasePlugin hook chain (onFetchChallenge, onRequestServerVerification, onVerify) plus a shipped data-obfuscation plugin for hiding content like email addresses until verification.

Common Use Cases

• Signup and contact forms - block scripted form spam without adding user friction or third-party trackers.
• Regulated industries - GDPR/HIPAA/CCPA-bound products that can’t send visitor data to a third-party CAPTCHA vendor.
• Public APIs and comment sections - throttle automated abuse behind a lightweight, self-hosted challenge instead of rate-limiting alone.
• Accessible government/enterprise sites - meet WCAG 2.2 AA and European Accessibility Act requirements with the audio/image code-challenge fallback.

Under The Hood

Architecture The core is a single Svelte 5 custom-element component (Widget.svelte, ~1,370 lines) organized into clearly commented sections — props, reactive/derived state, effects, lifecycle, plugin system, challenge handling, DOM helpers, event handlers, server communication, and public API. It composes small presentational Svelte components (Checkbox, Switch, Code, Popover, Footer, Logo) and delegates the PoW math to a separate pow.ts module shared between the browser workers and the server-side libraries. Verification is orchestrated as challenge fetch → worker-based solve (solveChallengeWorkers races N workers and retries with fewer on out-of-memory) → payload encode → optional code-challenge/server-verify → event dispatch, with a BasePlugin hook chain as the extension point instead of subclassing. A single global $altcha namespace (defaults, algorithm registry, i18n store, plugins, instances) is shared by every widget instance on the page, which is a deliberate cross-instance mechanism but also a structural coupling point.

Tech Stack TypeScript and Svelte 5 (runes-based: $state/$derived/$effect/$props/$host), compiled to a framework-agnostic custom element via @sveltejs/vite-plugin-svelte. Multiple dedicated Vite configs build separate bundles (main, external, i18n, plugins, themes, lib), with dts-bundle-generator producing standalone type declarations. Styling uses Sass; the only runtime dependency is hash-wasm, used for the Argon2/Scrypt workers, with everything else built on the native Web Crypto API. Testing runs on Vitest for units and a separate Playwright-driven config for end-to-end tests; CI (GitHub Actions) runs both on every push to main.

Code Quality Tests are substantive and specific — dedicated suites for the PoW core, helpers, server-signature verification, the obfuscation plugin, and each hash algorithm — using concrete input/output assertions rather than snapshot-only checks. Error handling favors explicit, descriptive thrown errors over silent failure, and the verification flow centralizes catch/log/state-transition logic in one place. The codebase is unusually well-commented, with JSDoc-style blocks explaining intent (not just mechanics) above nearly every function and state variable. Type safety is strong, with a dedicated types module, enums, and satisfies-based literal checks. Linting relies on Prettier only (no ESLint), with svelte-check and tsc run as a separate check script.

API Design The public surface is a single custom element configurable via plain HTML attributes for the common path, with a .configure() method and global defaults object for anything too complex to express as an attribute (functions, custom workers). Algorithm and plugin registration follow one consistent pattern, so extending either uses the same mental model. Getting started requires only an install, one import, and one HTML tag, and ten companion server libraries plus six framework starter repos substantially lower cross-stack integration friction — though it does mean the full DX story is spread across many external repos rather than one bundled SDK.