Part I

The Argument

There are three ways to build private communication at this level, and two of them are wrong for reasons that are structural rather than a matter of taste. Working through why is the fastest route to understanding what we actually built.

Why not a platform

The obvious answer is to use a very good encrypted messenger and be done. It is the wrong answer, and the reason is not the encryption — the good ones are excellent — but where the encryption stops.

The most widely used "private" messenger encrypts one-to-one conversations only when a user deliberately switches that on, keeps everything else in a cloud it holds the keys to, and cannot end-to-end encrypt a group at all. For a network whose entire purpose is eleven women in a room together, that single limitation disqualifies it: every group conversation would sit in readable form on infrastructure we do not own, in a jurisdiction we did not choose, retrievable by anyone with a warrant, a breach, or root access.

The best of them — the one whose protocol is the genuine industry standard — is very nearly right. It encrypts everything by default, groups included, and hides who is talking to whom from its own servers. Two things still fail for us. It requires a phone number to register, which is a SIM-swap target and a permanent link between an app account and a real-world identity. And its servers are somebody else's: excellent people, sound intentions, and still a party we would be asking members to trust on our word.

A network for eleven should not require anyone to trust a company they have never met.

Why not a blockchain

The instinct that a distributed cryptographic ledger would help is a good instinct pointed at the wrong problem, and it is worth being precise about why, because the idea sounds strong until examined.

A public chain is the opposite of what we need. Its defining property is that every entry is permanent and visible to everyone forever. Even without message content on it, the pattern of who transacted with whom, at what times, in what rhythm, would be published immutably — and pattern is the sensitive material here. You would have built a permanent, public record of a private network's social graph.

A private or consortium chain fixes the visibility and keeps the wrong shape: every consensus node still holds a complete copy of the ledger, writing message traffic to a chain is slow and expensive by design, and you have multiplied the number of machines holding data rather than reduced it.

The useful part of the idea — no central database to breach — we take. We simply take it by holding almost nothing rather than by distributing everything.

Why one machine is enough

Here is the fact that makes the whole architecture tractable: this network has one hundred and twenty-one members at full capacity. Eleven circles of eleven, and the cap is real.

At that scale, essentially every argument for distributed infrastructure evaporates. There is no load to spread. There is no region to be closer to. There is no elastic demand curve. A single well-specified workstation with a great deal of memory handles this traffic without noticing it, and will continue to at ten times the size.

What one machine buys that no distributed system can is a single place where anything unencrypted ever exists — a place we can point at, walk to, and physically guard. Every additional machine in the design is another place to secure, another administrator to vet, another jurisdiction to consider. The smallest possible attack surface is one box in one room.

Part II

The Shape

Four isolated services on one machine, reached through an outbound tunnel that never opens a port to the internet. That is the entire topology, and its simplicity is the point — every component you cannot remove is a component you have to defend.

The four containers

All four sit on an isolated private bridge with no route to anything else on the premises. Registration is off. Guest access is off. Federation is off. Every one of those is a default we inverted deliberately.

The blind pipe

The one thing we use somebody else's network for is reachability — a member on a hotel connection in another hemisphere has to be able to find us, and our machine must not have a public address for anyone to scan, flood, or map.

So the machine dials out. A lightweight daemon holds a persistent outbound connection to a global edge network, and all member traffic arrives back down that pipe. No port is open on our side. Our address is never published. A port scan of the internet does not find us because there is nothing at any address to find.

And the pipe is deliberately dumb. It forwards packets; it does not terminate them. The edge network cannot read a header, inspect a request, or run code of ours, because we deploy none there. This matters and it is where a lot of otherwise-good architectures quietly fail: it is very tempting to put a small piece of clever logic at the edge for speed, and the moment you do, an unencrypted request exists on a machine you do not own.

If any readable data touches a machine we do not own, the architecture has failed, however fast it made things.

Termination at home

Encryption terminates inside our room and nowhere else. The proxy container is the first and only thing that sees an unwrapped request, and it does three jobs in the order given: enforce a strict modern cipher suite and nothing older, strip every identifying header before passing anything inward, and write no record that the request occurred.

Downstream of that proxy, the messaging core receives requests that have no client address attached, no device signature, and no geographic hint. It could not log those things if it wanted to, because by the time it sees the request they no longer exist.

