Writing about privacy, messaging, and zero-storage architecture.

Today the European Parliament reinstated Chat Control 1.0. Through a controversial procedural manoeuvre — bypassing the committee that had previously rejected it — the voluntary message-scanning regime is back in force until 2028.

Here is what actually passed, what it means for encrypted services, and why Nema's architecture puts it in a different category from the platforms this regulation targets.

What passed today

Chat Control 1.0 is a voluntary derogation from the EU's ePrivacy Directive. It gives large platforms a legal basis to scan private messages for child sexual abuse material. It does not require them to scan. It does not apply to end-to-end encrypted communications — the Parliament's own position explicitly states that detection measures "should not apply to end-to-end encrypted communications." And it targets existing large platforms: services like Gmail, Facebook Messenger, and Snapchat that have opted in voluntarily since 2021.

What was not passed

Chat Control 2.0 — the permanent, mandatory regulation that would require platforms to scan messages and potentially require backdoors into end-to-end encryption — is still being negotiated in trilogues. It has not been adopted. The Parliament has repeatedly pushed back on mandatory E2EE scanning. The fifth trilogue on June 29 produced no agreement. That fight continues.

Why Nema is structurally unaffected by today's decision

Three reasons, in order of importance.

First, Nema uses end-to-end encryption throughout. The regulation that passed today explicitly exempts E2EE communications. That exemption is not a loophole — it reflects a basic technical reality that the Parliament acknowledges: you cannot scan what you cannot read.

Second, and more fundamentally: Nema stores no messages on the server. There is no archive. There is no stored ciphertext. Messages are routed live between participants and never written to disk. Even if a scanning obligation applied to Nema, there would be nothing to scan. The data does not exist. You cannot provide what was never retained.

Third, it is voluntary. Chat Control 1.0 has always been opt-in. Nema has not opted in, and nothing in today's decision changes that.

Why architecture matters more than policy

Today is a good illustration of a principle Nema is built around: policy changes. Architecture does not.

A platform that promises not to read your messages is making a commitment that can be revised — by a board decision, a legal order, a change in ownership, or a regulation like the one debated today. That commitment has value only as long as the platform chooses to honour it.

A platform that structurally cannot read your messages because nothing is stored is making a different kind of statement. Not a policy. An architecture. The messages are not there. They were never there. No court order, no regulatory change, no ownership transition changes that fact.

Chat Control 1.0 is back. For most messaging platforms, that is a live compliance question. For Nema, it is not — because the data that would need to be scanned was never written in the first place.

The permanent regulation, if it ever passes with mandatory E2EE requirements, is a different and more serious question. We will address it directly if and when it does. For now: the architecture holds.

When you send a message on almost any modern platform, that message is stored. Not because you asked it to be. Not because storing it serves you. Because storage is cheap, product teams optimised for continuity, and nobody stopped to ask whether the conversation needed to outlive itself.

The default is permanent. That default was never chosen. It accumulated.

How we got here

In the early days of digital communication, storage was expensive. Retention was a deliberate engineering decision with a real cost attached. You kept what you needed and discarded the rest. The constraint enforced a kind of honesty about what was worth keeping.

Storage became cheap. The constraint disappeared. And in its absence, the industry converged on a single answer: keep everything. Sync it across devices. Index it for search. Queue it for offline delivery. Archive it indefinitely.

None of this was announced as a philosophy. It accumulated as a series of product decisions that each seemed reasonable in isolation. Offline delivery is useful. Search is useful. Cross-device sync is useful. The sum of those decisions is permanent retention as the universal default — applied to every conversation, regardless of whether that conversation should outlive the moment it happened.

The inherited arrangement

The consequence is an arrangement that nobody meaningfully agreed to: corporations and governments inherit long-term visibility into personal conversation as a side effect of using a messaging product.

This is not a conspiracy. It is a byproduct. Messaging platforms did not set out to build surveillance infrastructure. They set out to build useful products, and useful products retain data. The surveillance infrastructure emerged as a structural consequence of decisions made for other reasons.

But the consequence is real. A conversation stored on a server is a conversation that can be subpoenaed, breached, leaked, or handed to a regulator. That is true regardless of what the platform's privacy policy says. The data exists. Data that exists is vulnerable in ways that data that does not exist simply is not.

