Principles & Boundaries
trueseal is opinionated. Every choice in the stack traces back to a short list of things we won’t compromise on, and a parallel list of things we deliberately won’t do. Skim both and you’ll know pretty quickly whether trueseal fits what you’re building.
TL;DR
| Principle | What it means |
|---|---|
| Zero Trust | The relay can’t read your data. |
| Anonymity | No accounts, no human identity, no communication graph the server can piece together. |
| Fault Tolerance | Devices drop offline. Networks die. Any device can be gone for a long time and come back current. |
| Guaranteed Delivery | Every blob reaches every group member. Eventually, unconditionally. |
| Revocability | No device gets permanent access. The mechanism matches the threat. |
| No Lock-In | Any relay instance works. Self-host, public, switch around. The security model doesn’t change. |
| Boundary | What we don’t do |
|---|---|
| Not a P2P System | The relay is always in the path. |
| Not a Real-Time Channel | Background sync with strong delivery, not streaming. Sync might be fast, but “fast” isn’t a guarantee we make. |
| Not a Conflict Resolver | We guarantee delivery and order. Conflicts are yours. |
| Not an Identity System | A device is a keypair. Linking it to a human happens above this layer. |
| Not a Durable Log | The relay is a delivery buffer. Blobs are deleted on delivery. |
| Not a Platform | No admins, no hierarchies. If you’re in the group, you’re in. |
Principles
Zero Trust
The relay can’t read your data.
Everything is encrypted on-device before it goes anywhere. The relay receives ciphertext addressed to a recipient’s public key, and that’s all it ever sees. No keys, no plaintext, no idea what it’s routing. Take the binary, dump the database, sniff every packet — you still walk away with encrypted blobs.
This is the only mode there is. There’s no setting that loosens it.
Anonymity
trueseal has no concept of a human identity. No accounts, no registration, nothing to sign up for.
A device is a long-term X25519 keypair, generated locally the first time the SDK runs (or generated by you, if you want to drive it yourself). The public key is the device’s identity inside the protocol. Whoever owns the device is information that never enters the wire.
That extends to metadata. Every push to the relay happens over a short-lived connection opened with a fresh ephemeral keypair. The relay authenticates itself to the sender; the sender never has to authenticate back.
Fault Tolerance
The primitive has to survive the environment it runs in, and the environment is messy.
Phones go in pockets. Wi-Fi drops in tunnels. Laptops sleep for a week. Any device can disappear for an indefinite stretch and come back fully current — that’s the bar.
Undelivered blobs sit in the relay until the recipient reconnects, and they also sit in the sender’s local outbox until the relay confirms delivery. Two safety nets, one on each side.
Guaranteed Delivery
A blob that gets sent reaches every group member. Eventually, no excuses.
Without that, “sync” is misleading. The combination of relay-side hold-for-offline and sender-side outbox replay is what makes it actually true — nothing gets silently dropped because the wrong subset of devices happened to be online at the time.
Revocability
No device gets permanent access. Any current member can remove any other member at any time.
When the threat is mundane — selling a phone, leaving a project — removal is cooperative: the device is dropped from the Group Manifest and its future blobs get filtered out. When the threat is real — a stolen or compromised device — removal is cryptographic: every remaining device rotates its keypair, and the compromised device’s old address becomes a permanent dead end.
The mechanism has to match the threat. Cooperative is fast and cheap. Cryptographic is the nuclear option. Both belong in the toolbox.
No Lock-In
Any deployed relay works. Run your own, use someone else’s, switch tomorrow. The security guarantees don’t depend on who’s operating the infrastructure.
There’s no hosted-only feature, no proprietary extension, no operator (including us) you’re forced to trust.
Boundaries
The things trueseal won’t do, on purpose.
Not a P2P System
Devices don’t talk to each other directly. The relay is always in the middle.
Real peer-to-peer over the open internet means NAT traversal, which means STUN and TURN to punch through home routers, office firewalls and mobile carriers — and when that fails (it fails a lot), TURN is just a relay anyway, wearing a different hat.
The trueseal relay solves the connectivity problem cleanly: outbound connections from both sides, no NAT gymnastics. And because the relay is zero-knowledge, you’re not really paying a privacy cost for the convenience.
Not a Real-Time Channel
No WebSockets, no sub-second delivery promises.
This is background sync with strong delivery guarantees. The design optimises for correctness and privacy. Latency is whatever it happens to be.
Not a Conflict Resolver
We guarantee every device receives every blob, in order. What happens when two offline devices write contradictory things is your call.
trueseal doesn’t pick a winner and it doesn’t merge. It has no opinion on your data model.
Not an Identity System
No accounts. A device is a keypair, full stop. Display names, multi-device accounts, social graphs — all of that lives above this layer.
Not a Durable Log
The relay is a buffer, not storage. Blobs are deleted on delivery.
If your app needs the full history of everything ever sent, keep that locally as messages arrive. The relay is not the archive.
Not a Platform
No admin roles, no permission hierarchies, no hosted-only knobs. Any current member can do anything any other member can do.
If you need an admin who can kick people but can’t be kicked themselves, build that above trueseal. It doesn’t belong in the primitive.