Vroom Technical Documentation
Architecture, Requirements, and Workflow
Project Overview
Introduction:
Vroom is a lightweight, privacy-focused chat application built for smooth and secure communication without requiring personal information, login, or signup. It focuses on providing users with a quick and private way to chat without leaving behind any digital identity.Temporary Virtual Rooms:
Vroom operates through temporary virtual rooms, which serve as private spaces for real-time message exchange. Each room is created dynamically and exists only during the communication session. Once the conversation ends or participants close the chat tab, the room and all associated data are permanently deleted, ensuring complete privacy and data anonymity.Security and Encryption:
All communication within Vroom follows the End-to-End Encryption (E2E) standard. This ensures that messages are encrypted on the sender’s side and decrypted only by the receiver. The server cannot access or view any message content, guaranteeing total confidentiality between participants.Real-Time Communication:
Vroom uses Socket.IO for establishing real-time bidirectional connections between users. This enables instant message delivery with minimal latency and ensures that all users in a room stay synchronized without page reloads.Scalability with Redis Pub/Sub:
To handle multiple rooms and servers efficiently, Vroom integrates Redis Pub/Sub architecture. Redis acts as a message broker that distributes messages across multiple WebSocket servers. This allows users connected to different servers to communicate seamlessly while keeping their rooms isolated from others.Focus on Privacy and Simplicity:
Unlike conventional chat platforms that rely on persistent user accounts or stored chat logs, Vroom prioritizes simplicity and privacy. By automatically deleting all data after communication ends, it ensures there is no digital footprint, providing users with a secure, anonymous, and hassle-free chatting experience.Requirements
Landing page with project intro, create room, join room options.
Temporary virtual rooms for communication.
No login/signup required.
Rooms can be joined via link or code.
Auto-termination of rooms after use.
Specifications
No Personal Info
Complete anonymity for all users
End-to-End Encryption
Secure E2E encrypted messages
Credential-Based Rooms
Illusion of duplicate rooms using credentials
Auto Data Deletion
Automated deletion after room termination
Session-Based Rooms
Room expires when tab is closed
Tech Stack
Next.js
Frontend & backend
Socket.IO
WebSocket connections
Express
Socket handling
Redis
Message broker & temporary data store
Workflow Diagram
Workflow of room creation, joining, and messaging
Workflow Steps:
User creates or joins a room using a unique Room ID and Passkey
WebSocket server validates credentials against Redis
Upon validation, user socket joins the virtual room
Messages sent by users are broadcasted to all sockets in the room
Redis Pub/Sub ensures messages reach users on different servers
Room and messages are deleted when all users disconnect
WebSocket Architecture
The WebSocket architecture coordinates room creation, joining, and validation through a distributed system of socket servers and Redis.
Key Concept: Each socket connection can be treated as a virtual room, with multiple sockets grouped under a shared Room ID for multi-user conversations.
- Redis stores room credentials and validates incoming connections
- Multiple WebSocket servers can handle different users in the same room
- Socket.IO rooms provide logical grouping of connections
- Redis ensures consistency across distributed WebSocket servers
Message Flow Architecture
Same WebSocket Server
When users are connected to the same WebSocket server, messages are delivered directly through Socket.IO's room broadcasting mechanism. This provides low-latency, real-time communication without external dependencies.
Different WebSocket Servers
When users are on different WebSocket servers, Redis Pub/Sub acts as a message broker. The sending server publishes messages to Redis, which broadcasts them to all subscribed servers. Each server then delivers the message to its connected clients in that room.
Key Takeaways
Temporary & Private
Encrypted chat system with no data persistence
Scalable Design
Redis Pub/Sub enables horizontal scaling
Zero Data Storage
Ensures complete privacy and compliance
Virtual Room Architecture
Each socket is a virtual room, grouped by IDs