Sharp#Soft
The whitepaper, in plain terms

An honest description of what is protected —
and where the limits lie.

Written for readers who won't take a privacy claim at face value — but readable without a cryptography degree. Understand what is actually protected, not just hope. Read it chapter by chapter below.

This web edition covers the publicly-open parts of the whitepaper. Deeper technical detail is available to evaluators and partners under agreement.

The thesis

Privacy-by-architecture is not a feature of Sharp#Soft. It is the design constraint everything else is derived from.

Most communication products that market privacy as a feature retain the technical ability to compromise it: master keys held by the platform, content stored in a form the operator can read, support flows that can open accounts on a user's behalf. When the architecture is built so the operator could read user data, the privacy claim ultimately rests on policy and personnel — not on cryptography.

Sharp#Soft was designed under a different constraint: the operator cannot. Not because we promise not to, but because user content, user keys, and the relationships between users are inaccessible to anyone — including us — who does not hold a credential the user keeps for themselves.

Three structural guarantees

Not settings. Not features that can be switched off. Properties the architecture holds by construction.

1 · Private keys never leave their owner

All key generation happens on your device. Keys are sealed at rest under your Account, and the Account opens only with your credential. Our infrastructure holds opaque ciphertext — there is no operation, protocol, or storage format that carries a plaintext key.

2 · Content opens only for the invited

Access means cryptographic membership, not a database entry. No server, operator, or help desk can add itself to your shared space or reveal a sealed file — invitation requires the owner's active cryptographic participation.

3 · Communication is invisible to outsiders

Not just message contents: sender, receiver, frequency, and volume are protected metadata. An observer on the network sees sealed envelopes — who talks to whom, how often, and about what stays inside the cryptography.

Read the whitepaper

Seven readings, from the thesis to the legal foundations. Start at the beginning, or go straight to the part you care about.

The limits, named up front

The section we most want every reader to read is the shortest one: the boundaries. Naming what the system does not defend against is what makes every other claim fully defensible.

  • We don't hide that communication is happening — traffic to our infrastructure is observable, its contents and correspondents are not
  • We can't prevent an invited recipient from copying what they can read — no system can, whatever it claims
  • We don't solve coercion, and we can't protect a fully compromised device
  • Recovery is opt-in — enabling it trades a small attack surface for the ability to recover; declining it keeps the strongest guarantee

How you verify

Every architectural claim in the whitepaper is traceable to its evidence: confirmed rules, completed development work, catalogued product parts, and published cryptography literature. The chain from statement to implementation is the trust artifact.

Every other privacy product asks you to trust them. This one asks you to check.

Privacy is not a criminal luxury. Privacy is a legally recognised fundamental right — see our answer to the "only criminals need privacy" objection, drawn directly from the whitepaper's legal appendix.

Want the deeper technical detail?

This web edition covers the openly-published parts. Evaluators, auditors, and partners can request the full technical brief under agreement.