AnonChat
Experimental end-to-end encrypted realtime messaging platform built during wartime to explore secure peer communication without centralized data storage.
AnonChat started during the war when secure and private communication became far more important than convenience. I wanted to build a messaging platform that minimized trust in the server itself and explored what fully client-controlled communication could look like.
Instead of using Socket.io or other abstractions, I implemented the websocket communication layer manually on both the client and server. This forced me to deeply understand connection management, event routing, callback systems, and realtime synchronization at a much lower level.
One of the most difficult parts of the project was handling persistence entirely on the client side. Since the server intentionally avoided storing messages, IndexedDB became responsible for local state management, synchronization, and recovery without corrupting data flow.
The project also explored end-to-end encryption concepts where messages would be encrypted before leaving the browser, allowing the backend to function only as a relay. While the full encryption pipeline was never completely finished, working through the architecture taught me an enormous amount about cryptography, realtime systems, and frontend state reliability.
Direct websocket-based realtime messaging
Custom client and server websocket architecture
Experimental end-to-end encryption pipeline
Client-side persistent message storage
Database-free relay-oriented backend design
Offline-resistant local synchronization flow
Raw WebSocket Communication Layer
Instead of relying on abstractions like Socket.io, the entire realtime communication layer was implemented directly on top of native WebSockets. Custom client and server classes handled connection state, event dispatching, message routing, and callback synchronization.
End-to-End Encryption Pipeline
The platform was designed around the idea that even the server should not be able to read user messages. Encryption and key exchange logic were handled on the client side, while the backend acted purely as a transport relay between peers.
Client-Side Persistence Architecture
Because the backend intentionally avoided storing user data, message persistence and synchronization had to be managed entirely inside the browser using IndexedDB. A large part of the architecture focused on preventing state corruption and maintaining reliable local reads and writes.
Managing realtime websocket state without higher-level abstractions like Socket.io.
Designing client-side persistence flows without relying on server-side databases.
Handling synchronization between encrypted local state and active peer sessions.
Balancing privacy-focused architecture with practical usability constraints.