Forum Software on Tor Hidden Service

Different forum platforms have different requirements and operational characteristics. Flarum is a modern PHP-based forum with a clean Vue.js frontend. It requires PHP 8.0+, MySQL/MariaDB, and Composer. Memory footprint: 512 MB RAM minimum, 1 GB comfortable. Flarum's extension system allows adding features (email, social login) but each extension must be audited for clearnet dependencies. Discourse is a Ruby on Rails forum with a heavy resource footprint: 2 GB RAM minimum, with Redis and PostgreSQL required. Discourse's admin interface is feature-rich. On .onion, disable all email transactional features or route SMTP through Tor. phpBB is a traditional PHP forum, the most resource-efficient option. It runs on standard LAMP/LEMP stack with minimal configuration. phpBB lacks modern UI but runs on 256 MB RAM. Lemmy is a federated Reddit-like platform (ActivityPub). Running Lemmy on .onion requires deciding whether to federate (requires clearnet-accessible instance) or run as a closed, non-federated community. For maximum isolation, disable federation entirely. For each platform: disable automatic email notifications if SMTP routing through Tor is not configured, and disable CDN-based assets in themes.

Install Flarum via Composer (PHP dependency manager). Install the LEMP stack: nginx (localhost:80), PHP-FPM 8.1+, MariaDB (localhost:3306). Run the Flarum installer via CLI: composer create-project flarum/flarum . and run the Flarum install wizard. During setup, set the forum URL to http://youronion.onion. After installation, key configuration changes in config.php: ensure 'url' is set to the .onion address. In Admin > Settings: disable email confirmation for new users if email is not configured. Admin > Mail: configure SMTP settings pointing to a Tor-routed SMTP server, or disable email entirely and rely on in-forum notifications only. Flarum's default assets (fonts, icons) are loaded from CDN URLs in some themes - inspect the default theme's source and replace CDN references with local copies. Enable the cache: Flarum supports file-based cache (no Redis required) for small installations. For larger communities, Redis caching (localhost Redis) significantly improves performance. Flarum's URL structure uses slugs which are crawlable by Tor search engines (Ahmia indexes .onion sites).

Forum member management on .onion requires adapting standard practices. Email verification is problematic: requiring email verification for new accounts forces users to use an email service, potentially compromising their anonymity. Options: (1) Disable email verification entirely, open registration without verification. Increases spam/bot registrations but maximizes anonymity. (2) Require registration approval by moderator - new accounts require admin activation. Reduces bot accounts but adds administrative overhead. (3) Implement invite-only registration - existing members send invitation codes. Maintains community quality without email requirement. Username policy: allow pseudonymous usernames without requiring real-name information. Do not collect additional profile information during registration. Implement username uniqueness enforcement (database-level unique constraint) and basic profanity filters for usernames. For user identity on .onion forums, the username IS the identity - no email, no real name, no external account linking. Inform users in the Terms of Service that the forum does not collect identifying information and that they should not post identifying information about themselves or others.

Moderating a Tor hidden service forum presents unique challenges: users are anonymous (no IP bans are effective against Tor users), and ban evasion is trivial (create new account via new Tor circuit). Effective moderation strategies for .onion forums: (1) Account-age-gated posting - new accounts cannot post for 24 hours. Reduces throwaway account spam while allowing legitimate users to join. (2) Moderation queue for new accounts - first N posts from new accounts require moderator approval before appearing publicly. High overhead but filters initial spam. (3) Community flagging - users flag rule-violating content, moderators review flagged content. Scales community moderation without full-time moderators. (4) Content hash fingerprinting - hash post content to detect repeated spam from different accounts even without IP or account correlation. Flarum extension: Flarum-akismet sends posts to Akismet spam service for checking - disable this (it sends content to clearnet). phpBB's built-in moderation tools (banning, post moderation queue) are effective for small communities with active moderators. Discourse has sophisticated automated moderation including new user trust levels.

Forum data backup strategy for .onion deployments. Database backup: all forum content (posts, user accounts, threads) is stored in the database. Schedule nightly dumps: mysqldump forum_database | gzip | gpg -c -o backup-$(date +%Y%m%d).sql.gz.gpg. Transfer encrypted backups to off-server storage via Tor (rsync to a second .onion server, or SFTP to a .onion storage endpoint). File backup: forum attachments, avatars, and theme assets are stored on the filesystem. Include in backup: tar cz /var/www/forum/storage | gpg -c -o storage-backup.tar.gz.gpg. Test restore procedure quarterly: restore backup to a staging server and verify forum functionality. Forum migration between servers: export database, copy filesystem assets, import on new server, update configuration URL if .onion address changes (this requires updating all stored absolute URLs in the database - use SQL search-replace for the .onion hostname). If you maintain the same .onion address (by copying the HiddenServiceDir including private keys), no URL update is needed. Maintaining the same .onion address after migration requires copying the private_key and hostname files from the hidden service directory.