Computer_Network: SECURECHAT: A Chat App That Makes Encryption Part of the Conversation

A room-based, browser-native E2EE chat built with Next.js and Socket.io, where the UI teaches you how a message becomes unreadable before it ever leaves your browser.

7 min read • View on GitHub • More from Aarya7306

A wide chat interface sits inside a glass-like encryption chamber. On the left, a plaintext message is readable. In the center, it passes through a mechanical cipher lattice. On the right, it emerges as dense hex output while a server tower remains visually separate below the flow. The scene explains that the browser transforms the message before the server can see it. — SECURECHAT turns encryption into a visible step, not a hidden promise.

Key Takeaways

SECURECHAT’s real differentiator is not just end-to-end encryption, but the decision to turn encryption into a visible UI event that users can understand at a glance.
The server coordinates rooms and message relay, but the cryptographic work stays in the browser, which keeps plaintext out of the backend path.
The room name doubles as the shared secret seed, which makes onboarding simple but pushes security quality onto user-chosen entropy.
The project’s cyberpunk styling is not decorative noise, because it reinforces the idea that private computation is happening locally and deliberately.

The Encryption You Can Watch Happen

Most encrypted chat apps treat cryptography like plumbing. SECURECHAT does the opposite. It stages the moment a message turns from readable text into ciphertext, and that choice changes the whole product story.

The point is not just privacy. It is trust, made legible. When the app shows the transformation instead of hiding it behind a lock icon, the user is invited to understand what is being protected and where that protection actually lives.

A close-up machine-like modal shows a plaintext message entering a press labeled with verification and integrity cues, then leaving as ciphertext with a separate authentication tag element. The scene explains how the app makes encryption feel like a deliberate process rather than a silent backend step. — The CryptoModal slows the moment down so the user can see the handoff from plaintext to ciphertext.

SECURECHAT’s Core Promise: The Server Cannot Read the Message

The architecture is straightforward, which is part of the appeal. Next.js renders the app, Socket.io coordinates the room, and the browser performs the cryptography. That separation matters because the server can move messages around without becoming a place where messages are decrypted.

The browser owns the secret. The server only moves packets and keeps rooms organized.

How a Room Name Becomes a Shared Secret

This is the technical heart of the project. The browser takes the room name, hashes it with SHA-256, and uses that result to derive an AES-256-GCM key locally. Encryption and decryption happen entirely on the client, so the server never needs access to the key material that protects the content.

// Simplified from src/lib/crypto.ts
const roomHash = await crypto.subtle.digest(
  'SHA-256',
  new TextEncoder().encode(roomName)
);

const key = await crypto.subtle.importKey(
  'raw',
  roomHash,
  { name: 'AES-GCM' },
  false,
  ['encrypt', 'decrypt']
);

const encrypted = await crypto.subtle.encrypt(
  { name: 'AES-GCM', iv },
  key,
  new TextEncoder().encode(message)
);

That is elegant, but it comes with a sharp edge. The room name is not just a label. It is the shared secret seed. If the room name is weak or guessable, the security model weakens with it.

The design favors zero-friction onboarding. No key exchange ceremony. No public key handoff. You type the room name, and the browser does the rest. The simplicity is the feature, but it is also the tradeoff.

Why the Modal Slows Everything Down

SECURECHAT makes encryption feel real by refusing to make it instant. The 2100 ms delay is not a bug fix for latency. It is part of the lesson. The user watches the app do work, and that visible pause becomes a signal that something important just happened.

Most products try to bury that kind of wait. Here, the wait is the point. It turns a background security primitive into a deliberate ceremony, which makes the app feel more trustworthy even before a user knows the implementation details.

The Security Tradeoff Hiding in Plain Sight

App model	Where encryption happens	Who can read messages	How users join	Main tradeoff
Typical centralized chat	Often on the server or not end-to-end at all	The platform can usually inspect or retain content	Email, account, or invite link	Convenient onboarding, weaker privacy guarantees
Generic encrypted chat	Usually client-side, but hidden from the UI	Only participants with the key	Account, contacts, or explicit key exchange	Better privacy, less visible machinery
SECURECHAT	In the browser with native Web Crypto	Only browsers that derive the shared key	A shared room name	Simple entry, but security depends on room-name entropy

That table is the real argument. SECURECHAT is not trying to win by being the most sophisticated cryptographic protocol in the room. It is trying to make the trust model understandable, and then accept the consequences of that clarity.

A Cyberpunk UI That Actually Matches the Stack

The styling is not random chrome. The HexWaterfall effect, the glow variables, and the motion cues all reinforce the same claim: this is a private system doing technical work locally. The interface does not merely suggest security. It performs it as a visual language.

That coherence matters. When the aesthetic and the architecture point in the same direction, the product feels less like a demo and more like a thesis. SECURECHAT’s design says the private part should be visible enough to earn trust, but not visible enough to expose the secret itself.