The Internet Throne

The Internet Throne is a persistent, real-time, global competitive platform centered around a single, scarce digital status object: The Throne.

• At any given second in time, exactly one person rules the internet. • Any visitor (guest or registered user) can step up and challenge the sitting King or Queen to a real-time, skill-based mini-game (Typing, Reaction Speed, or Memory). • If the Challenger wins, the incumbent ruler is instantly dethroned, the Challenger is crowned, and the event is broadcast globally in real time. • If the Defender prevails, their defense count increments, their reign continues, and their legacy grows. • Every reign, defense, score, and dethroning is archived forever into the Hall of Kings.

Core psychological pillars center on absolute scarcity (one global throne that cannot be duplicated or split), skill-based legitimacy (power earned strictly through human skill, zero pay-to-win), immediate curiosity ("Who rules the internet right now?"), and permanent historical immortality.

The persistence layer is modeled in MongoDB using multi-document ACID transactions:

• thrones Collection (Singleton Document): _id: "global", state (OCCUPIED, VACANT, MAINTENANCE), currentRulerId, currentReignId, activeBattleId (mutex lock for ongoing battles), defenseCount, bountyPoints, seasonId, and version (CAS lock counter). • reigns Collection (Immutable Reign Archive): _id, throneId, rulerId, rulerType (user | guest), startedAt, endedAt, endReason (DETHRONED | ADMIN | MAINTENANCE_RESET), defenseCount snapshot, bountyPointsSnapshot, and endedByBattleId. • battles Collection (Battle State Engine): _id, target, challengeType (typing | reaction | memory), state (CREATED through COMPLETED/CANCELLED/DISPUTED), challengerId, defenderId, throneVersionAtCreate, cryptographic seeds, participant submissions/scores, outcome, and server-enforced playDeadlineAt. • Supporting Collections: users (credentials & OAuth bindings), guest_identities (cookie-hashed sessions), profiles, audit_logs (security and anti-cheat trail), creator_thrones, and world_kingdoms.

Throne state transitions are governed by strict mathematical and concurrency rules:

• TR-010 (Cardinality): Exactly one global Throne singleton document (_id: "global"). • TR-040 (Concurrency & Single-Contender Lock): At most one active Throne Battle can occur at any time. Any concurrent challenge requests receive 409 CONFLICT ("Throne is Contested"). • TR-050 (Cooldowns): After a battle completes, the challenger must wait 60,000ms before challenging the same ruler again. • TR-070 (Defense Count): Increments atomically by +1 on each successful defense; resets to 0 when a new ruler takes the Throne. • TR-080 (Bounty Prestige): Bounty Points = ⌊Reign Duration (ms) / 60000⌋ + (Defense Count × 10). • TR-090 (Defender Fatigue Tier): Fatigue Tier = min(3, ⌊Defense Count / 5⌋), adding +15s challenger cooldown per tier to prevent monarch burnout. • TR-120 (Incumbent Advantage in Ties): If challenger and defender post identical validated scores, the Defender wins. • TR-160 (Atomic Dethroning): Crown handoff occurs in a single multi-document ACID transaction verifying expected version.

A multi-layered defense shield ensures competitive integrity:

• Cryptographic Challenge Nonces: Seeds and stimulus sequences are generated server-side during the STARTING countdown and emitted exclusively to active participants. • Physics & Biometrics Sanity Checks: Input velocities (WPM < 250, Reaction Time > 80ms) are validated to eliminate bots and macros. • Deterministic Re-Simulation: Server re-executes player inputs against the puzzle rules to verify claimed scores. • Server-Enforced Timeouts: Strict playDeadlineAt timestamps prevent offline manipulation. • Rate-Limiting & Dispute Isolation: Token bucket rate limiters protect API gates, while suspicious runs are routed to DISPUTED status for audit. • Resilient Fallback: If Ably WebSocket connectivity drops, clients automatically fall back to REST polling (/api/v1/throne).

The platform features a frictionless user onboarding and progression model:

• Dual Identity: Players can jump directly into battles as Guests via cookie-hashed sessions. Upon registration or OAuth sign-in (GitHub, Google, Discord via Auth.js), players can merge their full match history, reign archives, defense tallies, and trophies into a permanent verified account. • Product Roadmap: - Phase 1 (MVP Core — Complete): Single Throne architecture, 3 mini-game disciplines, CAS concurrency locks, Ably real-time broadcast mesh, and guest identity flow. - Phase 2 (Growth & Community): Hall of Kings historical viewer, Profile claiming, Achievements, and automated seasonal soft resets. - Phase 3 (Creator & Scale): Creator custom thrones, regional territory conquest (World Map), and cosmetic throne customizations.

The codebase enforces comprehensive quality gates across all layers:

• Vitest: Unit tests for domain state machine transitions, CAS version counters, fatigue tier math, and anti-cheat verification. • Integration Tests: Repository transactions verifying atomic MongoDB multi-document commits during simultaneous challenge requests. • Playwright: End-to-end multi-browser test suites simulating concurrent challenger queues, real-time battle play, and dethroning broadcasts.

Shipped a production-grade high-concurrency competitive platform featuring sub-100ms real-time battle distribution, zero-collision CAS state transitions, and permanent historical reign archives.