Introduction

Tesseras is a peer-to-peer network for preserving human memories across millennia. Each person creates a tessera — a self-contained time capsule of memories (photos, audio, video, text) that survives independently of any software, company, or infrastructure.

What is a tessera?

The word tessera comes from the small tiles used to make mosaics in the ancient world. In Tesseras, each tessera is a collection of memories packaged into a format designed to be understood even thousands of years from now, without any special software.

A tessera contains:

• Memories — photos (JPEG), audio recordings (WAV), video (WebM), and text (plain UTF-8)
• Metadata — when and where each memory was created, who it involves, and what it means
• Identity — cryptographic signatures proving who created it
• Decoding instructions — plain-text explanations of every format used, so future humans can read the contents

Core philosophy

• No company dependency — your memories are yours, stored locally and replicated across a peer-to-peer network
• No format lock-in — every tessera includes instructions for decoding its contents
• Availability over secrecy — public memories are not encrypted, because long-term accessibility matters more than hiding things
• Minimal encryption — only private and sealed content is encrypted; everything else is open
• Quantum-resistant — dual signatures (Ed25519 + ML-DSA) protect integrity even against future quantum computers

Current status: Phase 4

Tesseras has completed through Phase 4 — encryption and sealed tesseras. The project now covers local tessera management, networking, replication, a mobile app, and cryptographic privacy.

What’s available today:

• Identity generation (Ed25519 keypair with proof-of-work)
• Tessera creation from local files
• Content-addressed storage (BLAKE3 hashing)
• Integrity verification and self-contained export
• Full node daemon with QUIC transport
• Peer discovery via Kademlia DHT
• Tessera pointer publishing and lookup across the network
• Reed-Solomon erasure coding with automatic fragment repair
• Flutter mobile app with embedded Rust P2P node
• Private tesseras — encrypted content only the owner can access
• Sealed tesseras — time-locked content that opens after a specific date
• Hybrid post-quantum encryption — X25519 + ML-KEM-768 key encapsulation
• AES-256-GCM content encryption with AAD binding

Key concepts

Installation

Tesseras is currently available by building from source.

Prerequisites

Rust

Tesseras requires Rust 1.85 or higher. The recommended way to install Rust is via rustup:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

After installation, make sure ~/.cargo/bin is in your PATH. The installer usually adds it automatically. Verify with:

rustc --version
cargo --version

If you already have Rust installed, update to the latest version:

rustup update stable

SQLite

Tesseras uses SQLite for local storage. You have two options:

Option 1: System SQLite (recommended)

Install SQLite development libraries via your system package manager:

Option 2: Bundled SQLite

If you prefer not to install SQLite on your system, use the bundled-sqlite feature flag during compilation. This compiles SQLite alongside Tesseras:

cargo install --path crates/tesseras-cli --features bundled-sqlite
cargo install --path crates/tesseras-daemon --features bundled-sqlite

Optional tools

Build from source

Clone the repository and install the binaries:

git clone https://git.sr.ht/~ijanc/tesseras
cd tesseras
cargo install --path crates/tesseras-cli
cargo install --path crates/tesseras-daemon

Or, if you have just installed:

just install

This installs two binaries to ~/.cargo/bin/ and configures shell auto-completions:

• tes — CLI tool for creating, verifying, and exporting tesseras
• tesseras-daemon — full node daemon that participates in the P2P network

Verify installation

tes --help

You should see:

Create and preserve human memories

Usage: tes [OPTIONS] <COMMAND>

Commands:
  init    Initialize identity and local database
  create  Create a tessera from a directory of files
  verify  Verify integrity of a stored tessera
  export  Export tessera to a self-contained directory
  list    List local tesseras
  help    Print this message or the help of the given subcommand(s)

Options:
      --data-dir <DATA_DIR>  Base directory for data storage [default: ~/.tesseras]
  -h, --help                 Print help

Shell completions

The just install command configures completions automatically. If you installed manually, generate completions for your shell:

# Fish
tes completions fish > ~/.config/fish/completions/tes.fish

# Zsh
tes completions zsh > "${XDG_DATA_HOME:-$HOME/.local/share}/zsh/site-functions/_tes"

# Bash
tes completions bash > "${XDG_DATA_HOME:-$HOME/.local/share}/bash-completion/completions/tes"

Flutter App

To build the mobile or desktop app, you need additional dependencies:

Flutter prerequisites

1. Flutter SDK — install following the official guide
2. Rust — already installed as above
3. Platform dependencies:

Build the app

cd apps/flutter
flutter pub get

# Linux desktop
flutter build linux --debug

# Android
flutter build apk --debug

# iOS
flutter build ios --debug

# Tests
flutter test

Or using just from the repository root:

just build-linux    # Linux desktop
just build-android  # Android APK
just test-flutter   # Tests

Network ports

The Tesseras daemon uses QUIC (protocol over UDP). If you are behind a firewall, allow traffic on the port:

Next steps

• Quick Start — create your first tessera
• Running a Node — configure and run the daemon
• Configuration — configuration options
• Docker — run in containers

Quick Start

This tutorial walks you through a complete workflow: creating an identity, building a tessera from files, verifying it, and exporting it.

1. Initialize your identity

First, set up your local identity and database:

tes init

Generated Ed25519 identity
Database initialized
Config written to /home/user/.tesseras/config.toml
Tesseras initialized at /home/user/.tesseras

This creates:

• ~/.tesseras/identity/ — your Ed25519 keypair
• ~/.tesseras/db/ — SQLite database for indexing
• ~/.tesseras/blobs/ — storage for memory files
• ~/.tesseras/config.toml — configuration file

2. Prepare your files

Create a directory with the memories you want to preserve:

mkdir my-memories
cp ~/photos/family-dinner.jpg my-memories/
cp ~/photos/garden.jpg my-memories/
echo "A warm Sunday afternoon with the family." > my-memories/reflection.txt

Supported formats: .jpg, .jpeg, .png (images), .wav (audio), .webm (video), .txt (text).

3. Preview with dry run

See what would be included without creating anything:

tes create my-memories --dry-run

4. Create a tessera

tes create my-memories --tags "family,sunday" --location "Home"

The output includes the content hash — a 64-character hex string that uniquely identifies your tessera. Copy it for the next steps.

5. List your tesseras

tes list

Hash             Created     Memories  Size    Visibility
9f2c4a1b3e7d8f0c 2026-02-14         3  284 KB  public

6. Verify integrity

Use the content hash to verify that all files are intact and the signature is valid:

tes verify 9f2c4a1b3e7d8f0c...

Tessera: 9f2c4a1b3e7d8f0c...
Signature: VALID
  [OK] memories/a1b2c3/media.jpg
  [OK] memories/d4e5f6/media.jpg
  [OK] memories/g7h8i9/media.txt
Verification: PASSED

7. Export a self-contained copy

Export the tessera to a directory that can be read without Tesseras:

tes export 9f2c4a1b3e7d8f0c... ./backup

Exported to ./backup/tessera-9f2c4a1b3e7d8f0c...

8. Inspect the export

The exported directory is fully self-contained:

tessera-9f2c4a1b3e7d8f0c.../
├── MANIFEST                    # Plain text index with checksums
├── README.decode               # How to read this tessera without software
├── identity/
│   ├── creator.pub.ed25519     # Your public key
│   └── signature.ed25519.sig   # Signature of the MANIFEST
├── memories/
│   ├── <hash>/
│   │   ├── media.jpg           # The photo
│   │   ├── context.txt         # Description in plain text
│   │   └── meta.json           # Structured metadata
│   └── .../
└── decode/
    ├── formats.txt             # Explanation of all formats used
    ├── jpeg.txt                # How to decode JPEG
    └── json.txt                # How to decode JSON

Everything a future reader needs to understand the contents is included in the directory itself — no Tesseras software required.

tes init

Initialize identity and local database.

Usage

tes init

Description

Sets up your local Tesseras environment. This is the first command you should run after installing Tesseras.

The command creates:

Options

Idempotent

Running init again is safe. If an identity already exists, it is preserved:

tes init

Ed25519 identity already exists
Database initialized
Tesseras initialized at /home/user/.tesseras

Custom data directory

tes --data-dir /mnt/usb/tesseras init

This creates the full directory structure under /mnt/usb/tesseras/ instead of the default location.

What happens under the hood

1. Creates the directory structure (identity/, db/, blobs/)
2. Generates an Ed25519 keypair (private key stays local, public key identifies you)
3. Runs SQLite migrations to set up the database schema
4. Writes a default config.toml

tes create

Create a tessera from a directory of files.

Usage

tes create <PATH> [OPTIONS]

Arguments

Options

Supported file formats

Files with other extensions are ignored.

Memory type inference

The command automatically assigns a memory type based on the file format:

• Text files (.txt) are classified as Reflection — thoughts, beliefs, or opinions
• All other formats are classified as Moment — a photo, recording, or video of something happening

Examples

Preview before creating

tes create ./my-photos --dry-run

Create with metadata

tes create ./vacation-2026 \
    --tags "vacation,summer,beach" \
    --location "Florianópolis, Brazil" \
    --language pt-BR \
    --visibility public

Non-interactive mode

tes create ./daily-log --non-interactive --tags "daily"

Visibility levels

What happens under the hood

1. Scans the directory for supported files
2. Computes a BLAKE3 hash for each file
3. Assigns a memory type based on file extension
4. Generates a MANIFEST listing all files with their checksums
5. Signs the MANIFEST with your Ed25519 private key
6. Stores the files and metadata in the local database
7. Outputs the content hash that uniquely identifies this tessera

tes verify

Verify integrity of a stored tessera.