Capability is not justification

The standard defence of permanent retention is that users benefit from it: search works better, history is available, nothing is lost. This is true. Retention is useful.

But usefulness is not the only criterion. The question is whether the usefulness of retention justifies the risks of retention — and whether users have a real alternative when it does not.

For many conversations, it does. Keeping a record of a business negotiation, a client brief, a long-running relationship — that is often worth the trade-off.

For others, it is not. A conversation between a journalist and a source. A discussion between a lawyer and a client. A personal exchange that was meant to be private in the way that spoken conversation is private — present in the moment, then gone.

For those conversations, the right default is different. The infrastructure always could have been built this way. The question is why it was not, and what that says about whose interests the default serves.

Why Nema exists

Nema is not an argument that retention is always wrong. It is an argument that it should not be the universal default — that there should be an alternative for conversations that should not outlive themselves.

Live, encrypted, private conversation. No server-side message history. When the space ends, it ends. Not archived. Not recoverable. Structurally gone.

That narrowness is not a limitation. It is the point.

Nema's landing page says that when a private space ends, the conversation is "structurally gone — not just deleted."

That phrase carries weight that deserves unpacking. What does structurally gone actually mean? How does it differ from deletion? And why does the distinction matter?

The difference between deletion and non-existence

When a platform deletes a message, it is removing something that existed. That process has a history. The message was written to disk, indexed, backed up, possibly replicated across data centres, and then removed — or marked for removal, which is not the same thing.

Deletion is an action performed on data. It implies prior existence. And prior existence creates risk: the message may have been copied before deletion, the deletion may be incomplete, the backup may not have been purged, a legal hold may have prevented deletion from occurring, or the deletion log itself may be subpoenaed.

Non-existence is different. If a message was never written to disk, there is no deletion process to perform. There is no backup to purge. There is no legal hold to contest. There is nothing to subpoena because there is nothing to provide.

How messages move through Nema

When two participants open a private space on Nema, the following happens:

Each participant's device generates a local E2EE key pair. The private key never leaves the device. It is stored in the browser's IndexedDB using the WebCrypto API with non-extractable key storage — which means the key cannot be exported or read by JavaScript running on the page.

The participants exchange public keys and verify each other's identity using a safety number — a fingerprint derived from both public keys. Sending is blocked until both sides confirm the match.

Messages are encrypted locally, on the sender's device, before transmission. The server receives an encrypted payload it cannot read. It routes that payload to the recipient. It does not store it. The encrypted payload passes through the server the way a phone call passes through a telephone exchange — in transit, never at rest.

When the space ends, the in-memory session state is cleared on both devices. The conversation that existed in that session — in RAM, in the DOM — is gone. It was never on disk on the server. It was never in a database. It was never in a log file. It was in memory, which is volatile by definition.

What the server actually holds

The server stores the minimum required to operate the service: account credentials, session tokens, E2EE public keys, and rolling anti-abuse counters. It does not store message bodies, conversation history, delivery queues, or any form of ciphertext associated with the content of a conversation.

This is enforced structurally, not by policy. Every release runs an automated privacy gate that fails the build if message persistence is introduced. The enforcement mechanism is code, not intention.

Why this matters

A server that stores encrypted messages is still a target. Encrypted ciphertext can be held while waiting for future decryption capabilities. It can be produced in response to a legal order, where the burden then shifts to proving the encryption is unbreakable. It can be leaked and later decrypted if key material is ever compromised.

A server that stores no messages — encrypted or otherwise — eliminates that surface. There is nothing to hold, nothing to produce, nothing to leak. The threat model changes fundamentally.

Structurally gone does not mean deleted. It means the data was never written in the first place.

Nema's central claim is that messages are never written to the server. No message bodies. No conversation history. No stored ciphertext. Nothing.

Claims like this are easy to make. They are less easy to enforce — because software changes, codebases grow, engineers make mistakes, and features get added. A claim that is true today needs a mechanism to stay true tomorrow.

Ours is an automated privacy gate that runs on every release and fails the build if message persistence is introduced. Here is what that means in practice and why it matters.

The problem with policy-based privacy

Most privacy promises work like this: a company writes a policy, the policy states what data is and is not retained, and the engineering team is expected to implement code that honours the policy.

