HeyStrangr
HeyStrangr
HeyStrangr is a real-time random video chat platform built for adults, in the spirit of Omegle and Chatroulette but with a modern, security-first architecture. Built under the WebBetas label, the platform pairs strangers via live WebRTC video, supports text messaging over peer data channels, and offers three chat modes — Random, Dating, and Speed Vibes. A freemium model gates premium features (gender/age/location filters, Dating Mode, beauty filters, read receipts, saved matches) behind Starter and Flame/VIP tiers, with plan state always validated server-side and never trusted from localStorage. An integrated live admin monitor lets moderators observe active rooms in real time, with passive AI-assisted reporting powered by a self-hosted Ollama instance. Stack: Node.js · Express · WebSocket · WebRTC · PostgreSQL · nginx · Vanilla JS
-
Domain - heystrangr.com
-
Year - 2026
-
Type - WebApp
-
Industry - Technology
Challenge
The core challenge was building a reliable, abuse-resistant real-time video platform without a framework safety net. Several problems compounded each other: nginx serves static files directly, bypassing Node entirely, which ruled out server-side injection of any dynamic content into HTML or JS files. Plan state had to be validated on every request without ever trusting the client, yet the frontend is purely static — so a careful promise-gating pattern was needed to delay all feature checks until the server confirmed the user's plan. WebRTC signaling had to handle not just 1-on-1 peer connections but also admin observation slots, group rooms, and ICE routing across all three — and an early architectural mistake (storing admins in a Set instead of a Map keyed by slot) caused silent ICE routing failures that were difficult to diagnose. On top of that, third-party ad js scripts reinitialise on every call, causing race conditions and visual glitches whenever the chat reconnected and ad containers were rebuilt.
Solution
Each problem was solved at the right layer rather than patched at the symptom. Plan validation uses a _planReady Promise initialized to 'free' in memory and resolved exclusively by the /api/auth/me server response — a planReady DOM event then fires reactively, gating every requirePlan() call. The signaling server's admin registry was refactored from a Set to a Map keyed by watch slot (user/stranger), giving ICE candidates and offer/answer messages a precise routing target. Ad instability was addressed by a shared loadAdIntoIframe() helper that clears the container, creates a fresh about:blank iframe, and writes the ad network code inside onload — preventing js from reinitialising against a stale DOM. Mobile vs. desktop ad units are swapped at runtime based on viewport width. Throughout, the frontend remained vanilla JS with no build step, keeping deployment friction near zero while nginx handles all static asset delivery at the edge.
- ⌘ It is a long established fact that a reader will distracted by the readable content of a page when looking an its readable ⌘
- ⌘ It is a long established fact that a reader will distracted by the readable content of a page when looking an its readable ⌘
- ⌘ It is a long established fact that a reader will distracted by the readable content of a page when looking an its readable ⌘
- ⌘ It is a long established fact that a reader will distracted by the readable content of a page when looking an its readable ⌘