Usage

tes verify <HASH>

Arguments

Options

What it checks

1. Signature validity — verifies the Ed25519 signature over the MANIFEST
2. File integrity — recomputes the BLAKE3 hash of every file and compares it against the MANIFEST

Exit codes

Examples

Successful verification

tes verify 9f2c4a1b3e7d8f0cabc123def456789012345678abcdef0123456789abcdef01

Tessera: 9f2c4a1b3e7d8f0cabc123def456789012345678abcdef0123456789abcdef01
Signature: VALID
  [OK] memories/a1b2c3d4/media.jpg
  [OK] memories/e5f6a7b8/media.txt
  [OK] memories/c9d0e1f2/media.wav
Verification: PASSED

Failed verification

If a file has been modified or corrupted:

Tessera: 9f2c4a1b3e7d8f0cabc123def456789012345678abcdef0123456789abcdef01
Signature: VALID
  [OK] memories/a1b2c3d4/media.jpg
  [FAILED] memories/e5f6a7b8/media.txt
  [OK] memories/c9d0e1f2/media.wav
Verification: FAILED

Use cases

• Routine integrity checks — periodically verify that your stored tesseras haven’t been corrupted
• After transfer — verify after copying tesseras to a new device or storage medium
• Trust verification — confirm that a tessera received from someone else hasn’t been tampered with

tes export

Export a tessera as a self-contained directory.

Usage

tes export <HASH> <DEST>

Arguments

Options

Output structure

The export creates a directory named tessera-<hash> inside the destination:

tessera-9f2c4a1b.../
├── MANIFEST                    # Plain text index with checksums
├── README.decode               # Human-readable decoding instructions
├── identity/
│   ├── creator.pub.ed25519     # Creator's public key
│   └── signature.ed25519.sig   # Signature of the MANIFEST
├── memories/
│   ├── <content-hash>/
│   │   ├── media.jpg           # Primary media file
│   │   ├── context.txt         # Human context in plain UTF-8
│   │   └── meta.json           # Structured metadata
│   └── .../
├── schema/
│   └── v1.json                 # JSON schema for metadata validation
└── decode/
    ├── formats.txt             # Explanation of all formats used
    ├── jpeg.txt                # How to decode JPEG
    ├── wav.txt                 # How to decode WAV
    └── json.txt                # How to decode JSON

Example

tes export 9f2c4a1b3e7d8f0cabc123def4567890... ./backup

Exported to ./backup/tessera-9f2c4a1b3e7d8f0cabc123def4567890...

Key feature: self-contained

The exported directory is designed to be readable without Tesseras software. It includes:

• MANIFEST — a plain-text file listing every file with its BLAKE3 checksum, readable by any text editor
• README.decode — human-readable instructions for understanding the contents
• decode/ — detailed explanations of every file format used (JPEG, WAV, JSON, UTF-8)

This means someone thousands of years from now, with no knowledge of Tesseras, can still understand and access the memories.

Use cases

• Backup — export to an external drive, USB stick, or cloud storage
• Sharing — give someone a complete copy of a tessera
• Archival — store on write-once media (DVD, Blu-ray, tape)
• Migration — move tesseras between machines without needing the database

tes list

List all local tesseras.

Usage

tes list

Options

Output

Displays a table with the following columns:

Example

tes list

Hash             Created     Memories  Size    Visibility
9f2c4a1b3e7d8f0c 2026-02-14         3  284 KB  public
a3b7c2d9e4f01823 2026-02-10         1   12 KB  private
f8e7d6c5b4a39201 2026-01-28        12    4 MB  public

Empty database

If no tesseras have been created yet:

tes list

No tesseras found.

Running a Node

The tesseras-daemon binary runs a full Tesseras node that participates in the peer-to-peer network. It listens for connections over QUIC, joins the distributed hash table (DHT), and enables other nodes to discover and find tessera pointers.

Starting the daemon

tesseras-daemon

On first run, the daemon:

1. Creates the data directory (~/.local/share/tesseras on Linux, ~/Library/Application Support/tesseras on macOS)
2. Generates a node identity with proof-of-work (takes about 1 second)
3. Binds a QUIC listener on 0.0.0.0:4433
4. Bootstraps into the network by contacting seed nodes
5. Prints daemon ready when fully operational

Command-line options

tesseras-daemon [OPTIONS]

CLI options override values from the config file.

Examples

Run with defaults (join the public network):

tesseras-daemon

Run as a seed node (no bootstrap, other nodes connect to you):

tesseras-daemon --bootstrap ""

Run on a custom port with a specific data directory:

tesseras-daemon --listen 0.0.0.0:5000 --data-dir /var/lib/tesseras

Bootstrap from a specific node:

tesseras-daemon --bootstrap "192.168.1.50:4433"

Join a local network of multiple nodes:

tesseras-daemon --bootstrap "192.168.1.10:4433,192.168.1.11:4433"