This works until it does not. Features get added by engineers who did not read the policy carefully. A logging statement gets added for debugging and never removed. A message queue gets introduced for reliability and nobody asks whether it creates a retention surface. The gap between stated policy and actual implementation grows invisibly, in ways that are not caught until they become a breach or a disclosure.

The problem is structural: policy is written by one part of the organisation and enforced by another, with no automated feedback loop between them.

What a privacy gate does

A privacy gate is an automated test that runs as part of the build and deployment process. It inspects the codebase and the running server for behaviours that would violate the privacy promise, and it fails the build if it finds them.

For Nema, the privacy gate checks for message persistence. It verifies that the code paths for message handling do not write message content to any storage layer — no database, no log file, no queue, no cache. If a change to the codebase introduces persistence, the gate catches it before the change can be deployed.

This makes privacy enforcement part of the delivery pipeline. Not a review process. Not a periodic audit. An automated check that runs on every build, with the same weight as tests that verify the core functionality works.

Why this is a different kind of commitment

The distinction matters for anyone trying to evaluate whether a privacy claim is trustworthy.

A privacy policy is a commitment by the company. A company can change its policy. A company can be acquired. A company can be served with a legal order that requires it to quietly modify its practices. A company can make a mistake.

An automated gate in the build pipeline is a different kind of commitment. It is one that the engineering process itself enforces. Changing it requires a deliberate decision to remove or modify the gate — not just an oversight. That does not make it infallible. But it changes the nature of the guarantee from "we intend not to store messages" to "our delivery pipeline will not let us deploy code that stores messages without explicitly choosing to remove that constraint."

That is a narrower and more honest claim. And it is verifiable by anyone who can read the codebase.

The most common question people ask when they first encounter Nema is some version of: when are you adding groups?

The honest answer is: probably never. And understanding why is understanding what Nema is.

The standard product logic runs like this: start with a narrow MVP, prove the core experience, then expand. Add groups. Add offline delivery. Add media sharing. Add message history. Build toward the full-featured messenger. The limitations are a starting point, not a destination.

Nema does not work that way. The limitations are the destination.

What offline delivery requires

When a messaging platform delivers messages to users who are not currently online, it needs to hold those messages somewhere while it waits for the recipient to connect. That somewhere is a server. The message sits in a queue, on disk, until delivery is confirmed.

This is useful. It is also a retention surface. The message exists on the server between send and delivery. How long it exists there depends on how quickly the recipient connects, how long the platform holds undelivered messages, and what the platform's data retention policy says about queued content.

Adding offline delivery to Nema would mean adding exactly this: a server-side message queue with content waiting on disk. That is not a feature addition. It is a fundamental change to the privacy model. It introduces the thing Nema is specifically designed to eliminate.

What groups require

Groups introduce a coordination problem: messages need to be delivered to multiple recipients, some of whom may be offline, across multiple sessions, with history maintained so new members can see what was said before they joined.

Each of those requirements pushes toward retention. History for new members is retention by definition. Delivery to offline members is retention until connection. Multi-session coordination requires a shared record of what was said.

A group feature built on Nema's architecture — live only, no server-side storage — would be a group feature where everyone must be online simultaneously, no history is available, and any member who misses a session has missed it permanently. That is not how people use groups. It would be a poor product.

The alternative — adding server-side storage to support the features users expect from groups — would make Nema a different product. A product with a different privacy model. A product that is, in the ways that matter, indistinguishable from the tools it was built to offer an alternative to.

What restraint as design actually means

Nema is a tool for a specific thing: live, ephemeral, 1:1 private conversation where neither party wants a server-side record of what was said.

That thing has real use cases. A journalist and a source. A lawyer and a client in a sensitive matter. Two people who want to have a conversation the way people have always had conversations in person — present in the moment, not archived against the future.

For those use cases, groups would add nothing. Offline delivery would undermine the premise. Message history would be the opposite of the point.

The product is narrow because the use case is specific. The limitations are not a roadmap item waiting for resources. They are the argument made tangible: that restraint can be a design principle, and that a tool which does one thing correctly is worth more than a tool that does many things with a compromised privacy model.

Use your regular messenger for groups, offline delivery, and message history. It is genuinely better at those things.

Use Nema for the conversation that should not outlive itself.