Hard-Chat: browser-based E2EE peer-to-peer chat that stores nothing and runs serverless

Hard-Chat, an open-source project by the Hardlint Cybersecurity Team that surfaced on the front page of Hacker News, gives two people a way to chat over an encrypted, direct peer-to-peer link with no backend relaying messages, no accounts, and no stored history. Despite the terminal styling — the app presents itself as a retro command-line interface called Zero-Trace Terminal — it is a static web page: plain HTML, CSS and JavaScript hosted on GitHub Pages, running entirely in each user's browser.

Establishing the connection

One user initializes a room, which generates a 100-character Room Key using the browser's cryptographically secure random number generator (crypto.getRandomValues, deliberately chosen over Math.random, which is unsuitable for cryptography). The key draws from letters, digits and symbols to maximize entropy. It must then be shared with the other party out of band — in person, over a voice call, or via another encrypted channel. The second user pastes it in, and both browsers derive the same two values from it: an encryption key, and a short identifier used only so the peers can find each other.

Finding each other is the one step that involves third-party infrastructure. According to the project's documentation, signaling runs through the public PeerJS cloud broker: both sides hash the Room Key and register or connect under the resulting identifier, letting the broker introduce them. The broker never carries message content, which travels over a separate WebRTC DataChannel once the peers are connected.

To get through NATs and firewalls, the app configures 18 STUN and TURN servers in priority order — a dedicated Metered.ca TURN service with its own credentials first, followed by public fallbacks from Google, Cloudflare, Twilio, OpenRelay and others. TURN relaying kicks in only when a direct connection cannot be established. If no link forms within 120 seconds, the session expires and the Room Key becomes invalid, which prevents a key from sitting registered on the public broker indefinitely.

The encryption model

Both sides derive a 256-bit AES-GCM key from the Room Key using PBKDF2 with 100,000 iterations of SHA-256. Every message is individually encrypted with a fresh random 12-byte IV, which is prepended in the clear to the ciphertext before being sent as a byte array. Because GCM includes an authentication tag, any tampering in transit produces a visible decryption error rather than silently corrupted plaintext.

One design choice stands out: the PBKDF2 salt is hardcoded and identical across all sessions. The project defends this by arguing that a fixed salt only weakens security in scenarios involving weak, reused passwords — and a 100-character random key does not fit that scenario.

Nothing is written to disk

Everything lives in memory. The Room Key and the derived encryption key sit only in JavaScript variables, messages exist only in the live page and RAM, and the app uses no cookies, localStorage or IndexedDB at all. A Panic Purge button instantly wipes keys, connection state and the visible chat log; closing the tab accomplishes the same thing.

There are practical requirements. The page must be served over HTTPS because the Web Crypto API and WebRTC demand a secure context — opening it as a local file will not work. Both parties need the page open at the same time during the connection attempt, and the 100-character key must be copied exactly, with no extra characters or whitespace.

What it does not protect

The documentation is candid about limits. The tool protects the content of conversations, not who is connecting: it offers no network-level anonymity, and the team strongly recommends a VPN on both devices. There is no cryptographic verification of who is on the other end — anyone holding the Room Key can join. And there is no forward secrecy across sessions if a key were reused, though the normal flow generates a fresh key each time. The project is distributed for educational and security research purposes rather than as a guarantee for sensitive communications.

Why it matters

Hard-Chat is a compact demonstration of how far browser platform APIs have come: a single static page can deliver serverless, end-to-end encrypted communication that leaves nothing behind when the tab closes. Its ephemeral-by-default design contrasts sharply with mainstream messengers, which typically retain message archives, accounts and metadata.

At the same time, the project's own caveats are the more instructive part. A shared-secret model, a public signaling broker, and TURN relays that can observe traffic patterns mean zero-trace applies to message content, not to the existence of a conversation. For privacy-focused users, tools like this are genuinely useful — but, as the developers themselves state, the threat model deserves a careful read before trusting it with anything sensitive.