Node identity

Each node has a unique identity stored in <data-dir>/identity.key. This file contains a 32-byte public key and an 8-byte proof-of-work nonce.

The node ID is derived from the public key: BLAKE3(pubkey || nonce) truncated to 20 bytes. The nonce must produce a hash with 8 leading zero bits, which takes about 256 hash attempts. This lightweight proof-of-work makes creating thousands of fake identities expensive while costing legitimate users less than a second.

The identity is generated automatically on first run and reused on subsequent runs. If you delete identity.key, a new identity will be generated.

Logging

The daemon uses structured logging via tracing. Control the log level with the RUST_LOG environment variable:

# Default (info level)
tesseras-daemon

# Debug logging
RUST_LOG=debug tesseras-daemon

# Only show warnings and errors
RUST_LOG=warn tesseras-daemon

# Debug for DHT, info for everything else
RUST_LOG=info,tesseras_dht=debug tesseras-daemon

Shutting down

Press Ctrl+C to initiate graceful shutdown. The daemon will:

1. Stop accepting new connections
2. Finish in-flight operations (up to 5 seconds)
3. Close all QUIC connections
4. Exit cleanly

Firewall

The daemon communicates over UDP port 4433 (QUIC). If you’re behind a firewall, ensure this port is open for both inbound and outbound UDP traffic.

# Example: Linux with ufw
sudo ufw allow 4433/udp

Configuration

The daemon can be configured via a TOML file. Pass the path with --config:

tesseras-daemon --config /etc/tesseras/config.toml

If no config file is given, the daemon uses sensible defaults. CLI options (--listen, --bootstrap, --data-dir) override the corresponding config values.

Full example

[node]
data_dir = "~/.local/share/tesseras"
listen_addr = "0.0.0.0:4433"

[dht]
k = 20
alpha = 3
bucket_refresh_interval_secs = 3600
republish_interval_secs = 3600
pointer_ttl_secs = 86400
max_stored_pointers = 100000
ping_failure_threshold = 3

[bootstrap]
dns_domain = "_tesseras._udp.tesseras.net"
hardcoded = [
    "boot1.tesseras.net:4433",
    "boot2.tesseras.net:4433",
]

[network]
enable_mdns = true

[observability]
metrics_addr = "127.0.0.1:9190"
log_format = "json"

Sections

[node]

Basic node settings.

The default data_dir is ~/.local/share/tesseras on Linux and ~/Library/Application Support/tesseras on macOS.

[dht]

Kademlia DHT tuning parameters. The defaults work well for most deployments.

[bootstrap]

How the node discovers its first peers when joining the network.

[network]

Network-level features.

[observability]

Monitoring and logging.

IPv6 Support

Tesseras supports IPv6 natively. The listen_addr and listen_addrs fields accept both IPv4 and IPv6 addresses.

Listening on IPv6

To listen on all IPv6 interfaces:

[node]
listen_addr = "[::]:4433"

On Linux and most BSDs, binding to [::] also accepts IPv4 connections (dual-stack) by default. On some systems (notably OpenBSD), [::] is IPv6-only due to IPV6_V6ONLY being enabled by default. To guarantee both IPv4 and IPv6 on all platforms, use listen_addrs with explicit addresses:

[node]
listen_addrs = ["0.0.0.0:4433", "[::]:4433"]

For IPv6 loopback only (testing):

[node]
listen_addr = "[::1]:4433"

Bootstrap with IPv6

Bootstrap addresses can be IPv6:

[bootstrap]
hardcoded = [
    "boot1.tesseras.net:4433",
    "[2001:db8::1]:4433",
]

DNS hostnames with both A and AAAA records are resolved to all addresses, so the daemon will connect over whichever protocol is reachable.

IPV6_V6ONLY behavior by OS

If you need explicit control, use listen_addrs with both an IPv4 and IPv6 address.

Minimal config

Most users don’t need a config file at all. If you do, a minimal config overriding only what you need is enough:

[node]
listen_addr = "0.0.0.0:5000"

[bootstrap]
hardcoded = ["192.168.1.10:4433"]

All other values use their defaults.

Network Concepts

This chapter explains how Tesseras nodes find each other and locate tessera pointers on the network. You don’t need to understand these details to use Tesseras, but they help explain what the daemon is doing in the background.

How nodes find each other

Tesseras uses a Kademlia distributed hash table (DHT) — a proven algorithm used by BitTorrent and other P2P systems for over 20 years. There is no central server. Each node maintains a routing table of peers it knows about, and nodes cooperate to route queries to the right place.

When your node starts, it contacts one or more bootstrap nodes (seed nodes with known addresses). Through these initial connections, your node discovers other peers and builds up its routing table. Over time, your node naturally learns about more peers as it participates in the network.

What the DHT stores