Memory, not disk

The machine has a great deal of memory, and the reason is a privacy property rather than a performance one.

Database buffers, working memory and the messaging core's caches are all sized so that active traffic lives in RAM rather than on the drive. Practically, that makes the network fast — but the property that matters is that memory is volatile. Pull the power and the working state is gone, instantly and unrecoverably, in a way that no disk wipe achieves. Undelivered messages, active session state, and everything in flight simply ceases to exist.

Which turns the crudest possible physical response into an effective one. If the room is entered, the correct action is to unplug the machine, and the correct action takes one second.

Part III

No Logs

"We do not log" is the most abused sentence in this industry, so here is exactly what it means here, at which layer, and how it is enforced rather than intended.

Off at source, not scrubbed after

The distinction is everything. A service that writes logs and deletes them nightly had logs — for a window, on a disk, in a backup, recoverable by forensics and discoverable by process. A service configured never to write them never had them.

So logging is disabled at source across every layer of the stack. The proxy has access logging switched off outright and its error stream directed to nowhere. The messaging core runs at a log level that records service faults and nothing about who caused them. The database does not log statements or connections. The tunnel daemon runs at its minimum verbosity. And the host operating system's own network-level logging for this service path is off.

There is no cron job deleting logs, because there is no log to delete.

The header scrub

Even without logs, headers leak into memory and can propagate inward. The proxy explicitly overwrites the client address, the forwarded-for chain, the user agent, every geographic hint the edge network attaches, referrer, and the accepted-language string — which is a more precise identifier than most people realise.

What continues inward is the encrypted payload and the routing token, and nothing else. The messaging core knows a valid member made a request. It does not know from where, on what, or in what timezone.

What the machine actually knows

Honesty requires the positive list, because "we know nothing" is never true and claiming it destroys the credibility of everything else on this page.

The database holds account handles and public keys — necessary for members to find each other, and useless to anyone else. It holds encrypted message blobs pending delivery, which the machine cannot read, on a short expiry, removed once collected. It holds room membership as encrypted state. And the operating system holds the fact that a tunnel is connected, which is a property of our own machine rather than of any member.

What does not exist anywhere: message content in readable form, a call recording, an address, a device identifier, a location, a name, an email, a phone number, or a log that any of the above ever passed through.

Part IV

Identity

No phone number. No email address. No account recovery question. Identity here is a key that lives in a piece of hardware and a card that came by courier, and the design follows from a single decision: nothing that identifies a member in the real world enters any system we operate.

No phone number

A phone number is the worst identifier available for this cohort, and it is what nearly every secure messenger insists on. It is a SIM-swap target — a category of attack that works by persuading a carrier's employee rather than by breaking any cryptography, and it is used against exactly this population. It permanently ties an account to a carrier's records and a legal name. And it lets anyone who knows the number confirm the account exists.

So we do not use one. On first launch, the device generates an identity keypair inside its own secure hardware. The private key is written into that hardware and never leaves it — not to us, not to the machine, not to a backup. The public key is what the network knows, and it is the entire account.

The printed card

The account is created by hand, on our machine, by us. The tool that does it produces a handle, a high-entropy first credential, and the address of the server — and then that is printed onto card.

People are sometimes surprised that the most secure step in the sequence is a printer, so it is worth stating the logic plainly. Our machine is the root of trust for this network. If our machine is compromised, the network is compromised, and whether a credential briefly existed in a text file on it changes nothing about that. What paper buys is that the credential never travels through any digital channel at all — not our email, not the member's, not a messaging app, not a password manager, not a cloud clipboard. There is no interceptable path because there is no path.

The courier

The card travels in a sealed, tamper-evident envelope, by hand, to the member — and increasingly it travels inside the device we issue. The onboarding is completed in person or on a call with someone she already knows by voice.

On first login the device does its own key generation, she sets her own credential, and the printed one is dead. The card is then hers to destroy, which most people do, and a few keep.

Losing a device

This is the honest cost of the design and we state it before onboarding rather than after.

Because the private key exists only in the hardware of the device, a lost device means a lost history. There is no password reset, because there is no password we hold. There is no cloud backup, because a backup we could restore is a backup we could read. There is no recovery question, because the answer would be an identifying fact about her.

