How zkChat works under the hood (without a math PhD)

You don't need to be a cryptographer to understand the core idea behind zkChat.

Here's the system in plain language.

1. Keys live in the URL fragment

When you create a room or a one-time message, your browser:

• Generates a random 256-bit key
• Uses that key with AES-256-GCM to encrypt everything
• Puts the key into the URL fragment: #key=...

Important detail: the part after # is never sent to the server. The server only sees the path and query string, not the fragment.

That means:

• The relay server never sees your encryption key
• Only people you share the full link with (including the fragment) can decrypt the content

2. The relay is blind

For group rooms, zkChat uses a simple WebSocket relay:

• Your browser opens wss://…?roomId=XYZ
• When you send a message, the browser:

- encrypts { senderId, text, createdAt } with AES-GCM

- sends { iv, ciphertext } over the socket

• The server just forwards that blob to other clients in the same room

The relay knows:

• that a room with ID XYZ exists
• how many connections are currently active

The relay does NOT know:

• who you are
• what you say
• which persona belongs to which human

All the interesting parts are inside the ciphertext.

3. One-time messages and files

One-time messages and file drops use a small HTTP API instead of WebSockets:

• Your browser:

- encrypts the message or file

- uploads the ciphertext to /otm or /file

• The server returns an ID
• You generate a link like /otm/<id>#key=... or /file/<id>#key=...

When someone opens the link:

• The browser requests /otm/<id> or /file/<id>
• The server returns the ciphertext once and immediately deletes it
• The browser decrypts locally using the key from #key=...

If the link was already opened or the TTL expired, the server just returns "used/expired".

4. No history, no accounts, no tracking

zkChat deliberately does not have:

• login / registration
• global user profiles
• message history
• push notifications
• analytics scripts

Your session is basically:

• a random room ID
• a random senderId
• a short-lived WebSocket connection

When you close the tab or the room burns, it's gone.

Conclusion

zkChat transforms encrypted communication into a scanned communication environment. While encryption protocols may remain mathematically strong, the introduction of mandatory client-side scanning breaks the threat model that makes E2EE meaningful.

The directive's long-term impact will be felt primarily through normalized metadata surveillance. Once scanning infrastructure is legally mandated, the same systems enable comprehensive monitoring of communication patterns, social graphs, and behavioral profiles.

Metadata-free, ephemeral, zero-knowledge designs become more important not as tools to evade legitimate law enforcement, but as architectures that eliminate the data foundations upon which surveillance infrastructure depends.

Systems such as zkChat demonstrate how secure-by-design architectures may evolve in response to regulatory shifts — by removing the very data that scanning systems rely on. When there are no accounts to subpoena, no messages to archive, and no metadata to analyze, compliance with surveillance mandates becomes structurally impossible.

The question is not whether encryption remains mathematically strong. The question is whether the systems built around encryption will preserve or undermine the privacy properties users depend on.