trueseal-relay — Overview

trueseal-relay is the infrastructure layer of the stack. It’s a zero-knowledge delivery buffer that stores and forwards encrypted blobs between devices, and it implements trueseal-protocol on the server side.

What it does

It accepts two kinds of connections from devices:

  • Push Sessions — short-lived, anonymous. A device opens one, drops off one or more blobs addressed to recipient public keys, and closes the connection. The relay stores each blob durably and acknowledges it.
  • Receive Sessions — long-lived, authenticated. A device opens one to receive blobs addressed to it. The relay flushes anything pending immediately on connection, then pushes new blobs as they arrive.

Blobs for offline recipients sit in their Inbox until they reconnect. Delivered blobs are deleted immediately. Anything that exceeds the TTL without ever being delivered gets reaped.

What it doesn’t do

It never decrypts anything, never learns group membership, and never knows who sent what to whom. Routing is by recipient public key. Blob content is never parsed, logged, or examined.

It’s not a durable log. It’s not a database. It’s a delivery buffer — data lives in it only until it reaches the recipient.

Storage

The relay persists accepted blobs durably across crashes and restarts until delivery or TTL expiry. The default backend is SQLite — zero external dependencies, good for single-node self-hosted setups. A Postgres backend is on the roadmap for clustered deployments.

Relay identity

The relay has a long-term X25519 keypair. Connecting devices use this key to verify they’re talking to the right relay before any data moves. The public key has to be distributed to clients out-of-band — trueseal-relay doesn’t handle key discovery. Operators ship it however makes sense: baked into a client binary, published on a landing page, shared as a QR code.

Platforms

Go. Single binary, no runtime dependencies beyond the storage backend. Linux and macOS.

Source

github.com/julianbonomini/trueseal-relay.

Going deeper

Three sub-pages covering session protocols, storage internals, and self-hosting:

  • Sessions — the two session types (Push NK, Receive XX) and their handshake flows.
  • Inbox & TTL — storage model, InboxStore contract, TTL reaping.
  • Deploying — keypair generation, configuration, single-node setup, Docker.