Honest positioning —
and the limits, named up front.

We don't hide that you're communicating

Sealing hides the content of a message and who it's addressed to. It cannot hide the simple fact that encrypted traffic is flowing between your device and our infrastructure. Anyone watching the network can see that your device is talking to us, roughly how often, and how much data moves — the same way anyone can see that a sealed envelope was mailed, without reading what's inside.

This is the irreducible minimum of any system that uses a network at all — no privacy product can make the existence of traffic invisible. Sharp#Soft version 1 does not add the extra techniques (padding traffic, randomising timing) that some research systems use to blur even that signal — they carry real costs in speed and bandwidth that our current threat model does not require. If your concern is specifically a network observer correlating traffic timing, know that this version does not defend against it.

We can't recall what an invited recipient already read

Once someone you invited into a conversation has decrypted a message, the sealing has done its job — and the plaintext is now under that person's control, not ours. They can screenshot it, copy it, retype it, or show their screen to someone else. Some products market "self-destructing" or "no-forward" messages as if this were solved. It isn't, anywhere. A determined recipient can defeat any such flag, because the flag is a request to a well-behaved app, not a cryptographic lock. Sharp#Soft may offer these as honest UX signals in later versions — clearly labelled as social conventions, not as enforcement.

Where Sharp#Soft is genuinely stronger is what happens when you remove someone from a shared space. Removal is a real, structural cutoff: the removed person loses access to everything sealed afterward, and — because most people don't decrypt and save every message the moment it arrives — they also lose access to anything they hadn't yet opened at the moment of removal. What remains outside our reach is only the content they had already actively read and exported before you removed them. Choose who you invite into a shared space with that distinction in mind: removal closes the door on the future and on the unread — it does not unsay what was already seen.

We don't solve coercion

This is true of every cryptographic system that has ever existed, and we say it plainly rather than let the rest of this document imply otherwise. If someone is physically forced to unlock their account, hand over a credential, or authorise access under threat, no cryptography protects them — the system correctly opens for whoever holds a valid credential, whether they typed it willingly or under duress. Likewise, a device taken while it is unlocked and in active use is an open session; the protections that exist limit what a later, cold analysis of the device can recover, but they cannot stop someone using an already-unlocked session in front of them.

"Even we cannot read your messages" is true at the level of what Sharp#Soft as an operator can do. It says nothing about what a person with direct, physical coercive power over you can do. Those are different threat models, and we are explicit about which one this architecture defends against. Anyone whose risk includes coercion specifically needs measures outside any single product's reach — physical safety, jurisdictional choices, and operational practices.

We can't fully protect a compromised device

Sharp#Soft runs on your device — a laptop, a desktop, a terminal session. Every guarantee it offers assumes that device is running the software you think it's running, under an operating system that isn't itself hostile. If an attacker has taken over the operating system at its deepest level, they can, in principle, read what's in memory while you're actively using the app, capture keystrokes as you type a credential, or capture the screen as content is displayed. No application-level defence changes what a fully hostile kernel can see.

What Sharp#Soft can do — and does — is make the simpler, more common version of this attack much harder to pull off invisibly: quietly swapping the real client for a fake one. Every release carries a publisher signature so the operating system (or you) can confirm it's genuinely ours. Connecting to our infrastructure requires the client to prove it matches the version we published — a fake or modified client cannot complete that check. We're also building toward a second, independent way to verify a release, and a public page where an attentive user can compare their installed client's fingerprint against the one we published, from a separate device. None of this makes a fully compromised operating system trustworthy — but it makes substituting a fake client for the real one substantially harder to do without being noticed, for a user who checks.

Keeping your operating system patched, avoiding devices of unknown origin, and locking your device when you step away remain your responsibility — no product can take that over for you.

We don't eliminate the metadata needed to run the service

Sealing removes content from what the operator can see. It does not remove every piece of information the service needs to actually function. We hold, by operational necessity: your billing email (needed for subscriptions and account-recovery flows); your connection's IP address while a session is active (any networked service sees this); the fact that a thread or shared space exists and who belongs to it (though the design splits this across separate services so that content remains unreachable without both a service compromise and a cryptographic key); and minimal operational logs kept for diagnosis and abuse detection.

This matters because a well-known real-world case showed exactly why: a privacy-focused email provider with strong content encryption was compelled to retain and disclose connection-IP records, and that single piece of metadata was enough to identify a user — content protection alone hadn't protected them. Our posture is to minimise, not pretend to eliminate: we hold what the service genuinely needs, we don't enrich it with anything else, and where we can split a relationship across two services so neither alone holds the full picture, we do. But metadata that the service needs to operate cannot be made to disappear without breaking the service itself.

Recovery is opt-in — and it changes your posture

Losing your credential with no recovery enabled means no one — including us — can get your account back. That's the strongest form of "you own your keys." Sharp#Soft also offers an opt-in recovery path for people who'd rather trade a small amount of that absolute guarantee for the ability to recover if they lose access. The recovery path is short-lived, gated, and requires your own active participation — it is never an operator-administered reset — but a path is still a path, and a path is a potential point of attack.

We don't claim every user has the same posture. We claim every user has the posture they chose. If a strict "no recovery possible under any circumstance" guarantee matters to you, it's available — simply by not enabling recovery.

Version 1 is not federated

Everything runs under a single operator. There's no protocol yet for a Sharp#Soft deployment run by one party to talk to a Sharp#Soft deployment run by another. Federation would bring real benefits — user choice of operator, resilience if one operator goes down — but it also brings real costs: it reveals which operators are talking to which, and it means your privacy is only as strong as the least trustworthy operator anywhere in the conversation's path. A single-operator model has a smaller, more clearly evaluable trust surface, and that's the trade we've made for version 1. Federation is a longer-term direction, not a version-1 commitment, and we won't announce a timeline until the design is actually ready.

We don't offer formal mathematical proofs

The architecture is auditable: every design decision, every piece of delivered work, and every public claim traces back to evidence a qualified reader can follow and check. That is different from formally verified — a machine-checked mathematical proof that no possible execution of the system can violate a given property. Formal verification is an expensive, highly specialised undertaking that has been done for a small number of narrowly-scoped cryptographic protocols; it is not standard practice for a system of this scope, and it isn't something we claim.

The honest claim is that Sharp#Soft is built to be measured — evaluated against published evidence and observable behaviour — not that it is mathematically proven secure. The distinction is small in wording and large in what each statement actually promises.

No product-level certifications, yet — but the foundations are certified

Sharp#Soft the product does not, at version 1, carry a formal product-level security certification or organisational-process audit. That's a real gap for buyers whose procurement process specifically requires one, and we name it plainly rather than gloss over it — the roadmap for pursuing one is a future direction, not a version-1 commitment.

What we want equally clear: the cryptographic building blocks underneath Sharp#Soft are not garage-invented or proprietary. They are drawn from internationally standardised, independently reviewed cryptographic foundations that have been through years of open scrutiny by cryptographic communities around the world, and the software libraries implementing them carry their own independent validations. A product-level certification is, at its core, a paperwork audit of process and procedure — valuable for a specific kind of procurement gate, but it is not the same thing as cryptographic strength, and it's entirely possible to have one without the other. We'd rather a reader look at both — the certifications we do and don't hold, and the underlying technical architecture — than take either alone as the full picture.