PURGE-CHAT // ARCHITECTURE & AUTOMATION
Zero-Knowledge & Ephemeral Storage Specs

SYSTEM ARCHITECTURE & VANISHING ENGINE

Understand how Purge-Chat delivers real-time secure communication using automated TTL eviction, client-side AES-256-GCM encryption, and zero-log retention.

AES-256-GCM
Client Encryption
Native TTL
Auto Eviction
Relational DB
No Memory Bloat
60-Day Purge
Inactive Backups
system_architecture.puml
Stage 01: Client Entry Node
Mobile & Desktop Browsers (Client Encrypted)
ORIGIN NODE
ENTER PIPELINE STREAM (SWIPE HORIZONTALLY)
STAGE 02: HIGH-SPEED PROCESSING TRACK
01 / TRANSPORTTLS 1.3

WebSocket Stream

Bidirectional encrypted pipe with heartbeats

Status100ms Latency
02 / ROUTERNext.js Edge

Application Server

NanoID route validation & handshake

StatusZero Logs
03 / EVICTIONReal-Time

TTL Sweep Engine

Evaluates NOW() > expiresAt eviction trigger

StatusAtomic Purge
04 / CIPHERE2E Secure

GCM Payload Vault

Local client AES-256 binary validation

StatusNo Plaintext
STAGE 03: CONVERGENCE TO STORAGE
In-Memory Cache Layer
VOLATILE TTL
Room Metadata & Expired Timer
Ephemeral Session Map
Zero Persistence Footprint
Ephemeral Datastore
RELATIONAL
Messages Table
Cascading Foreign Key Eviction
Encrypted Backups (60D Purge Sweep)

Execution Lifecycle Breakdown

STEP 01: Room Creation & Native TTL
01 / LIFECYCLE

Upon secret room creation, the system issues a secure 16-character NanoID key and records the room in the datastore with an explicit timestamp (expires_at).

A lightweight key-value cache entry is initialized with a native TTL (e.g. 10m, 1h, 24h). This prevents memory bloat and forces instant metadata eviction upon timer expiry.

STEP 02: Real-Time Transport & Storage
02 / MESSAGING

Messages stream instantly across active participants. Incoming payloads are stored in an ephemeral relational database table explicitly linked via foreign keys to the parent room.

Because message histories are handled via structured disk-backed relational storage rather than unbounded RAM, room capacity remains high without causing memory spikes.

STEP 03: Automated Cascading Purge
03 / AUTOMATION

Purging operates via a 3-tier automated safeguard:

  • On-Access Validation: Direct checks trigger immediate room destruction if NOW() > expiresAt.
  • Cascading Key Purge: Room deletion automatically purges all connected messages in a single atomic database operation.
  • Worker Sweep: Background workers sweep every minute to clean up orphaned or expired records.
STEP 04: Zero-Knowledge Backup & 60D Purge
04 / BACKUP

When a room creator requests a backup, the client encrypts the message payload locally using AES-256-GCM prior to uploading the encrypted blob to the backup repository.

Backups track a last_accessed_at timestamp. The automated worker permanently purges any untouched backup where last_accessed_at < NOW() - 60 Days.

Ready to communicate with total privacy?

No registration required. Create an encrypted room, share your single-use access link, and let the vanishing engine handle the rest.