📝 Background & Objective

WikiLounge (powered by The Lounge IRC bouncer) was originally managed entirely via terminal commands (SSH). As the user base grew, manually tracking active users, processing account requests, and monitoring inactivity became unsustainable.

Objective: Build a comprehensive, automated, and secure Unified Web Dashboard from scratch. The system must provide a public-facing portal for volunteer self-service and account requests, alongside a secure administrative backend for moderation and automated lifecycle management. The entire application is hosted on Wikimedia Cloud Services at https://wikilounge.wmcloud.org.

🏗️ Backend Architecture & Automation

The system is built on Node.js/Express and interfaces directly with the local server filesystem and the Wikimedia API.

• Database (admin.db): Transitioned state management to an SQLite database. It maintains structured tables for users (tracking status and inactivity), requests, and an immutable audit_logs system.
• The Lounge CLI Bridge: The Node application uses child_process to execute native The Lounge CLI commands (thelounge add, thelounge reset, thelounge remove) in the background, ensuring dashboard actions directly manipulate the IRC bouncer state.
• Ghost Protocol (syncLoungeUsers): An automated server boot-up script. It scans the Linux ~/.thelounge/users/ directory and compares it to the database. If a user was physically deleted via the terminal, the database automatically marks them as Removed to maintain absolute parity.
• MediaWiki Bot Integration: Authenticates via BotPassword to dispatch automated MediaWiki emails (for delivering temporary credentials) and post Talk Page messages.
• Cron Automation (Inactivity Lifecycle): A daily background job monitors user connection logs:
  • 150 Days Inactive: Triggers an automated warning email and Meta-Wiki talk page notification.
  • 180 Days Inactive: Triggers automatic suspension (disabling server access while safely preserving logs for reactivation).

🖥️ Frontend: Public Portal (User Self-Service)

The public portal is fully responsive, supports a persistent Dark Mode (🌙), and provides a streamlined onboarding and account management experience.

• Unified OAuth: Users log in securely using a single Meta-Wiki OAuth consumer.
• Prerequisite Enforcement: Upon login, the system queries the Meta-Wiki API. If a user has fewer than 500 global edits or has "Email this user" disabled, the account request form is hard-locked with an explanatory error.
• Account Requests: Eligible users can submit desired WikiLounge usernames, IRC Nicks, and Cloaks.
• Dynamic Request Freezing: If a user submits a profile request, the UI dynamically locks their submission columns with a yellow ⏳ Request Pending block to prevent spamming the Admin Inbox.
• User Dashboard & Self-Service:
  • Users can securely change their own server password.
  • Users can request IRC nick/cloak updates, request account renames, and download their chat history logs.
• Wikibreak Module: Users can proactively declare a "Wikibreak" (by days or specific date). This writes a wikibreak_until timestamp to the database, completely bypassing their account for inactivity suspensions until they return.
• Active Directory: A public-facing directory displaying all currently active WikiLounge members and their IRC cloaks.

🛡️ Frontend: Admin Dashboard & Moderation

Access to /admin is strictly gated by OAuth username matching against a hardcoded Admin/Super Admin list.

• Live Metrics: Dynamic Chart.js visualizations tracking Active, Pending Suspensions, Suspended, and Removed users.
• Pending Suspension Filter: A smart UI toggle that only appears when users enter the 150-179 day warning zone. Clicking it instantly hides all healthy users to quickly isolate at-risk accounts.
• One-Click Inbox: Admins review incoming requests. Clicking "Approve" on an account creation automatically:
• Runs thelounge add in the background.
• Generates a secure temporary password.
• Dispatches the credentials to the user via MediaWiki email.
• Logs the action in the System Audit Trail.
• Manual Overrides: Full GUI tools to manually add users, edit profiles, force password resets, and suspend/remove accounts without requiring SSH access.

🔐 Security & Infrastructure

• Rate Limiting: Implemented strict request limits (Max 3 password resets per 24 hours; Max 3 general requests per hour) to prevent abuse.
• Environment Variables: All secrets (OAuth keys, Bot passwords, Session secrets) are isolated in a .env file, loaded securely into PM2 via pm2 restart wikilounge-admin --update-env.
• Session Management: Secure, encrypted local session storage utilizing sessions.db to prevent memory leaks during prolonged server uptimes.

✅ Deployment Status

• Core Node.js/Express server and SQLite database initialized.
• Meta-Wiki OAuth and MediaWiki API integrations completed.
• Public Portal and Admin Inbox tested.
• Cron jobs and syncLoungeUsers protocols verified.
• Deployed to production on WMCS at wikilounge.wmcloud.org.