The DHT stores pointers, not data. A pointer is a lightweight record that says “tessera X is held by nodes Y and Z.” When someone wants to retrieve a tessera, they first look up its pointer in the DHT to find out which nodes have it, then connect directly to those nodes to download the actual data.

This means the DHT stays small and fast — it only tracks who has what, not the content itself.

Node identity and proof-of-work

Every node has a 160-bit node ID derived from its public key. To prevent an attacker from cheaply creating thousands of fake nodes (a Sybil attack), generating a node ID requires a small proof-of-work: the node must find a nonce such that BLAKE3(public_key || nonce) starts with 8 zero bits.

This takes about 256 hash attempts — under a second on any device, including a Raspberry Pi. But an attacker trying to create 10,000 fake identities would need millions of attempts, making the attack impractical.

XOR distance

Kademlia defines “closeness” between nodes using the XOR metric: the distance between two node IDs is their bitwise XOR. Nodes are responsible for storing pointers whose keys are close to their own ID (in XOR distance). This distributes data evenly across the network without any coordination.

When looking up a tessera pointer, your node asks the peers it knows that are closest to the target key. Those peers point to even closer ones, and so on, until the pointer is found. This iterative lookup typically reaches any node in the network within a few hops.

Transport: QUIC

All communication between nodes uses QUIC, a modern transport protocol built on UDP. QUIC provides:

• Built-in encryption — every connection uses TLS 1.3
• NAT-friendly — works through most network address translators since it’s UDP-based
• Multiplexing — multiple independent operations over one connection without head-of-line blocking
• Connection migration — survives network changes (e.g., switching from Wi-Fi to mobile data)

The daemon listens on UDP port 4433 by default.

Bootstrap process

When a node starts, it follows this sequence:

1. Contact seed nodes — connect to one or more known bootstrap addresses
2. Exchange pings — verify the seed is alive and exchange node identities
3. Self-lookup — ask the seed for nodes close to your own ID, to populate your routing table
4. Iterative discovery — contact the newly discovered nodes, which point you to even more peers

After bootstrap, the node maintains its routing table automatically: it refreshes buckets periodically and replaces unresponsive peers with new ones.

Node types

Not every device participates in the network the same way:

The full node daemon is the backbone of the network. The more full nodes running, the more resilient the network becomes.

Replication and Repair

This chapter explains how Tesseras keeps your memories safe even when individual nodes go offline or suffer hardware failures. You don’t need to understand these details to use Tesseras — the daemon handles everything automatically.

Why replication matters

A tessera stored on a single machine dies when that machine dies. Tesseras solves this by splitting data into fragments, spreading them across multiple peers, and continuously verifying that enough copies exist. If some fragments disappear, the network repairs itself automatically.

Erasure coding

Tesseras uses Reed-Solomon erasure coding to create redundant fragments. The idea is simple: from N data fragments, generate M extra parity fragments. Any N of the N+M total fragments can reconstruct the original data.

This is far more storage-efficient than simple replication. Storing 3 complete copies of a 100 MB file costs 300 MB. With 16 data + 8 parity fragments, you get stronger protection (can lose up to 8 of 24 fragments — 33%) for only 150 MB total.

Fragmentation tiers

Not every tessera is treated the same way. Small files don’t benefit from erasure coding overhead, so Tesseras uses three tiers:

All tiers target a replication factor of 7 — meaning fragments are distributed to 7 different peers.

How distribution works

When you create a tessera and the daemon replicates it, this is what happens:

1. Encode — the tessera data is split into fragments according to its size tier
2. Find peers — the daemon queries the DHT for the closest nodes to the tessera’s hash
3. Subnet diversity — peers are filtered so that no more than a few come from the same network subnet (to avoid correlated failures if a datacenter goes down)
4. Distribute — fragments are pushed to the selected peers in round-robin order
5. Acknowledge — each peer validates the fragment’s checksum and confirms receipt

The tessera owner pushes fragments to peers. Peers don’t pull — this keeps the protocol simple and ensures immediate distribution.

Fragment verification

Every fragment carries a BLAKE3 checksum. When a node receives a fragment, it recomputes the hash and compares it to the expected checksum. If they don’t match, the fragment is rejected. This catches both transmission errors and deliberate tampering.

Fragments are stored in a content-addressable store (CAS) where each unique piece of data exists exactly once on disk, keyed by its BLAKE3 hash. A SQLite reference table maps logical fragment identifiers to CAS hashes, enabling automatic deduplication — if two tesseras share identical fragment data, only one copy is stored. Reference counting ensures data is cleaned up only when no tessera references it.

Repair loop

The daemon runs a background repair loop every 24 hours (with random jitter to avoid network-wide storms). For each tessera it’s responsible for, the repair loop:

