The Story

Mike Reynolds, the designer of Earthships, was once asked whether he was building to stick it to the man. His answer was characteristically direct: the man doesn't want to live where Earthships are built, because Earthships don't need the grid. So the man's opinion of them is irrelevant.

Reynolds wasn't describing a fight. He was describing a bypass. An Earthship harvests its own water, treats its own sewage, generates its own power. The conventional infrastructure — the utilities, the grid, the companies and regulations built around supplying what a house needs — doesn't become obsolete universally. It becomes obsolete to the person living in that house. That's the move: out-innovate the dependency, not the institution. He built in the high desert of New Mexico, on land authorities didn't care about because it was seen as desolate and unprofitable. No one fights over land no one wants. The community that formed there was simply outside the frame.

XOs is the same idea applied to chat.

A lightweight relay server carries your words for a moment, drops them on two devices, and forgets everything. There is no database. There are no server logs. There is nothing for a platform to mine and nothing for a government to compel. The Online Safety Act, data retention requirements, platform compliance obligations — these apply to products with servers, to companies holding databases, to infrastructure that accumulates. XOs doesn't accumulate. There is simply nothing there to answer for, no cloud to exit later.

This is not a legal workaround. It is the architecture. It sits in a space the conventional framework has no particular reason to reach.

The Idea

XOs is a messaging app. Text only. Two people. No server.

It started as a question: if on-device AI can run with no server at all, could a messaging app? That question had a clean answer.

The founding principle is ownership. Your words, always. A conversation only ever exists between two people — never on a server. Both participants can always choose to take back what they said — ownership doesn't end at send.

The logo resolves the same idea visually — two people, moving toward each other, deliberately. That is the product made visible.

XOs is not on the App Store. It installs directly from a webpage onto a device — a Progressive Web App, available before an app store account or review process can get in the way.

The Name

XOs arrived and immediately made everything else redundant.

Pronounced Eks-ohs the way you sign off a message to someone close to you — xoxo. But also X's and O's — tic-tac-toe, a game played between exactly two people, one mark each, no more, no less. Text only, between exactly two people. The name is a description of the product.

The domain was available. That was the signal.

The QR code came first — the right way to connect two people deliberately, face to face, before the app is ever involved. That led to the logo. Then something unexpected: the visual pattern of a QR code has the same weight as a 2x2 grid. The O could contain a QR code. A tic-tac-toe grid where the O's face inward — two arrows pointing toward each other. The logo is the product.

When the name, the logo, the social model, and the product philosophy all resolve into the same image, your only option is to keep going

The North Star

Your words, always.

Not a tagline. A question asked of every feature, every trade-off, every edge case: does this honour the principle that a person's words are always theirs — before they send them, while they are in transit, after they arrive, and at any point after that?

If the answer is no — or even uncertain — it was never really on the table.

The Double Gate

Text only. Two people. No server.

Initially, either could have been the North Star. Tested against each other, they work better as a double gate — every feature, every trade-off, every edge case must pass both. The first is a principle. The second is a description. Together they answer most questions before they become questions.

Would group chat make the product more useful? "Two people" ends that conversation. Should users be able to share images? "Text only" settles it. Should the app back up conversations to the cloud? "No server" closes it. A nine-word product description is a decision engine. Most proposed features dissolve on contact with it — not because they were rejected, but because they were never actually options.

The first gate is harder to apply. "Your words, always" has to be used deliberately, because reasonable-seeming decisions can fail it without anyone noticing. That tension is where the interesting work happens.

Working Backwards

The FAQs came first. Then the website. The website launched before the app was ready. That sequence is deliberate

Writing the FAQ before the code is a way of pressure-testing whether a product is real. If you can't answer "what does redact mean?" honestly and specifically, the feature isn't designed clearly enough to build. If you can't answer "what happens when someone blocks me?", you haven't actually decided what happens when someone blocks me.

Amazon calls it working backwards — start with the press release, then build the thing that makes it true. The FAQ forced every question the product would eventually have to answer, and forced them to be answered in plain language before a line of app code existed.

One question triggered a complete redesign: "what happens when someone blocks me?" Writing the answer required committing to plain language for the person being blocked — and the honest answer under the original design was that the blocker could keep their messages indefinitely, with no recourse. That sentence cannot coexist with "your words, always." The feature had to be rebuilt.

Decisions That Weren't Obvious

Taking a principle seriously creates problems. These are four that required actual thinking.

Blocking and the ownership problem

The original blocking design was reasonable: when you block someone, you choose what to do with the existing conversation — keep it, redact your side, or delete it entirely. That seemed like the right amount of user control.

Then it was tested against _your words, always_. "Keep" means the blocked person's words remain on the blocker's device indefinitely — held by someone who just severed contact, with no way for the blocked person to retrieve them or withdraw consent. The blocked person is the less powerful party at that moment. The original design handed them no control at all.

The correct answer is mutual automatic redaction: when a block happens, both parties' messages are simultaneously removed from both devices. The blocker's words leave the blocked person's device. The blocked person's words leave the blocker's device. Neither party holds the other's words after the relationship ends.

This is not a technical decision. It is a product decision that a principle forces. The FAQ answer to "what happens when someone blocks me?" could not be written correctly until this was resolved. Writing the FAQ is what made the problem visible.

Notifications carry nothing

When a message arrives while the app is backgrounded, the notification contains no message content, no sender name, no count — just a generic wake signal that opens the app.

This passes both gates at once. Apple, Google, and the device lock screen can all read notification payloads — that is how push infrastructure works. Putting message content in a notification hands your words to every platform the notification passes through. "Your words, always" means that can't happen. "No server" means the notification infrastructure — Apple Push Notification service, Firebase Cloud Messaging — is itself a server that sees whatever you put in the payload.

The solution is an absence. The notification says nothing. Your words are waiting in the app — not in a system that companies can read.

The key custody dilemma

A cryptographic key stored in the browser can be locked to the device — permanently non-exportable, slightly more secure in isolation. But a key you can't export is a key the platform owns more than you do. If you lose the device, the identity is gone. If the browser vendor changes its policies, you have no recourse. That fails the principle.

The trade-off: the key can be exported, and until at-rest encryption is fully implemented, that comes with a documented vulnerability. The debt is tracked. The alternative would be more secure in one narrow sense while making self-custody structurally impossible — which is the one thing this product cannot compromise on.

Discovery without a directory

The obvious way to find someone in a messaging app is to search for their username. That requires the relay to maintain a queryable directory — a map of usernames to public keys. Every search is a piece of social graph metadata: who is looking for whom, when, from which device.

"No server" ends that. A directory is a server. A server that knows who you're looking for knows something about you that you didn't choose to share.

The answer is a QR code. Two people meet in person, one scans the other's code, and a connection is made — before the relay is ever involved. The relay never learns how they found each other, because they found each other before they touched the app. The consequence is real: you cannot find strangers on XOs. That is not a limitation the gate reluctantly imposed. It is what the gate revealed the product actually was — a private channel between people who have already chosen each other, not a network for reaching people you don't know.

XOs doesn't need the grid. The grid's opinion of it is irrelevant.