Case Study

Chatty

End-to-End Encrypted Peer-to-Peer Messenger

ReactWebRTCSocket.ioWeb Crypto APITailwind CSSTypeScript

The Problem

Engineering Context & Problem Statement

Most modern chat applications store unencrypted or server-decryptable conversation records in centralized cloud databases, exposing private communications to data breaches, surveillance, and unconsented data harvesting.

The Solution

System Architecture & Implementation Strategy

Built Chatty, a client-first, zero-persistence WebRTC messaging application. Users generate RSA-OAEP / AES-GCM key pairs directly inside the browser using the Web Crypto API. Signaling is used strictly for the initial SDP peer handshake; after connection, all data flows through peer-to-peer data channels.

System Pipeline & Data Flow

Pipeline Flow

Client A (Browser Crypto) <-> Ephemeral Signaling Server <-> Client B (Browser Crypto) ==> Direct WebRTC P2P Encrypted Tunnel

Clients establish an ephemeral socket connection to exchange cryptographic public keys and session descriptions (SDP offer/answer). Once WebRTC RTCDataChannel handshakes complete, the signaling server drops the session context, and peers exchange AES-GCM encrypted payloads directly.

Overview

Chatty was built around a singular architectural principle: your personal communications should never touch a server database in decrypted form. By combining modern WebRTC data channels with browser-native cryptography, Chatty provides verified ephemeral messaging.

// Browser-native cryptographic key generation
export async function generateSecureKeyPair(): Promise<CryptoKeyPair> {
  return window.crypto.subtle.generateKey(
    {
      name: "RSA-OAEP",
      modulusLength: 2048,
      publicExponent: new Uint8Array([1, 0, 1]),
      hash: "SHA-256",
    },
    true,
    ["encrypt", "decrypt"]
  );
}

Architectural Highlights

Zero Server Retention: Messages never reach or pass through a backend database.
Hardware-Accelerated Encryption: Keys and ciphers are processed directly by browser crypto subsystems.
Direct P2P Data Channels: Text and file packets travel peer-to-peer over UDP-based WebRTC tunnels.

Architectural Trade-offs

Key Architectural Decisions

01Used Web Crypto API primitives rather than external JavaScript crypto bundles to guarantee hardware-accelerated, constant-time operations immune to timing attacks.
02Configured ephemeral session chambers that delete cryptographic handles from memory on tab closure.
03Implemented STUN/TURN failover mechanisms to support enterprise firewall traversal while strictly enforcing end-to-end payload encryption.

Technical Challenges Overcome

!1NAT traversal across symmetric and carrier-grade NATs without routing through centralized relays.
!2Ensuring seamless key derivation and cryptographic integrity checks across heterogeneous mobile and desktop browsers.
!3Handling peer disconnections gracefully while ensuring zero message remnants remain in browser local storage or server memory.

What I Learned

✓Browser-native cryptographic primitives are significantly faster and more secure than polyfilled NPM libraries.
✓Peer-to-peer signaling state machines require strict race condition guards when ICE candidates arrive out of order.

Related Writing & Technical Essays

Read ArticleThe Silent Handover: Ethics of Autonomous Delegation