Sharp#Soft
Whitepaper · Chapter 5

Where this is heading —
direction, not commitment.

Everything on this page describes a direction, not a delivered feature or a scheduled date. Sharp#Soft alone decides what advances, in what order, and when. What stands today — the guarantees you can rely on now — lives in the rest of the whitepaper; this chapter is where we say, plainly, what we're heading toward next.

No dates appear on this page. That omission is deliberate, not an oversight.

The near-term direction

Work the architecture is heading toward within its next stretch of versions beyond v1 — grouped by theme, not by a fixed sequence, since much of it proceeds in parallel.

A dedicated file-storage experience

File content is sealed end to end today — that cryptographic property is not something later work adds. What the near-term direction is designed to bring is the feature surface: a first-class way to manage large files, collections, and file-sharing workflows on the Client, brought up to the same polish as messaging and documents already have. If you've seen other products claim "encryption is coming later," note the distinction — here, the sealing already exists; only the dedicated surface for working with it is the near-term addition.

Hardening against network-level attacks

Sharp#Soft does not retain client IP addresses beyond the life of a session today. The direction is to go further: operational detection of misbehaving traffic patterns using a transformed representation of connection data — not a store of plaintext addresses — reversible only by a deliberate, operator-controlled action when a block decision is actually made. Alongside that, the architecture is designed to make its own network endpoints harder to target over time, and to add a lightweight admission step in front of the core fabric so that reaching it at all requires first passing a smaller, more defensible gate.

Every platform that matters, including mobile

v1 ships as a first-class Terminal client and desktop clients for Windows, macOS, and Linux. The direction is to complete parity across those and extend the same Account and Identity model — which already travels with the user rather than living on a single device — to mobile. A conventional web-browser client is explicitly not part of this direction: the trust model that approach requires is one Sharp#Soft continues to avoid.

More ways to verify the client you're running

v1 already code-signs its binaries and checks them at connection time. The direction adds further, independent ways an attentive user can check their own installation: a second published hash reachable through a separate channel, a public page listing the canonical signature for every released version, and a daily-changing visual marker comparable side by side with what's shown inside the client. None of these replace good device hygiene — together they're designed to raise the cost of a silent substitute-client attack.

Organisational deployments — the invariants that won't move

For teams and companies that want to deploy Sharp#Soft under organisational control, the direction is named by four invariants Sharp#Soft is committing to hold regardless of how the mechanism is eventually designed:

  • A user's Account stays theirs — organisational control never overrides personal ownership of the Account itself
  • Any such control is scoped strictly to company-managed clients — never to a person's own device or Account
  • Transparency to the affected user is mandatory, not optional, wherever this applies
  • Access at the organisational level requires multi-party governance — no single administrator holds it alone

The specific mechanism is still taking shape and is held back until it matures — organisations whose own planning depends on this direction are welcome to talk to us directly about what to expect.

Roughly, in order. Nearest: the file-storage surface and the first client-verification additions. Next: platform-parity completion and the first steps of network hardening. Further out: mobile clients, the organisational-control mode, and fuller network-address protection. This ordering is direction, not a schedule — an item that slides past its expected near-term window is simply reclassified as longer-horizon the next time this page is revised, and the current page always supersedes an older reading of it.

The longer-horizon idea: a platform, not just a product

Sharp#Soft's v1 product is the first thing built on its identity-and- cryptographic fabric — not designed to be the only thing. This section describes a genuine, architecturally-supported direction. It is not a deliverable, and the boundary below says exactly what that means.

The fabric underneath Sharp#Soft — the Account, the Identity, the sealing layers, and the transport that carries sealed messages between identities — is built to be operationally separable from any single product surface. The direction is that other software, built by others, could stand on that same fabric and inherit its privacy properties rather than having to re-engineer them from scratch.

Sovereign identity

A builder's users would carry the same Identity, with private keys that never leave their owner. The builder would never hold a password database or the keys to its own users' content.

Operator-blind privacy

Content sealed under the fabric is designed to be unreadable to whoever operates the infrastructure — including a third party building on it. That inherited inability to read is what would let its users trust it.

Sharing without a master key

The fabric's sharing model re-seals content to invited identities rather than granting access through a central authority. A builder would inherit a model with no master key to steal, subpoena, or leak.

Three shapes of integration are captured as directions the platform is heading toward, spanning a spectrum from "build a whole product on the fabric" to "consume a single capability from it": a programmatic surface for developers to build directly against the fabric; a hosted marketplace model where independent vendors could publish services that inherit the same trust model automatically; and narrower, single-capability licensing — illustrated by the idea of a tamper-evident audit trail a third-party platform could emit to, independently verifiable by anyone who checks it, with no requirement to adopt anything else from the fabric.

What makes this different from a conventional developer platform is the direction of trust. Ordinarily, a third party's users must trust both the third party and the platform underneath it, and that underlying platform can, in principle, read everything. The fabric is designed to invert this: a builder would inherit an inability to read its own users' content that it could not easily have built on its own — and that same "cannot read it" property would carry through intact to the builder's own end users. The trust story would not be something the builder manufactures and defends with policy; it would be inherited from the architecture, and it would remain checkable against the same public record the rest of this whitepaper invites you to verify.

On sequencing: opening the fabric to outside builders is a direction we are heading toward after, not before, one or two of our own flagship products are running on it — so that anyone building against it has a working example to compose against, rather than an empty promise. Timing here, as everywhere in this chapter, is Sharp#Soft's call alone.

What this is not

Naming the boundary is what makes the direction above trustworthy rather than a pitch. As of today:

  • Not a commitment. This is strategic direction. Sharp#Soft retains full authority over which parts of it advance, in what order, and on what timeline.
  • Not an available product. There is no developer SDK, no marketplace, and no service-licensing offering today. These are captured ideas, not shipped features.
  • Not a published API. No third-party interface is documented, stable, or open for integration right now. Any such interface would be defined only once this direction is actually triggered.
  • Not a partner program. There is no enrolment, no application process, and no commercial terms for third parties at this time.
  • Not a forecast. This section sizes no market and predicts no revenue.

The direction is genuine, and the architecture is already built in a way that supports it — and it is not yet a product.

← Perspectives All chapters Next: Legality & privacy rights →