Three readers.
Three honest answers.
The same architecture, read from three angles: the person using Sharp#Soft for their own private messages and files, the manager deciding whether it fits their organisation, and the evaluator whose job is to verify a claim, not take it on faith.
Condensed from the whitepaper's dedicated perspective chapters — nothing here goes beyond what's published.
For the everyday user
You don't need a cryptography background to know what's protected, what isn't, and what to do if something goes wrong.
This reading is for someone who wants to use Sharp#Soft for their own conversations, documents, and files — not a security professional, just someone who wants a straight answer to four questions: what does Sharp#Soft actually protect for me, who am I in the system, what happens if I lose my password or change my mind, and what's here today versus still on the way?
Your keys are yours
The keys that protect your messages, documents, and files are created on your own device and sealed under your own credential. They are never sent anywhere in a form anyone else — including Sharp#Soft — could use. We hold only sealed bytes.
Only the invited can read it
When you share a conversation, a document, or a file with specific people, only those people can open it. Not Sharp#Soft. There is no support-desk override, no administrator key, and nothing we can be ordered to hand over except ciphertext.
Both content and contacts are hidden from outsiders
An outside observer of the network can see that your device is talking to Sharp#Soft. That is all. Not what was said, not who else was involved, not even how many people were on the other end.
Who you are — and who can find you
Your identity here is not your email address, your phone number, or your name. It's a long, unguessable string of cryptographic randomness with nothing personal encoded in it. By default, nobody can find you — there is no directory mapping names or emails to identities. You become discoverable only through a deliberate act: someone who already has your identifier reaching you directly, a structured link you chose to share, or opting into keyword search under terms you pick yourself. There is no fourth path.
One account can hold several identities — work, personal, public — and to Sharp#Soft they look like entirely unrelated people. The only place the connection between them exists is inside your own opened account. Keeping your work life and your personal life apart isn't a setting you switch on; it's built into how the identities are structured.
Messaging and shared spaces
A conversation and a shared space for documents or files are built on the same idea: a sealed container with a member list. Content sealed inside it opens for its members, and for no one else. A conversation or space you haven't been invited to can't even be found by an outsider — there's no way to browse or enumerate them.
Adding someone gives them access to what's shared from that point forward — not to everything that came before. And removing someone is where the architecture actually shows its work (see below).
Removing someone — what actually happens. It isn't a permission flag that gets unchecked. The shared space re-keys itself: the removed person's access dies across everything already shared, all at once — not just for new content going forward. Their device also destroys anything it had cached but the person hadn't gotten around to opening yet, so content they technically could have read but hadn't actually seen becomes unreachable too. What none of this can undo: anything the person actively opened and copied out — screenshotted, forwarded, saved — while they were still a member. Once information leaves the app as plain content on someone's device, no cryptography anywhere can recall it. Invite people you'd be comfortable having read what you share while they're a member of the space.
What's sealed — we can't read it
Your messages. Your documents and files. The actual content of every conversation and shared space. This is architecturally out of reach for us, not merely off-limits by policy.
What we still need to run the service
A billing contact if you're a paying subscriber. Your connection's IP address while you're online. Which conversations and spaces exist and who's in them, so messages can be delivered to the right place. We minimise this and never build it out for profiling — but we're honest that some of it has to exist for the service to work at all.
If you lose access to your account
Lost your credential? Your "credential" doesn't have to be a single password — it can be a structured combination of a password, a key file, a biometric, a hardware key, and recovery tokens, arranged however suits your own threat model. Account recovery itself is opt-in and off by default, because that's the strongest privacy posture. If you never turned it on and every factor is lost, nobody — not us, not anyone — can get you back in. That is the direct cost of a system where we genuinely cannot read your data: the same property that protects you from compelled disclosure also means we can't rescue a lost credential. If you did turn recovery on, there's a structured, visible, short-lived recovery flow built from material you set up yourself at enablement — never "support resets your account."
Still have your credential, but want a change of plan? That's a separate question, and the answers are more flexible. You can download a complete copy of everything that's yours, at any time. You can pause your subscription without closing anything. And you can close your account permanently — Sharp#Soft purges its own copy, and you keep whatever you downloaded. If you change your mind later and still hold your credential and your download, you can re-establish service from it yourself. We don't keep a hidden restorable copy behind the scenes — you're the one who holds the authoritative copy.
The honest boundaries
Naming the limits is what makes everything above credible.
- We don't hide that you're using Sharp#Soft — a network observer can see traffic is happening, just not what it contains
- We can't recall content someone already actively opened and exported before being removed — no system can, whatever it claims
- We can't protect you if you're physically coerced into unlocking your own device
- We can't make a device safe that's already compromised by malware — we layer defences against a tampered client, but a hostile operating system is beyond any app's reach
- Turning recovery on trades a small amount of extra attack surface for the ability to get back in — the choice, and the trade-off, are yours
- Version 1 is a desktop product — Windows, macOS, Linux, and a terminal client. Mobile is on the roadmap, not here yet
Today and tomorrow
At launch
End-to-end privacy across messages, documents, and files. Multiple identities in one account. Routing metadata protected at the wire level. Group sharing with no master key. Signed, verified clients. Opt-in recovery. Full data download and account closure. A cross-platform desktop app plus a first-class terminal client.
Direction, next ~12 months
Extending the sealed-storage model to the remaining file-storage flows. Reducing the metadata Sharp#Soft has to hold even further. Mobile clients. Scaling the hosting footprint as the user base grows. Additional layers of client-integrity verification. None of this is a commitment on a date — it's the direction, named honestly.
For the manager
You may not be a security specialist — but you own the consequences of this decision for your organisation.
Most organisational communication tools are built for operational reach — IT needs administrative access for audit, compliance, and support, and that's the right trade-off for most day-to-day traffic. It is the wrong trade-off for a smaller category: legally-privileged conversations, executive-to-executive discussions, sensitive HR matters, source-protected work. Sharp#Soft is built for that smaller, higher-confidentiality category. The question it helps you answer isn't "should we replace our other tools" — it's "do we have conversations that warrant a different tier of confidentiality, and does this architecture fit that tier?"
What changes in your environment
- Sharp#Soft sits alongside your existing tools — it doesn't replace email for company-wide announcements or your usual tool for project meetings
- Each person gets a user-controlled cryptographic identity — not an IT-managed account. The organisation doesn't own it; the person does
- A dedicated channel exists only for the conversations that warrant the higher confidentiality tier
- There's deliberately no integration with your other IT-administered traffic — no directory import, no SSO federation, nothing pushed to your monitoring stack. That separation is part of what makes the confidentiality property real
- It's a per-user desktop install (Windows, macOS, Linux) on a subscription; the billing contact is visible to the operator and kept structurally separate from anyone's cryptographic identity
What it defends against — and what it doesn't
- Passive and active network attacks — interception, tampering, replay
- A compromised or curious infrastructure operator, hosting provider, or insider — none of them hold the keys to your content
- Compelled disclosure of content — there is nothing to hand over except opaque ciphertext
- A single compromised backend service acting alone — no one service holds enough to reconstruct both who's talking and what they said
- Tampering with the shipped client — no confidentiality secret can be recovered by inspecting the app itself
- Coercion of the person themselves — no cryptography protects a user forced to unlock their own device
- A fully compromised endpoint — malware that owns the device can read what the user reads
- A counterpart who already has the plaintext — once someone you invited has decrypted something, it's in their hands
- The bare fact that communication is happening — that traffic exists is visible; its content and participants are not
- Some server-side metadata that has to exist for the service to run — minimised, never eliminated entirely
Identities for organisational use
The natural pattern is a Work identity for professional correspondence, a Personal identity kept separate, and one or more External identities for specific client or partner relationships. These are cryptographically separable — Sharp#Soft sees them as different people, and the link between them lives only inside the individual's own account. The account belongs to the person, not the organisation — there is no corporate-administered account model in version 1. Someone who leaves takes their identities with them; the organisation can remove a departing person from specific shared spaces going forward, but it cannot reach into their account. Shared spaces created for a project can carry their own lifecycle policy — an expiry date, a scheduled teardown when the project ends.
The v1 organisational baseline. In version 1, the organisation has no automatic cryptographic seat in the shared spaces a user creates — that's the strongest privacy posture for the individual, but some organisations will reasonably want to qualify it under their own policy. That's exactly the gap the next item addresses.
What's heading our way — organisational-policy mode
Some organisations — particularly those with regulated record-keeping duties or continuity requirements that can't rely on a departing employee's cooperation — need the organisation itself to retain cryptographic access to work product created on company-managed devices. Version 1 does not offer this; it's a known and openly-named gap. The direction Sharp#Soft is heading is a set of organisational-policy capabilities built on four commitments that won't be compromised along the way:
- The individual's account stays theirs. Organisational policy would operate at the level of who's a member of what — never by the organisation owning or holding a spare key to someone's personal account.
- Strictly scoped to company-managed clients. Any such capability would apply only on devices the organisation itself deploys and controls — never bleeding into a person's personally-installed client or personal use.
- Always visible to the person using it. No silent access, no hidden auto-invitation — anyone on a company-policy client would always know what the organisation can see.
- Organisational access itself requires more than one person's say-so. Whatever represents the organisation's access would be governed by multiple parties, not held by a single individual.
Organisations whose requirements depend on employer-retained access to work product today, on company-managed devices, should evaluate Sharp#Soft against the version 1 baseline described above — and discuss timelines directly with Sharp#Soft.
Who operates it, and the limits on what they can do
Sharp#Soft is operated by Sharp and Soft Development AB. The operator publishes its architecture, its rules and invariants, its claim chain, and its development-history record; signs every client binary it releases; and provides billing and support limited strictly to what it can actually act on — account closure, subscription state, administering a recovery channel for people who opted into one. What the operator does not do: read user content (it can't, by architecture, even with full operational access), hold any master or back-door key, grant decryption under a compelled-disclosure order (there is nothing to grant), modify user data undetected, or reset an account unilaterally.
When someone leaves, loses a credential, or the organisation closes
A person leaves
Their account is theirs; the organisation can't recover or revoke it. It can remove them from shared spaces going forward. If a colleague or a shared project identity was already a co-member of that content, nothing changes for anyone else — no plaintext handover is even needed. If the departing person was the sole organisational holder of some content, in version 1 the only path today is a cooperative handover before they leave; organisational-policy mode is the planned answer for this case.
A person loses their credential
Same rules as for any individual — recoverable only if they opted into recovery ahead of time, or if they kept a local copy they can restore from. If your use case requires that organisational records always remain retrievable, organisational policy needs to require people to enable recovery, or to maintain compliant local backups.
The organisation closes
Account closure purges the operator's copy permanently. Whoever holds a downloaded copy — the individual, or the organisation, if it kept one — retains it. There is no separate operator-held archive to fall back on.
What you can tell your leadership
Say this with confidence
- Content protection that survives a compromised operator, compelled disclosure, and insider misuse — by construction, not by policy
- Routing-metadata protection at the wire level — outsiders can't see who's talking to whom, or about what
- Identity that's separable from your existing IT-managed accounts — a fit for client-privileged and executive-level conversations
- Built entirely on publicly standardised cryptography — nothing invented in-house
- A named, defined corporate and hosting jurisdiction, not an anonymous operator
Name these boundaries honestly
- That communication is happening at all is observable at the network level
- A coerced user can't be protected by cryptography
- A compromised device can be read by whoever compromised it
- Some server-side metadata is unavoidably operator-visible — minimised, not gone
- Recovery is opt-in; decline it and a lost credential is final
- No third-party product-level security certifications yet, though the underlying cryptography is drawn from certified, standardised building blocks
- Version 1 is desktop-only; mobile is on the roadmap
- Version 1 is single-operator (some buyers consider this an advantage — a named, accountable, evaluable operator rather than the trust problem federated systems carry)
- Version 1 doesn't yet give the organisation itself automatic retained access to employee work product on company-managed devices — see above
For the evaluator
A grounding principle: Sharp#Soft is auditable. Sharp#Soft is not open-source. This section is the map of exactly where that line sits.
This reading is for the security professional, the auditor, the technically-literate journalist, or the procurement security team whose job is to assess what Sharp#Soft actually does rather than take a claim at face value. What follows is the verification map: what's publicly available to inspect today, what a deeper look under engagement adds, and what stays internal — and why.
What's public, no engagement required
- This whitepaper itself — the full architectural argument, including the limits
- A traceable claim chain connecting every public statement Sharp#Soft makes down to the specific commitment behind it
- A public register of the architectural rules and invariants the system is built to hold
- A public history of completed engineering work, checked against what was promised
- A public catalog of what's delivered today, what's in progress, and what's still ahead
These cross-reference each other — a claim points to the rule behind it, the rule points to the engineering work that implemented it, the work points to what it delivered. An evaluator who finds a question at any point can follow the thread outward.
What's not public — named honestly
- The implementation source code. It's Sharp#Soft's proprietary intellectual property, not published under any open licence, and not distributed outside the company in any form beyond the narrow, supervised engagements below
- Builds beyond the signed releases — no self-build path, no independent reproducible-build verification in version 1 (that's a named future direction)
- Implementation specifics for a handful of sensitive subsystems — the properties they must hold are published; the exact construction is not, because it isn't necessary for verification
- Signing certificates, deployment material, and other operational secrets — an evaluator can verify that Sharp#Soft signs its releases against a published certificate; the certificate's private material stays with the operator
The principle in one line: publish what supports independent architectural evaluation; keep internal what's proprietary, operationally sensitive, or simply not needed to verify a claim.
Cryptography: published standards, Sharp#Soft-built implementation
Every cryptographic building block Sharp#Soft uses — for encryption, for key exchange, for digital signatures, for turning a password into a key, for hashing — is drawn from a published, peer-reviewed international standard. None of it is invented in-house. The choice of which standard building blocks are used, and why, is documented and open to scrutiny by anyone with the cryptographic background to evaluate it. How those building blocks are assembled into Sharp#Soft's own codebase is proprietary engineering — the same way a published lock design doesn't oblige a manufacturer to publish the blueprint of a specific vault.
How to actually verify a claim
For each class of adversary this architecture is designed against — a passive network observer, an active attacker on the wire, a compromised or curious operator, a compelled legal disclosure order, a tampered client — the verification path is the same shape: follow the claim to the specific architectural commitment behind it, and confirm that the commitment is stated as an invariant the system is built to hold, not a configuration that happens to be set a certain way today. An evaluator who traces the key custody chain for any given piece of protected data — starting from the user's own credential and following it outward — can verify for themselves that the chain never passes through the operator. None of this requires source-code access. Where an evaluator wants a live demonstration rather than a documented trail, that's available under engagement, described next.
If you need to go deeper
1 · Public material
No engagement, no fee, no NDA. Sufficient on its own for a genuine architectural evaluation — this whitepaper, the rules register, the engineering history, and the claim chain.
2 · Demonstration on request
Sharp#Soft demonstrates specific behaviour on a controlled deployment — showing the operator-visibility properties directly, or walking the verification chain interactively — under a time-bounded commercial engagement.
3 · Evaluation run on your behalf
You specify what you want tested; Sharp#Soft's own engineers scope, price, and run the evaluation, then deliver a written report under the engagement's NDA terms.
4 · Supervised code walk-through
The deepest tier: a narrowly-scoped, NDA'd walk-through of specific code paths, with Sharp#Soft engineering present throughout. The source itself is never copied or shipped to the counterparty.
None of the four tiers include shipping source code to a counterparty, an independent build capability, or open-ended access beyond the engagement's agreed scope. That boundary doesn't move for any single counterparty — consistency is what keeps the model workable.
Suggestions are welcome input; the decisions stay Sharp#Soft's. Evaluators, customers, and security researchers are encouraged to suggest directions — build reproducibility, further metadata minimisation, mitigations for traffic analysis, a migration path for post-quantum cryptography, and more. Sharp#Soft reads and weighs every substantive suggestion carefully. It does not, however, hand over control of its own roadmap: what gets built, in what order, and on what timeline remains Sharp#Soft's decision, made against everything else competing for the same engineering attention.
Reporting a security finding
Anyone who discovers a security defect affecting Sharp#Soft users should report it directly, with a reasonable window before any public disclosure. Sharp#Soft commits to acknowledging credible reports promptly, assessing severity, responding with a timeline appropriate to what was found, and coordinating disclosure timing in good faith. There is no cash bug-bounty programme in version 1 — recognition today is editorial credit, named in a security advisory where the reporter agrees to be named. Responsible disclosure, not source-code access, is the channel for this.