One chart.
All the way down.

Think about what an operating system actually did for the computer. It gave the machine a catalog of what was installed, accounts so more than one person could use it without reading each other's files, a file system where your documents were yours — and, the quiet radical part, equal footing: a program you wrote yourself ran under the same rules as a program from the largest vendor in the world. The system did not have a favourite.

Then we connected the computers together, and somewhere in the rush we forgot to build the operating system for the thing we had made. The Internet has wires and addresses and protocols for moving bytes. What it never got was the higher layer.

It got built the way anything gets built when there is no shared standard: privately, in pieces, by whoever moved fastest. Each piece became a platform. And every platform is a landlord.

The account you use every day is not really yours; it lives on someone else's machine, under someone else's rules, and somewhere there is an administrator who holds a master key. That key can read your files. It can reset your account. It can hand your data to a third party who asks the right way. None of this requires malice — it is simply how the building is wired.

The landlord can — so the only thing standing between you and exposure is the landlord's continued good behaviour.

Policy-private: we could read your data, but we choose not to. That is essentially every mainstream cloud service.

The operator keeps the technical capability. Privacy then depends on good behaviour, on internal controls, and on the absence of legal compulsion strong enough to override them — a chain, and it holds only while every link holds.

When any one of those breaks — an insider with admin access, a breach that exposes admin credentials, a court order with sufficient reach, a change of ownership — the operator's capability becomes your exposure.

On your own computer the file system never depended on the manufacturer promising not to read your files — it was simply built so. On the Internet we replaced built so with promised not to.

There is another way to mean “private” — one that does not rest on a chain at all. That is the subject of How protection works.

The full argument: The Internet Never Got an Operating System · the whitepaper

You own what you make. Not as a permission an operator grants and can withdraw, but as a property of how the thing is built. Nobody has to be trusted — not us, not an administrator, not whoever owns this company in ten years. The limits are said out loud, because what a system cannot do is part of what it is.

These are not values we hope to live up to. Each one is a claim about construction, and each one is checkable — which is the only kind of principle worth printing.

Every privacy promise is really a list of people who must keep behaving: the operator, its staff, its future owner, and whatever authority might compel it. Any one of them failing is enough.

Our list is empty — not because we are more trustworthy, but because the keys are yours and our good behaviour is not load-bearing.

This is the principle the other two rest on. Ownership means nothing if someone else holds a key to it, and stating limits honestly means little from a party you had to trust anyway.

There are four pieces. An Account — a container only you can open, holding the identities you use. An Identity — a private half that never leaves the account, and a public half you hand to people you choose. A CryptLock — a sealed space with a member list and no master key. And the maths: standard, public, unpatented cryptography.

Nothing further out is a new mechanism — messaging, storage and sharing are all these four arranged differently. That is deliberate: a small number of primitives you can actually inspect beats a large number of features you have to take on faith. And the cryptography being standard is a feature, not modesty — novel cryptography is a liability.

One account can hold several identities — work, personal, public. To everyone else, including us, they look like unrelated people; the only place they connect is inside your own opened account.

There is no email login, no phone number and no directory to be listed in. An identity is 384 bits of randomness with nothing personal in it, and you are found only when you choose to be found.

Content sealed under a CryptLock can be opened by its members and by no one else. There is no master key: not for the person who created the lock, not for an administrator, and not for us. Membership is the only way in.

Removing someone actually works — the lock rotates to a fresh key, and the removed member loses future content and everything they had not yet opened. A closed cryptographic door, not a greyed-out button.

Three things you do. You open your account — on your device, with your credential, and there is nowhere else it opens. You choose what is public — an identity stays private until you hand it to someone. You decide who can open what — membership of a lock is the access, and you hold it rather than a server setting somebody else controls.

None of these are settings you trust an operator to honour. Each is an action whose effect is cryptographic: opening happens on your device because the keys are only there; an identity is unfindable until shared because there is no directory to find it in; and access is membership because the content is sealed under the lock rather than filed behind a permission.

This is the difference the rest of the chart turns on. The usual model says we could read it, but we choose not to — the ability is there, and only conduct stands between it and you. Ours says we could not read it even if we wanted to.

The ability does not exist, so it cannot be misused by an insider, exposed by a breach, sold with the company, or compelled by an order. A court can compel us to produce only what we hold — and what we hold is opaque.

This is also why the honest limits elsewhere on this chart are not a disclaimer. When the guarantee is structural, the boundary of the structure is the boundary of the guarantee, and naming it precisely is what makes the rest checkable.

You do not connect to a server. You address an identity — and that is the only address that exists from where you are standing. No IP address, no hostname and no service address ever appears in anything a caller can see.

Where a service actually lives is the operator's implementation detail: internal, movable and replaceable as the system grows. That is what the name means — from a user's or a caller's point of view, there is no server you talk to at this address. There is an identity you address, and the route is somebody else's problem.

The property this buys is quieter than it sounds: a service can receive messages without accepting connections from the network at all. Someone who can scan and probe the whole internet finds only a small, hardened front line — the rest of the system is not reachable to be probed.

On your device the message exists in the clear — that is where it is written and where it is sealed. Across the wire and at our relay it is a sealed envelope. On the recipient's device — and only there — it opens again.

Nothing along the way needs to be trusted, because nothing along the way can read it. The seal is applied before the message leaves you and removed after it arrives.

Someone watching the network sees that your device talks to Sharp#Soft, and nothing more. Our relay holds a sealed blob addressed by an opaque delivery ID. The person you addressed sees the message — and they are the only one who does.

You seal and send. The message rests in a box that is theirs — still sealed to them while it waits — and they collect it when they next look. Neither of you is ever waiting for the other.

Some messages are meant to be fleeting and some are meant to wait, and the system treats those differently on purpose. If both parties are present it goes straight through; if not, it rests. Either way it is sealed to the recipient the entire time it is out of your hands, so holding it costs nobody any trust.

The usual way to send one thing to several people is to encrypt it separately for each of them — as many seals as there are readers, every time. Sharp#Soft does not work that way. Content is sealed once, under a lock, and every member of that lock opens it with their own key.

The consequence is quiet but large: adding a reader is a change to the lock's membership, not a re-encryption of the content. And removing one is not a revoked permission on a server — the lock rotates to a fresh key, and what they had not already opened is closed to them.

Sealed messaging between identities is built on this from day one. Shared spaces you can invite others into come after launch.

Three things, and none of them is a new mechanism. Keeping — files only you can open. Sending — messages only the person you addressed can open. Sharing — a space a group can open, and no one else.

Each is an Account, an Identity and a lock, arranged differently. That is why the guarantees are the same in all three: there is no separate “secure mode” to forget to switch on, and no feature that quietly relaxes the model to be more convenient.

Keeping and sending are here at launch. Shared spaces you can invite others into follow after it.

The hard part of building something private is the part anyone building on this doesn’t build. They inherit identity without a password database — nothing to breach because nothing is held. Storage that cannot read itself — which is exactly what lets their users trust them. And sharing without a master key — nothing to steal, subpoena or leak.

The “we cannot read your content” property transfers intact to their users — not because the builder is trustworthy, but because the architecture removes their ability to betray it. That is the interesting part: the guarantee survives being handed to someone you have never met.

This is a property of the architecture, not a programme. There are no dates here, and none are implied.