How the architecture works —
in plain terms.
Five properties, not a build manual. This page explains what the system guarantees and why — not the internal mechanics a competitor would need to copy it. Where more technical depth exists, it stays behind evaluation agreements.
Every property below is drawn from the full whitepaper's architecture chapters. Nothing here is a new claim.
One routing fabric, five moving parts
Every client and every Sharp#Soft service reaches every other party through a single routing fabric — there is no inner shortcut that bypasses it. What travels across that fabric, and what it's sealed under, is the rest of this page.
The router knows enough to deliver a sealed envelope to the right place — addressed by identity, not by network location — and nothing more about what's inside it. Everything that follows is a consequence of that one structural choice: identity without an email directory, content sealed under keys only you hold, shared access with no master key anywhere, a transport that hides who is talking to whom, and a recovery path you choose to enable or not.
Identity, without an email directory
Your identity is a cryptographic pair, not a login tied to a real-world handle.
Generated on your device, kept there
Every key you hold is created locally — never on our infrastructure — the moment you create an account or add an identity. The private half of your identity is sealed inside your account and is plaintext only on a device where you've supplied your credential. It is never transmitted, not even during login: proving who you are uses a challenge-and-response exchange, not a key handed over the wire.
One login, many faces
A single account can hold several identities — work, personal, a project you contribute to — each cryptographically independent of the others. To us, and to anyone else, two identities under the same account look like two unrelated people; the only place they connect is inside your own opened account.
Not discoverable by default
There is no directory mapping names, emails, or phone numbers to identities. You are found only by a deliberate act — sharing an opaque reference with someone specific. An outside party cannot enumerate the system to find you; they need something you chose to give them.
A subscription is not a login
Billing needs an email address for entirely ordinary reasons — receipts, renewal notices. That record is kept architecturally apart from your cryptographic identity: the service that knows your billing email does not hold your sealed account, and the service that holds your sealed account does not hold your email. Neither, alone or together, reveals what you say or to whom.
Sealed on your device, before it goes anywhere
Content is encrypted under keys you own, under several independent layers — so that breaking any one layer does not break the seal.
Anything of yours that we store at rest — your account, your saved identities, your personal drafts and files — is sealed under a chain of independent encryption layers before it ever reaches our infrastructure. Each layer uses its own independently generated key. The chain deliberately draws on more than one well-established encryption algorithm rather than relying on a single one throughout.
The property this delivers: a future weakness found in any one of those algorithms does not, by itself, expose your content. The remaining layers — built on a different mathematical foundation — still hold. This is defense in depth applied to encryption itself, not just to the surrounding system.
Compression, honestly labelled
Content is also compressed before it's sealed — smaller files at rest, less bandwidth on the wire, more of your storage quota left for you. This is a space-and-speed benefit, not a security one: it does not add or remove any protection. We name that distinction plainly because the two are easy to conflate.
Order matters: compress first, then encrypt. Well-encrypted data looks like random noise, and random noise doesn't compress — so the sequence is fixed. It's a small detail, but getting it backwards would quietly throw away the benefit.
Shared spaces — with no master key
The primitive that makes "shared without shared secrets" literally true, not just a slogan.
Membership is the only way in
When two or more people share access to something — a conversation, a document, a shared space — that content is sealed under a key held only by its members. Each member receives their own copy of that key, sealed specifically to them. Nobody — not the person who created the space, not an administrator, not us — holds a master key that opens it independently of being a member.
Your permissions are keys, not settings
Roles inside a shared space (owner, admin, someone who can only read, someone who can only sign) are enforced by which specific key material each role actually holds — not only by a check in the software. Someone with read-only access literally does not possess the key needed to sign on the space's behalf; the boundary survives a coding mistake because there is no key there to misuse.
Removal actually removes access
Take someone out of a shared space and their access is cut — to future content and to anything they hadn't already opened. This isn't a permission flag being flipped; the underlying key material is rotated so their old copy stops working. What they had already viewed and retained on their own device is, as with any shared information, outside anyone's cryptographic reach — no system can recall what a person has already seen.
A refusal, never a silent weakening
If a shared space ever reaches a state where its protection can't be fully guaranteed — say, through an unusual sequence of membership changes — it refuses to operate rather than continuing with quietly reduced protection. A visible failure that asks for attention, instead of an invisible compromise.
A transport that hides who's talking to whom
Most private-messaging systems protect what you say and leave who you said it to, and how often, observable. Sharp#Soft treats both as sensitive.
Every message and every request between any client and any Sharp#Soft service travels as a sealed envelope through a single routing fabric — there is no privileged shortcut that skips it. The fabric reads only what it needs to deliver an envelope to the right place; the contents inside stay sealed under your own keys the whole way, and the fabric has no operation that reads them.
The routing information itself — who sent it, who it's addressed to, when — is protected too, under a separate seal of its own. An outside observer watching the network sees that traffic exists between an endpoint and our infrastructure, and roughly how large it is. They do not see the content, who is corresponding with whom, how often, or how many people are party to it.
No privileged shortcut
There is exactly one path between any two parties in the system — a client and a service, or one service and another. No component reaches another by any route that skips the sealed fabric. The protections below apply uniformly, to every interaction, because there is nowhere else for traffic to go.
Why metadata matters as much as content. Knowing that two people exchanged a hundred messages a day for a month reveals a relationship even without reading a single word. Sharp#Soft treats that pattern as something to protect, not an unavoidable side effect of running a messaging service.
Recovery is your choice — named honestly
The strongest privacy posture and the most fragile one are the same posture. We tell you that plainly instead of pretending otherwise.
By default: nobody can recover it, not even us
Out of the box, there is no recovery channel for your account. If you lose your credential and haven't opted into recovery, your content cannot be reopened — not by you, not by Sharp#Soft, not by anyone. This is the strongest form of "your keys never leave you": it is true precisely because no one holds a spare.
Opting in trades a little strength for safety
You can choose to enable a recovery path. Doing so adds a small additional target for an attacker to go after — a working recovery channel is, by definition, a channel that can recover something. In exchange, you gain the ability to get back in if you lose your credential. It's your call, made explicitly, and reversible at any time.
The honest version, not the reassuring one. A product that says "don't worry, we can always get you back in" is quietly telling you it holds something capable of opening your account without your credential — and that something is a target. Sharp#Soft would rather tell you the trade-off up front and let you choose your own balance of recoverability against strength.