Sharp#Soft
The security model, in plain terms

How it protects you,
step by step.

Five short steps through the Sharp#Soft security model — what happens to a message or file from the moment you hit send, and why we couldn't read it even if we wanted to. No cryptography degree required.

Everything here is drawn from the published whitepaper — including the limits.

The walkthrough

Pick a step, or use the arrow keys once a step is focused.

Walkthrough steps
Your message is sealed on your device; the server receives only a sealed envelope it cannot read. Your device — the only place it's readable sealed before it leaves Our servers — store sealed bytes only

Step 1 of 5 · No server trust

Sealed on your device — before it goes anywhere

In an ordinary app, your message arrives at the provider's servers readable. It may be encrypted on the way, but the provider holds the keys — they can read it, scan it, or be compelled to hand it over. Their privacy is a promise of conduct.

Sharp#Soft works the other way around. Your content is sealed on your device, with keys that are created there and never leave. What travels to our servers is a sealed envelope. We relay it and store it — and that is all we can do with it.

"We can't read your messages — by design, not by promise."

Your account holds a private identity that never leaves, and a public identity you choose to share with a contact. No email or phone number is involved. not needed YOUR ACCOUNT opens only on your device Private identity never leaves the account Public identity share it — or don't SharpId a contact you chose

Step 2 of 5 · Identities

You're not an email address here

There is no email login, no phone number, and no master account directory. Your identity is a cryptographic pair: a private half sealed inside your account, and a public half you hand to the people you choose. It's referenced by a SharpId — 384 bits of randomness with nothing personal in it.

By default, nobody can find you. There is no directory that maps names, emails, or numbers to identities. You become discoverable only by a deliberate act: sharing your SharpId, sharing an identity link, or opting into keyword search on terms you pick.

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

A CryptLock is a sealed space: three members hold keys and can open it; an outsider and the operator have no key and cannot. CRYPTLOCK content sealed under the lock's key members hold the key outsider — no key us — no key either

Step 3 of 5 · CryptLock

A sealed space only its members can open

Every private conversation in Sharp#Soft lives inside a CryptLock — a cryptographic container with a member list. Content sealed under the lock 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 hadn't yet opened — not just a greyed-out button, a closed cryptographic door.

At launch  Sealed messaging between identities is built on CryptLocks from day one.
Roadmap  Shared encrypted spaces you can invite others into arrive after launch.

A sealed message carrying its rules: an enforced expiry clock, a verifiable creator signature, and client-honoured flags such as read-once, no-forward, and no-screenshot. your content, sealed — rules attached Expiry enforced — purged when due Creator signature verifiable — proves who sealed it read-once no-forward no-screenshot honoured by the client — honest signals, not magic (see below)

Step 4 of 5 · Creator rules

Your rules travel with the content

When you seal a message or file, your intent is packed into the same sealed wrapper and travels with it — the rules don't live on a server setting someone else controls. Two of them are hard properties: every message carries an expiry and is purged when it lapses, and a creator signature lets recipients verify who sealed it.

You can also flag content read-once, no-forward, no-quote, or no-screenshot. The Sharp#Soft client honours these faithfully.

And here is the honest part most products skip: for someone who can read content, flags like these are signals to a well-behaved app — no system can cryptographically stop a determined recipient from copying what they can see. Anyone claiming otherwise is selling you something.

A sealed envelope travels from your device across the wire to the Sharp#Soft relay and on to the recipient's device — it stays sealed the whole way and opens only at the destination. You sealed here the wire: traffic visible, content and correspondents not Sharp#Soft relay sees a sealed blob and an opaque delivery ID — nothing else Your recipient the only place it opens

Step 5 of 5 · End to end

Follow a message the whole way

Put it all together and watch one message travel. On your device it exists in the clear — that's where it's written, and where it's sealed. On the wire, an observer sees that your device talks to Sharp#Soft, and nothing more: not the content, not who it's for, not how many people will receive it.

At our relay, the envelope waits for pickup as a sealed blob addressed by an opaque random ID — and the system is split so that no single service holds both the delivery graph and the content. On your recipient's device — and only there — the seal opens.

Sealed at the first step, opened at the last, unreadable everywhere in between. That is the whole model.

Good questions, straight answers

The three things people ask first when they hear the model.

Why no email address?

An email login ties everything you do to one real-world handle — and hands the provider a directory of who you are. Sharp#Soft identities are cryptographic objects with nothing personal inside, unlisted by default. A subscription may carry a billing contact, but it is never a login and never links your identities together — the only place they meet is inside your own opened account.

What is a CryptLock?

The sharing primitive everything private is built on: a sealed container with a member list, where members hold the key and nobody else does — no creator override, no admin override, no operator override. Messaging threads are CryptLocks at launch; invitable shared spaces follow on the roadmap. If you remember one term from this page, make it this one.

What can the server see?

Sealed blobs, opaque delivery IDs, connection IP addresses, subscription and billing details, and how much sealed storage you use. That's the honest, complete shape of it: what we need to run the service — and nothing inside anything you've sealed. The full enumeration, including why each item exists, is in the whitepaper's boundary chapters.

The limits, in print. No system can hide that you use Sharp#Soft, recall plaintext someone already exported, or protect a fully compromised device. We name our boundaries as carefully as our guarantees — that's what makes the guarantees credible. Read the boundaries in the whitepaper →

Go deeper

This page is the picture. These are the details.

The whitepaper

The full technical and legal foundation — architecture, threat model, and every boundary, in verifiable detail.

Questions & Answers

Clear answers to the hard questions — starting with why privacy is a fundamental right, not a feature.

Articles

Practical writing on key ownership, "no master account," and what encryption strength really means.

Convinced the model matters?

Sharp#Soft launches in 2026, Windows first. Leave your address and we'll tell you the moment it's ready — nothing else, ever.

Get notified at launch Read the whitepaper