Roadmap & Research

trueseal today is a sync primitive: zero-trust, end-to-end encrypted blob delivery between a group of devices. The direction is bigger. We want a composable foundation for encrypted, capability-based replication — something any application can drop in without trusting a server, modelling identity, or rebuilding infrastructure from scratch.

This page has two halves. The first is a near-term roadmap, with concrete, scoped work. The second is a research direction: an unsolved problem we’re working toward. They’re separated on purpose. One is commitment, the other is intent, and I’d rather not blur them.

Near-term

What gets trueseal from v0 to something bigger ecosystems can adopt:

  • More SDKs. A first-class Go SDK first, then whatever demand pulls next. Adding a language is cheap thanks to the Rust core and UniFFI.
  • Reference apps. More integrations beyond trueseal-clip. Apps that exercise real conflict-resolution patterns (CRDTs, append-only logs, custom merge), real bootstrapping flows, real failure modes. These are the docs that prose can’t replace.
  • A public hosted relay. Free, anonymous, for development and prototyping and low-stakes apps. Self-hosting is still the production default — the hosted relay is just the on-ramp.

Research: selective replication

The next architectural step beyond v0. Today every group member receives every blob — full fan-out, no exceptions. The next primitive: a device receives only the blobs it holds a capability for.

The mechanism falls out of the existing addressed-encryption scheme: the recipient key is the capability. Hold the key, decrypt the blob. Don’t, and the blob is noise. No identity system, no ACL, no central authority.

What’s still missing:

  • Object capabilities — a blob addressed to a sub-key rather than a device key. Composes trivially with what’s already there.
  • Topic capabilities — a key that unlocks a whole class of blobs. A namespace, a type, an event stream.
  • Sub-key distribution — how does a device acquire a new capability without a full pairing ceremony and without a central issuer? This is the hard one.

That last bullet is the actual research question. Pairing solves key distribution at a coarse grain. Doing it at a fine grain — without identity, without a central authority, without breaking anonymity — isn’t a solved problem. Every existing approach trips on one of those three:

  • UCAN, Macaroons. Introduce a central issuer.
  • Signal Sender Keys. Break anonymity at the group layer.
  • Application-layer ACL. Punts the problem to the caller, who then re-implements it differently every time.

Fine-grained capability distribution, zero-trust relay, and anonymity — all three at once, in a working primitive — doesn’t exist today as far as I can tell.

If trueseal cracks that, it stops being a library and becomes the encrypted replication layer under everything else. Databases, event systems, collaborative editors, agent coordination — anything that has to move state between parties who shouldn’t have to trust each other.

That’s the direction. Build the primitive, prove it with real apps, then go after the hard one.