A modern, lightweight, and highly secure web forum built with a visual design inspired by Command and Control console aesthetics. This forum utilizes client-side asymmetric cryptography in the browser to ensure that every thread, reply, and vote is digitally signed by its author, implementing a strict non-repudiation security model.
This platform is engineered to defend against common attack vectors and automated registration bots. The system is split into a Zero-Trust client application and a strictly validated REST and WebSocket backend.
Every write operation (thread creation, commenting, or voting) undergoes cryptographic signature verification:
- ECDSA Key Pairs: Users generate an Elliptic Curve Digital Signature Algorithm (ECDSA) key pair using the NIST-approved P-256 curve directly in the browser via the Web Crypto API (
crypto.subtle). - Non-Extractable Keys in IndexedDB: To prevent cross-site scripting (XSS) or browser extensions from stealing the private key, it is committed to a local browser database (
IndexedDB) with the propertyextractable: false. The private key remains inside the browser's cryptographic engine and cannot be read or exported via JavaScript. - Server Verification: The backend does not trust any user-supplied metadata. It imports the user's public key (stored as SPKI) and verifies the ECDSA signature of the exact payload string before saving threads or comments.
- Argon2id Password Hashing: User passwords are secured with the OWASP-recommended Argon2id algorithm (64MB memory cost, time cost 3, parallelism 4). The system employs a "Read-Old, Write-New" rehashing wrapper to automatically and silently upgrade legacy scrypt credentials upon successful login.
To prevent attackers from capturing network requests and replaying them to duplicate posts or votes (Replay Attacks):
- Cryptographic Nonces: Every request requires a unique client-side generated UUIDv4 (
client_nonce) and a microsecond-accurate UTC timestamp (client_timestamp). - Stateful Checks: The server retains a log of all processed nonces. It rejects any request that reuses a nonce or has a timestamp that deviates from the server's time window by more than 5 minutes.
To prevent automated accounts, scrapers, and agentic AIs from registering, a multi-layered check is performed at the registration endpoint:
- Proof-of-Work (PoW) Challenge: Before submitting a registration, the client must solve a CPU-bound hashing challenge. It must find a salt value that, when concatenated with the server-supplied challenge string, yields a SHA-256 hash starting with 4 leading hexadecimal zeroes. This increases the CPU cost of bulk registrations, acting as a silent background bot check.
- Invisible Decoy CAPTCHA (Honeypot): Visual CAPTCHA challenges are permanently hidden from humans. The
captcha-inputfield is moved off-screen, acting as an invisible decoy. Bots scanning the HTML will attempt to fill it out (which triggers immediate registration rejection), while human users leave it blank, bypassing visual verification entirely. - Honeypot Decoy: Multiple dynamic honeypot fields (
Middle Name,Email Confirm, etc.) are rendered off-screen with random classes. Automated scrapers fill these fields, causing the server to reject the registration request.
Commanders have advanced, quiet moderation capabilities:
- Shadowbanning: Users marked as shadowbanned can still browse, write posts, and see their own content. However, the server dynamically alters
GET /api/threadsandGET /api/threads/:id/repliesqueries to filter out their threads and replies for everyone else on the network. - Atomic Purges: Executing a user purge initiates an ACID transaction in SQLite, immediately terminating all WebSocket connections, deleting active sessions, and wiping out all threads, comments, and votes associated with the user across the database cascade.
- Payload Size Limitation: The WebSocket server restricts the handshake and message buffer (
maxHttpBufferSize) to a maximum of 5KB, preventing memory exhaustion (DoS) from oversized payloads. - Rate Limiters: REST write operations are throttled using custom rate limiters that persist hits in a dedicated database table.
server.js: Express web server, REST endpoints, WAL-mode SQLite database persistence, and Socket.io WebSocket engine.server/captcha.js: Vector path calculation, SVG rendering, and Proof-of-Work verification module.public/app.js: Frontend application state, Web Crypto P-256 engine, IndexedDB keystore, and History API SPA router.public/index.html: Shell layout for the dark terminal aesthetic.public/index.css: UI stylesheets.setup.js: CLI tool for initializing administrative accounts (COMMANDER role).
-
Install Dependencies:
npm install
-
Provision Administrative Account: Because admin/commander accounts cannot be registered from the public web interface, you must configure the initial credentials locally:
node setup.js --init-commander
Follow the prompts to configure your username and access key.
-
Start Web Server:
npm start
Alternatively, to start the application with automated Cloudflare tunnel integration, run:
.\deploy.bat -
Access: Open
http://localhost:3000(or the public tunnel address) in the browser.
This project contains infrastructure-as-code for zero-configuration deployments on Render:
- Navigate to Blueprints on your Render dashboard.
- Connect your Git repository.
- Render will parse the
render.yamlconfiguration:- Creates a Node.js Web Service.
- Attaches a Persistent Disk (1GB) mapped to
/datato persist your SQLite database across deploys. - Generates a cryptographically strong
TOTP_PEPPERenvironment variable.
- Launch the deploy. The project will compile native dependencies (like
argon2) automatically.
GNU General Public License v3.0 (GPLv3) — See LICENSE.
This project is Free Software: it can be redistributed and/or modified under the terms of the GNU GPLv3 as published by the Free Software Foundation.
Developed by Eduardo "Noir0x63" Camarillo noir0x63.github.io