1. Requests attestations from known holders — each holder proves it still has the fragments by reporting their checksums
2. Falls back to ping if attestation fails — to distinguish between “node is down” and “node lost the data”
3. Checks local fragments — verifies integrity of any fragments stored locally by recomputing BLAKE3 checksums
4. Decides action:
   • Healthy — all holders responded, all checksums valid, nothing to do
   • Needs replication — some holders are gone, find new peers and redistribute missing fragments
   • Corrupt local — a local fragment has bad data, fetch a replacement from the network

Reciprocity

Tesseras uses a bilateral reciprocity ledger to ensure fair storage exchange. There is no cryptocurrency, no blockchain, no global consensus — each node simply tracks its balance with each peer locally:

peer_a: +500 MB  (they store 500 MB of mine)
peer_b: -200 MB  (I store 200 MB more of theirs than they store of mine)
peer_c:    0 MB  (balanced)

The rules are simple:

• Store 1 GB on the network → you should store roughly 1 GB for others
• Nodes with a positive balance (they store more for you) get priority when you need to distribute new fragments
• Free riders gradually lose redundancy — their fragments are deprioritized for repair, but never deleted
• When receiving a fragment, a node checks the sender’s deficit. If the sender owes too much storage, the fragment is rejected
• Institutional nodes (universities, archives) can operate altruistically with imbalanced ratios

Maximum tessera size

The maximum tessera size is 1 GB. This is a practical limit that keeps fragment sizes manageable and replication fast. For larger collections of memories, create multiple tesseras.

Configuration

The daemon’s replication behavior can be tuned through configuration:

Encryption and Sealed Tesseras

Most tesseras are public — designed to be accessible to anyone, forever. But some memories need privacy. Tesseras supports two encrypted visibility modes:

• Private — only the creator (and their heirs) can ever access the content
• Sealed — the content is time-locked and becomes accessible after a specific date

Public tesseras are never encrypted. Availability is more important than secrecy for preservation.

How encryption works

When you create a private or sealed tessera, the following happens:

1. A random content key (256-bit) is generated
2. Each memory file is encrypted with AES-256-GCM using that content key
3. The content key is wrapped in a sealed key envelope using your encryption public key
4. The wrapped key is stored alongside the encrypted content

Only the holder of the corresponding private key can unwrap the content key and decrypt the content.

Hybrid post-quantum key encapsulation

The sealed key envelope uses a hybrid Key Encapsulation Mechanism (KEM) combining two algorithms:

• X25519 — a well-tested classical elliptic curve key exchange
• ML-KEM-768 — a NIST-standardized post-quantum lattice-based KEM (formerly Kyber)

Both algorithms produce shared secrets that are combined using BLAKE3 key derivation. An attacker must break both algorithms to recover the content key. This follows the same principle as Tesseras’ dual signatures (Ed25519 + ML-DSA): we don’t know which cryptographic assumptions will hold over centuries, so we hedge our bets.

Authenticated associated data (AAD)

AES-256-GCM supports authenticated associated data — extra information that is verified during decryption but not encrypted. Tesseras binds the following into the AAD:

• The content hash of the tessera (always)
• The open_after timestamp (for sealed tesseras only)

This prevents ciphertext swapping attacks: an attacker cannot copy encrypted content from one tessera to another, because the AAD will not match and decryption will fail. For sealed tesseras, this also means you cannot change the seal date — the timestamp is cryptographically bound to the ciphertext.

Sealed tesseras: time capsules

A sealed tessera is a true time capsule. When you create one, you specify an open_after date. The content is encrypted and the key is sealed in an envelope that only you can open.

When the open_after date passes, the owner publishes the content key as a signed Key Publication — a standalone artifact containing the key, the tessera hash, and the owner’s signature. Other nodes can verify the signature and use the published key to decrypt the content.

The tessera’s manifest is never modified. The Key Publication is a separate document, preserving the immutable, content-addressed nature of tesseras.

What about the keys?

Each identity now includes an encryption keypair alongside the signing keypair:

The encryption keypair is generated when the identity is created. The public half is stored in the tessera’s identity directory; the private half stays on the owner’s device.

Design principles

• Encrypt as little as possible — only private and sealed content is encrypted. Public memories stay open for long-term accessibility.
• Dual algorithms from day one — both classical and post-quantum cryptography, so content is protected even if one algorithm is broken.
• Immutable manifests — keys are published separately, never by modifying existing data.
• Fail closed — the system rejects attempts to create private or sealed tesseras without encryption keys.

Heir Key Recovery

Your tesseras can survive infrastructure failures, quantum computers, and centuries of time. But what happens when you can no longer access your own keys? Tesseras uses Shamir’s Secret Sharing to let you distribute your cryptographic identity to trusted heirs.

How it works

Shamir’s Secret Sharing splits a secret into N shares with a threshold T. Any T shares can reconstruct the original secret. Fewer than T shares reveal nothing — this is information-theoretically secure, not just computationally hard to break.

For example, with threshold 2 and 3 total shares:

• Give share 1 to your spouse
• Give share 2 to your sibling
• Give share 3 to your lawyer

