Two ways to mean "private" —
and why the difference matters.
Most products that market privacy as a feature retain the technical ability to break it. This document describes an architecture built so the operator cannot read user content — not a promise, a structural fact — and names exactly where the limits of that fact lie.
Chapter 1 of 6 in the web edition. Written for a reader who won't take a privacy claim at face value.
Policy-private, or structurally private
Almost every product that says "private" means one of two very different things. Knowing which one lets you evaluate any privacy claim — including ours.
Policy-private
"We could read your data, but we choose not to." The operator retains the technical capability to access user content. Privacy depends on the operator's good behaviour, on internal controls, and on the absence of legal compulsion strong enough to override them. When any of those break — an insider with admin access, a leaked credential, a court order with enough reach, a change of ownership — the operator's capability becomes the user's exposure. This is the model of essentially every mainstream cloud service.
Structurally private
"We could not read your data even if we wanted to." The operator's capability to read user content does not exist in the first place. Insider misbehaviour cannot produce plaintext that was never accessible. A court order can only compel the operator to produce what the operator holds — and what the operator holds is opaque. Privacy depends on the cryptography and the architecture, not on conduct. Sharp#Soft is structurally private.
"We can't read your messages — by design, not by promise."
Three structural guarantees
Not features that can be configured on or off — properties the architecture holds by construction, all radiating from one fact: only the user holds the credential that opens their own account.
1 · Private keys never leave their owner
No operation, anywhere in the system, ever requires sharing private key material — not with Sharp#Soft, not with any part of our infrastructure, not with another user. Keys are generated on the user's own device and sealed under a credential only that user holds. Even where sealed material sits on our infrastructure — so a user can reach their account from more than one device — it is opaque ciphertext to us.
2 · Information is inaccessible to uninvited parties
Access to protected content means active cryptographic membership in the relationship that protects it — not a row in an access-control table. No server, operator, or support team can add itself to a shared space or reveal a sealed file. Removing someone is structural too: they lose access to future content and cannot derive it retroactively from what they once held.
3 · Communication is invisible to outsiders
Not just contents — sender, receiver, and the pattern of who talks to whom are protected too. An outside observer sees encrypted envelopes flowing to our infrastructure, and nothing about who is exchanging them, how often, or in what volume. Service addresses aren't exposed to callers either; everything is addressed by identity, not location.
These three guarantees hold for every participant in the system uniformly — a person, an automated service, or a Sharp#Soft component talking to another Sharp#Soft component. There is no privileged inner ring that bypasses them.
Who this defends against
No privacy claim can be judged without knowing what it's claimed to defend against. Here is the honest shape of it — who we defend against, and by what kind of property.
Anyone watching the network
Internet providers, public Wi-Fi, hostile networks, carrier-level intercept, even bulk wiretap operators. What they see: encrypted traffic flowing to our infrastructure — timing, volume, connection existence. What they don't see: any content, any sender or recipient identity, any message count. This holds even against an attacker who can actively tamper with, replay, or inject packets — tampering is detected and rejected, not silently accepted.
Us — the operator
This is the load-bearing case. Sharp#Soft itself, a hosting provider, a database administrator, a disgruntled insider with full infrastructure access — none of them can produce plaintext. They hold sealed identities, sealed accounts, sealed content, and operational metadata — but never a user-controlled key. The distinction between an outer transport seal (which infrastructure can peel to route traffic) and an inner content seal (which it structurally cannot) is what makes this true regardless of operator behaviour.
A single compromised service
If one part of our infrastructure were fully exfiltrated in isolation — without any user credential and without co-compromising other services — the sensitive linkages are still split across services on purpose, so no single compromised service holds the full join needed to reconstruct who is talking to whom. And even a full join would still not produce plaintext without the relevant user-held key.
Legal compulsion to disclose
A court or legal authority can compel us to hand over what we hold. What we hold, for protected content, is opaque ciphertext we cannot read ourselves — so that is all that can be compelled. This isn't a refusal to cooperate; it's an absence of capability. What remains compellable is the honest residue described below: things like billing email and connection metadata, which every operating service must retain to function.
We also design against someone reverse-engineering the shipped client to extract secrets, and against someone probing the system to infer group membership by watching for telltale error patterns. Neither yields anything a determined adversary could use — see the full threat model for the complete list.
What this does not defend against
Naming the boundaries plainly is what makes the guarantees above trustworthy. A system that only tells you what it protects is asking for faith; one that also tells you what it doesn't is asking to be checked.
- We don't hide that communication is happening — a network observer can see your device is talking to our infrastructure, just not the content or correspondents
- We can't stop an invited recipient from copying what they can already read — once someone has decrypted content, no cryptography can recall it
- We don't solve coercion — someone physically or legally compelled to hand over a credential or an unlocked device cannot be protected by architecture
- We don't protect a fully compromised endpoint — a device with a rootkit or memory-level malware can see what its user sees, same as every comparable system
- We can't eliminate every piece of operational metadata — billing email and live-session connection details exist because the service has to function; we minimise rather than claim to erase them
Recovery is a trade-off, honestly named
Account recovery is opt-in. Enabling it accepts a small additional attack surface in exchange for the ability to recover a lost credential. Declining it keeps the strongest form of "we cannot read your messages" — at the cost that if you lose your credential and are the sole holder of your content, no one can recover it for you. That trade is yours to make, not ours to obscure.
Privacy is not a criminal luxury. It's a legally recognised fundamental right under the UN Universal Declaration of Human Rights, the European Convention on Human Rights, the EU Charter, and the GDPR — applying equally to individuals and organisations. Targeted, warrant-based lawful access against a specific endpoint remains fully effective; what this architecture forecloses is population-wide collection, which those same instruments already prohibit.
How you verify — check, don't trust
Every other privacy product asks you to trust its claims. This one asks you to check.
This document is not a security proof — formal verification of the cryptography is future work, and we say so rather than overclaim. It is also not a marketing brochure: where something hasn't shipped yet, we say so; where a guarantee only holds under a specific configuration (like opt-in recovery), we name the configuration.
What we do instead is publish an evidence chain. Every architectural claim in the full whitepaper traces back to something checkable: a confirmed engineering rule, a completed piece of development work, a catalogued part of the product, or a published cryptography standard — the same kind of standards body references (NIST, IETF, ISO) that any credentialed engineer can look up independently. A reader who wants to verify a statement can follow that chain from the prose to the evidence themselves, rather than taking our word for it.