Hard-Chat implements serverless P2P terminal chat with RAM-only ephemeral messaging

Hard-Chat demonstrates a minimalist approach to secure communication by leveraging WebRTC’s peer-to-peer capabilities. The absence of servers or accounts removes traditional attack surfaces like centralized data stores or authentication systems. Instead, the entire system relies on a single 100-character Room Key, exchanged manually, to derive encryption keys and establish a direct connection. This design prioritizes ephemerality and simplicity but shifts the burden of key distribution to the users, who must transmit the Room Key through a separate, trusted channel. The lack of persistence means no history is recoverable, which may suit high-risk scenarios but complicates usability for routine communication.

The technical constraints are non-trivial. Both parties must have the app open simultaneously during connection attempts, and the Room Key must be copied verbatim, errors or delays beyond two minutes invalidate the session. HTTPS is mandatory, ruling out local file execution, and browser support is limited to those with WebRTC and Web Crypto API compatibility. NAT traversal is handled via 18 STUN/TURN servers, but restrictive networks (e.g., corporate firewalls) may still block connections. The fixed PBKDF2 salt, while acceptable given the Room Key’s high entropy, diverges from best practices for password-based key derivation, though the risk is mitigated by the key’s length and randomness.

Security guarantees are narrowly scoped. End-to-end encryption protects message content, but metadata, such as IP addresses exposed during signaling or WebRTC negotiation, remains visible to intermediaries. The project explicitly disclaims network-level anonymity, recommending a VPN for sensitive use cases. The reliance on PeerJS for signaling introduces a single point of failure: if the public broker is unavailable or compromised, connections cannot be established. The Panic Purge feature offers a quick escape, but its effectiveness depends on user action, closing the tab is the only foolproof way to ensure data erasure. These limitations make Hard-Chat unsuitable for high-stakes scenarios without additional safeguards.

For engineers, the project serves as a proof-of-concept for serverless, ephemeral communication. Its static architecture simplifies deployment (e.g., via GitHub Pages) but sacrifices features like message history or offline delivery. The trade-offs, no persistence, no accounts, no backend, are deliberate, targeting use cases where operational simplicity outweighs convenience. The codebase, being open and static, invites audit and modification, though the lack of a proprietary backend means no updates or patches will be pushed automatically. The reliance on WebRTC and modern browser APIs ensures broad compatibility but ties the tool’s viability to the evolution of those standards.