Any two of them can recover your identity. A single share alone is useless.

Creating heir shares

tes heir create --threshold 2 --shares 3

This splits your Ed25519 identity key into 3 shares (requiring 2 to reconstruct) and saves them to ./heir-shares/:

heir-shares/
├── heir_share_1.bin   # MessagePack binary
├── heir_share_1.txt   # Human-readable base64 text
├── heir_share_2.bin
├── heir_share_2.txt
├── heir_share_3.bin
└── heir_share_3.txt

Each share is generated in two formats:

• Binary (.bin) — compact MessagePack, suitable for USB drives or digital storage
• Text (.txt) — base64 with human-readable header, suitable for printing on paper

The text format looks like this:

--- TESSERAS HEIR SHARE ---
Format: v1
Owner: a1b2c3d4e5f6a7b8 (fingerprint)
Share: 1 of 3 (threshold: 2)
Session: 9f8e7d6c5b4a3210
Created: 2026-02-15

<base64-encoded data>
--- END HEIR SHARE ---

Reconstructing from shares

When heirs need to recover the identity:

tes heir reconstruct heir_share_1.txt heir_share_2.bin --output-dir ./recovered-keys

The command auto-detects whether each file is binary or text format. It validates that all shares belong to the same session and owner, verifies checksums, and reconstructs the Ed25519 keypair.

To install the recovered keys as the active identity:

tes heir reconstruct share1.txt share2.txt --output-dir ./recovered --install

This backs up the current identity before replacing it.

Inspecting a share

To view metadata about a share without exposing secret data:

tes heir info heir_share_1.txt

Output:

Heir Share Information:
  Format version: 1
  Share: 1 of 3 (threshold: 2)
  Session: 9f8e7d6c5b4a3210
  Owner fingerprint: a1b2c3d4e5f6a7b8
  Share data size: 34 bytes
  Checksum: valid

Security considerations

• Threshold choice: a threshold of 2-of-3 or 3-of-5 is recommended for most people. Higher thresholds are more secure but require more heirs to cooperate.
• Physical storage: print the .txt files on acid-free paper and store in separate physical locations (safe deposit boxes, different homes). Paper survives decades without degradation.
• Never store shares together: the entire point of splitting is distribution. Keeping all shares in one place defeats the purpose.
• Session isolation: each heir create call generates a fresh session ID. Shares from different sessions cannot be mixed — this prevents confusion after key rotations.
• Checksum verification: each share includes a BLAKE3 checksum. Corrupted shares (OCR errors, bit rot) are detected before reconstruction is attempted.
• Re-split after key changes: if you regenerate your identity, create new heir shares and securely destroy the old ones.

Design principles

• Information-theoretic security — T-1 shares reveal exactly zero information about the secret. This is not a computational assumption; it is mathematically proven.
• Corruption detection — BLAKE3 checksums catch bit rot, OCR errors, and truncation before any reconstruction attempt.
• Format resilience — dual output (binary + text) ensures shares survive different storage media failure modes.
• Backward compatibility — the secret blob is versioned, so future versions can include additional key material without breaking existing shares.

NAT Traversal

Most devices on the internet sit behind a NAT (Network Address Translator). Your router assigns your device a private address (like 192.168.1.100) and translates it to a public address when you connect outward. This works fine for browsing the web, but it creates a problem for P2P networks: two devices behind different NATs cannot directly connect to each other without help.

Tesseras solves this with a three-tier approach, trying the cheapest option first:

1. Direct connection — if both nodes have public IPs, they connect directly
2. UDP hole punching — a third node introduces the two peers so they can punch through their NATs
3. Relay — a public-IP node forwards packets between the two peers

NAT type discovery

When a node starts, it sends STUN (Session Traversal Utilities for NAT) requests to multiple public servers. By comparing the external addresses these servers report back, the node classifies its NAT:

Your node advertises its NAT type in DHT Pong messages, so other nodes know whether hole punching is worth attempting.

Hole punching

When node A (behind a Cone NAT) wants to connect to node B (also behind a Cone NAT), neither can directly reach the other. The solution:

1. A sends a PunchIntro message to node I (an introducer — any public-IP node they both know). The message includes A’s external address (from STUN) and an Ed25519 signature proving A’s identity.

2. I verifies the signature and forwards a PunchRequest to B, including A’s address and the original signature.

3. B verifies the signature (proving the request really came from A, not a spoofed source). B then sends a UDP packet to A’s external address — this opens a pinhole in B’s NAT. B also sends a PunchReady message back to A with B’s external address.

4. A sends a UDP packet to B’s external address. Both NATs now have pinholes, and the two nodes can communicate directly.

The entire process takes 2-5 seconds. The Ed25519 signatures prevent reflection attacks, where an attacker replays an old introduction to redirect traffic.

Relay fallback

When hole punching fails (Symmetric NAT, strict firewalls, or corporate networks), nodes fall back to relaying through a public-IP node:

