frequently asked things.

The production scripts for browser verification, proof of work, CAPTCHA, and the waiting room are obfuscated because they coordinate systems that protect the site from bots, spam, floods, and other automated abuse. Making their exact control flow trivial to copy would lower the effort needed to automate attacks against a small server.

Normal site scripts—such as the clock, terminal, slideshows, music player, and this FAQ helper—stay readable. The editable security source is readable too; only the copies produced during deployment are obfuscated.

Obfuscation is not encryption and it cannot stop a determined person from studying public JavaScript. No password, CAPTCHA answer, signing key, or final security decision is trusted to these files. The server independently verifies every proof and protected action.

No—not by itself. It is one speed bump against cheaply copying and automating the browser-side flow. Server-side rate limits, bounded queues, expiring challenges, Cloudflare on the clearnet, and the waiting room do the real defensive work.

It makes a browser perform a small, temporary SHA-256 task before receiving a 12-hour pass. One person barely notices it, while a bot trying to create many fresh sessions has to pay the cost repeatedly. It is not cryptocurrency mining, and the proof is checked by the server.

Proof of work limits cheap automation; the CAPTCHA protects higher-impact actions such as posting. A successful CAPTCHA grants one short-lived action rather than permanent trust. Its answer and drag target remain server-side.

The site runs on a Raspberry Pi with finite CPU, memory, and connection capacity. The small first-in, first-out waiting room prevents a traffic spike from making the site unusable for everybody. It supports both the clearnet and the onion mirror.

The onion mirror gives visitors another route to the same site without going through the clearnet tunnel. Browsers that support Onion-Location can advertise it automatically. Clearnet and onion verification sessions remain separate.

The smart cache keeps public assets locally for faster repeat visits, then asks a small manifest endpoint what changed. It refreshes only changed files instead of downloading the entire site again. API and verification requests bypass that cache.