What happens instead is a person. She reaches whoever she reached before, is verified by voice and by things only she would know, and a new device is provisioned and couriered — usually within a day. Her account works. The conversation history that lived on the lost device is gone.

We would rather explain this once, at the beginning, than build the convenient thing that quietly undoes the rest.

Part V

The Hardware

The weakest point in any secure system is a member's own phone, running an operating system that reports to its manufacturer, alongside four hundred applications she did not audit. So we do not ask her to secure it. We give her a second device that is already secure, and it does one thing.

The device we issue

A hardened handset, procured by us and configured before it ships, running a privacy-focused operating system built on a hardware platform with a genuine security chip. It is not signed into any manufacturer account. There is no app store on it, no telemetry leaving it, and no service phoning home.

It carries our application and nothing else. Storage is scoped so that application cannot see the rest of the device. Screenshots and screen recording are blocked at the operating-system level, so the attempt produces a black frame rather than an image. The app blurs itself in the task switcher, and after a few minutes in the background it purges its decrypted state from memory and requires biometric re-entry.

The device reboots itself after a period of inactivity, which sounds trivial and is not: a rebooted device has its encryption keys back behind the lock screen rather than sitting available in memory, which is the difference between a seized phone being readable and being a brick. Legacy cellular bands are disabled so the device cannot be forced onto an interceptable connection by a simulated tower.

The duress key

Each member sets two codes. One opens the device. The other destroys it — a second code that, entered under compulsion, discards the hardware keys immediately and irreversibly. The device does not warn, argue, or display anything unusual; it becomes a blank handset in under a second, and no forensic process recovers what was on it.

We teach this once, at handover, and never test it. Most members will never use it. The ones who might are the reason it exists.

Notifications without leaks

A detail worth spelling out, because it is where most "secure" applications leak the most and nobody looks.

An ordinary app sends its notification text through the phone manufacturer's push service, which means the manufacturer sees a preview of the message and who sent it — an astonishing amount of signal, given the effort spent encrypting the message itself. Our app sends a blank trigger instead: an empty wake-up carrying nothing. The device wakes, reaches down the tunnel, collects the encrypted blob, decrypts it locally, and renders the notification on the device itself.

No intermediary ever sees the sender, the room, or a word of the content. The visible cost is a fractionally slower notification and slightly more battery, and we say so at handover rather than let anyone discover it.

Part VI

The Room

Concentrating everything into one machine makes that machine the entire prize. The measures below are therefore not optional extras; they are the load-bearing half of the design, and they are physical rather than cryptographic.

Physical custody

The machine sits in a locked room to which a very small number of named people hold access, and that access is logged against those names. Full-disk encryption is on, so a stolen machine is a paperweight. A firmware lock prevents booting from anything but its own drive, closing the standard route around an operating system. It has its own network segment with no path to anything else on the premises — no shared printer, no building system, no guest network.

It runs on battery backup, so a power cut is not an outage and a surge is not a loss. And it is watched: if the machine is moved, opened, or its environment changes, it powers itself down rather than continuing.

The successor envelope

The obvious objection to one machine and one operator: what happens if the operator is unavailable.

A sealed instrument held by counsel contains what a competent technical successor needs to keep the network running — administrative credentials, the tunnel configuration, and written operating procedure. It is split so that no single holder can act alone, and it is released only on documented incapacity.

This is unglamorous and it is the difference between a private network and a hobby. A member should be able to ask what happens if you are hit by a bus and receive an answer with a name and a document in it.

The canary

On a fixed monthly schedule we publish a signed statement that we have received no compelled disclosure order. When that statement stops appearing on schedule, members know what a gag order would prevent us from telling them.

It costs nothing, it cannot be faked in our name, and it converts a promise about the future into a mechanism that operates without us.

Part VII

Honest Costs

Six things this architecture is worse at than a commercial messenger. A page that listed only advantages would not deserve to be believed.

Every one of those is the price of the same property: that there is exactly one place in the world where anything readable exists, and we own it. A commercial messenger is better at all six and cannot offer that, and for this network that single property outranks the six.

We would rather be down for a day than readable for a minute.