1. A sends a RelayRequest to node R (a public-IP node with relay enabled).
2. R creates a session and sends a RelayOffer to both A and B, containing the relay address and a session token.
3. A and B send their packets to R, prefixed with the session token. R strips the token and forwards the payload to the other peer.

Relay sessions have bandwidth limits:

• 256 KB/s for peers with good reciprocity (they store fragments for others)
• 64 KB/s for peers without reciprocity
• Non-reciprocal sessions are limited to 10 minutes

This encourages nodes to contribute storage — good network citizens get better relay service.

Address migration

When a mobile device switches networks (Wi-Fi to cellular), its IP address changes. Rather than tearing down and rebuilding relay sessions, the node sends a signed RelayMigrate message to update its address in the existing session. This avoids re-establishing connections from scratch.

Configuration

The [nat] section in the daemon config controls NAT traversal:

[nat]
# STUN servers for NAT type detection
stun_servers = ["stun.l.google.com:19302", "stun.cloudflare.com:3478"]

# Enable relay (forward traffic for other NATed peers)
relay_enabled = false

# Maximum simultaneous relay sessions
relay_max_sessions = 50

# Bandwidth limit for reciprocal peers (KB/s)
relay_reciprocal_kbps = 256

# Bandwidth limit for non-reciprocal peers (KB/s)
relay_bootstrap_kbps = 64

# Relay session idle timeout (seconds)
relay_idle_timeout_secs = 60

To run a relay node, set relay_enabled = true. Your node must have a public IP (or a port-forwarded router) to serve as a relay.

Mobile reconnection

When the Tesseras app detects a network change on a mobile device, it runs a three-phase reconnection sequence:

1. QUIC migration (0-2s) — QUIC supports connection migration natively. The app tries to migrate all active connections to the new address.
2. Re-STUN (2-5s) — discover the new external address and re-announce to the DHT.
3. Re-establish (5-10s) — reconnect peers that migration couldn’t save, in priority order: bootstrap nodes first, then nodes holding your fragments, then nodes whose fragments you hold.

The app shows reconnection progress through the NetworkChanged event stream.

Monitoring

NAT traversal exposes Prometheus metrics at /metrics:

• tesseras_nat_type — current detected NAT type
• tesseras_stun_requests_total / tesseras_stun_failures_total — STUN reliability
• tesseras_punch_attempts_total{initiator_nat, target_nat} — punch success rate by NAT pair
• tesseras_relay_sessions_active — current relay load
• tesseras_relay_bytes_forwarded — total relay bandwidth
• tesseras_network_change_total — network change frequency on mobile

Docker

Tesseras provides a Docker image for running the daemon in containers. This is useful for servers, testing multi-node networks, and CI environments.

Building the image

From the repository root:

docker build -t tesseras-daemon .

The multi-stage Dockerfile uses rust:1.85 to compile and debian:bookworm-slim as the runtime base. The resulting image is small and contains only the daemon binary and CA certificates.

Running a single node

docker run -d \
  --name tesseras \
  -p 4433:4433/udp \
  tesseras-daemon

This starts a node that:

• Listens on UDP port 4433
• Bootstraps from the default seed nodes
• Stores data inside the container (ephemeral)

To persist data across container restarts, mount a volume:

docker run -d \
  --name tesseras \
  -p 4433:4433/udp \
  -v tesseras-data:/root/.local/share/tesseras \
  tesseras-daemon

Running as a seed node

To run a seed node that doesn’t bootstrap from anyone else:

docker run -d \
  --name tesseras-seed \
  -p 4433:4433/udp \
  tesseras-daemon --listen 0.0.0.0:4433 --bootstrap ""

Multi-node network with Docker Compose

The repository includes a Docker Compose file for testing a 3-node network:

services:
  boot1:
    build: ../..
    command: ["--listen", "0.0.0.0:4433", "--bootstrap", ""]
    ports: ["4433:4433/udp"]

  boot2:
    build: ../..
    command: ["--listen", "0.0.0.0:4433", "--bootstrap", "boot1:4433"]
    depends_on: [boot1]

  client:
    build: ../..
    command: ["--listen", "0.0.0.0:4433", "--bootstrap", "boot2:4433"]
    depends_on: [boot2]

Start the network:

cd tests/smoke
docker compose up --build -d

Check that all nodes are running:

docker compose logs --tail=5

You should see daemon ready in the logs for each node, and bootstrap successful for boot2 and client.

Stop the network:

docker compose down

Custom configuration

To use a config file with Docker, mount it into the container:

docker run -d \
  --name tesseras \
  -p 4433:4433/udp \
  -v ./config.toml:/etc/tesseras/config.toml:ro \
  -v tesseras-data:/root/.local/share/tesseras \
  tesseras-daemon --config /etc/tesseras/config.toml

See the Configuration chapter for all available options.