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

- - - - - - - - - - - - - - - - -

Concept	Description
Tessera	A self-contained time capsule of memories
Memory	A single item (photo, recording, video, or text) within a tessera
Content hash	A BLAKE3 hash that uniquely identifies a tessera by its contents
Visibility	Controls who can access a tessera: public, private, sealed, or circle
Sealed tessera	A time capsule that can only be opened after a specific date
MANIFEST	A plain-text index listing every file in the tessera with its checksum
Memory type	Categorizes a memory: moment, reflection, daily, relation, or object
Node	A device running the Tesseras daemon, participating in the P2P network
DHT	Distributed hash table — how nodes find tessera pointers without a central server
Bootstrap	The process of joining the network by contacting known seed nodes

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:

- - - - - - - - - - - - - -

Distribution	Command
Arch Linux	`sudo pacman -S sqlite`
Debian / Ubuntu	`sudo apt install libsqlite3-dev`
Fedora	`sudo dnf install sqlite-devel`
Alpine	`apk add sqlite-dev`
macOS (Homebrew)	`brew install sqlite`
FreeBSD	`pkg install sqlite3`
OpenBSD	Included in the base system

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

- - - - - - - - - - -

Tool	Purpose	Installation
just	Run project build commands	`cargo install just`
mdBook	Build the documentation	`cargo install mdbook`
Docker	Run nodes in containers	See Docker
Flutter	Build the mobile/desktop app	See Flutter App

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

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

- - - - - - - - - - -

Platform	Dependencies
Android	Android SDK, Android NDK, Java 17+
iOS	Xcode, CocoaPods
Linux desktop	GTK 3.0+, pkg-config (`sudo apt install libgtk-3-dev pkg-config` on Debian/Ubuntu)
macOS desktop	Xcode Command Line Tools

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:

- - - - - - - -

Protocol	Port	Direction
UDP	4433	Inbound and outbound

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:

- - - - - - - - - - -

Path	Contents
`~/.tesseras/identity/`	Ed25519 keypair for signing tesseras
`~/.tesseras/db/`	SQLite database for indexing
`~/.tesseras/blobs/`	Blob storage for memory files
`~/.tesseras/config.toml`	Configuration file

Options

- - - - - - - -

Option	Description
`--data-dir <PATH>`	Base directory for data storage (default: `~/.tesseras`)

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

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

tes create

Create a tessera from a directory of files.

Usage

tes create <PATH> [OPTIONS]
-

Arguments

- - - - - - - -

Argument	Description
`<PATH>`	Directory containing files to include

Options

- - - - - - - - - - - - - -

Option	Description	Default
`-n, --non-interactive`	Skip prompts	off
`--dry-run`	Preview what would be included	off
`--visibility <VALUE>`	Visibility level: `public`, `private`, `circle`	`public`
`--language <CODE>`	Language code (e.g., `en`, `pt-BR`)	`en`
`--tags <LIST>`	Comma-separated tags	none
`--location <DESC>`	Location description	none
`--data-dir <PATH>`	Base directory for data storage	`~/.tesseras`

Supported file formats

- - - - - - - - - - - -

Extension	Type	Memory type
`.jpg`, `.jpeg`	Image (JPEG)	Moment
`.png`	Image (PNG)	Moment
`.wav`	Audio (WAV PCM)	Moment
`.webm`	Video (WebM)	Moment
`.txt`	Plain text (UTF-8)	Reflection

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

- - - - - - - - - -

Level	Who can access
`public`	Anyone (default)
`private`	Only you (and designated heirs)
`circle`	Explicitly chosen people

What happens under the hood

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

tes verify

Verify integrity of a stored tessera.

Usage

tes verify <HASH>
-

Arguments

- - - - - - - -

Argument	Description
`<HASH>`	Tessera content hash (64 hex characters)

Options

- - - - - - - -

Option	Description
`--data-dir <PATH>`	Base directory for data storage (default: `~/.tesseras`)

What it checks

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

Exit codes

- - - - - - - - -

Code	Meaning
`0`	Verification passed — all files intact, signature valid
`1`	Verification failed — corrupted files or invalid signature

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

- - - - - - - - -

Argument	Description
`<HASH>`	Tessera content hash (64 hex characters)
`<DEST>`	Destination directory

Options

- - - - - - - -

Option	Description
`--data-dir <PATH>`	Base directory for data storage (default: `~/.tesseras`)

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

- - - - - - - -

Option	Description
`--data-dir <PATH>`	Base directory for data storage (default: `~/.tesseras`)

Output

Displays a table with the following columns:

- - - - - - - - - - - -

Column	Description
Hash	First 16 characters of the content hash
Created	Creation date (YYYY-MM-DD)
Memories	Number of memories in the tessera
Size	Total size (B, KB, MB, or GB)
Visibility	Visibility level (public, private, or circle)

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:

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

Command-line options

tesseras-daemon [OPTIONS]
-

- - - - - - - - - - -

Option	Description	Default
`-c, --config <PATH>`	Path to a TOML config file	None (uses built-in defaults)
`-l, --listen <ADDR>`	Address and port to listen on	`0.0.0.0:4433`
`-b, --bootstrap <ADDRS>`	Comma-separated bootstrap addresses	`boot1.tesseras.net:4433,boot2.tesseras.net:4433`
`-d, --data-dir <PATH>`	Data directory	Platform-specific (see above)

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:

Stop accepting new connections
Finish in-flight operations (up to 5 seconds)
Close all QUIC connections
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.

- - - - - - - - -

Key	Type	Default	Description
`data_dir`	path	Platform-specific	Where to store identity, database, and blobs
`listen_addr`	address	`0.0.0.0:4433`	QUIC listener address

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.

- - - - - - - - - - - - - -

Key	Type	Default	Description
`k`	integer	`20`	Maximum entries per routing table bucket
`alpha`	integer	`3`	Parallelism for iterative lookups
`bucket_refresh_interval_secs`	integer	`3600`	How often to refresh routing table buckets (seconds)
`republish_interval_secs`	integer	`3600`	How often to republish stored pointers (seconds)
`pointer_ttl_secs`	integer	`86400`	How long to keep a pointer before it expires (seconds)
`max_stored_pointers`	integer	`100000`	Maximum number of pointers to store locally
`ping_failure_threshold`	integer	`3`	How many consecutive ping failures before removing a peer

`[bootstrap]`

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

- - - - - - - - -

Key	Type	Default	Description
`dns_domain`	string	`_tesseras._udp.tesseras.net`	DNS domain for TXT-record-based peer discovery
`hardcoded`	list of strings	`["boot1.tesseras.net:4433", "boot2.tesseras.net:4433"]`	Fallback bootstrap addresses

`[network]`

Network-level features.

- - - - - - - -

Key	Type	Default	Description
`enable_mdns`	boolean	`true`	Enable local network discovery via mDNS

`[observability]`

Monitoring and logging.

- - - - - - - - -

Key	Type	Default	Description
`metrics_addr`	address	`127.0.0.1:9190`	Address for the Prometheus metrics endpoint
`log_format`	string	`json`	Log output format (`json` or `text`)

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

- - - - - - - - - - - -

OS	`[::]` accepts IPv4?	Notes
Linux	Yes (dual-stack)	`IPV6_V6ONLY` defaults to 0
macOS	Yes (dual-stack)	`IPV6_V6ONLY` defaults to 0
FreeBSD	Yes (dual-stack)	`IPV6_V6ONLY` defaults to 0
OpenBSD	No (IPv6-only)	`IPV6_V6ONLY` always 1
Windows	Yes (dual-stack)	`IPV6_V6ONLY` defaults to 0

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:

Contact seed nodes — connect to one or more known bootstrap addresses
Exchange pings — verify the seed is alive and exchange node identities
Self-lookup — ask the seed for nodes close to your own ID, to populate your routing table
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:

- - - - - - - - - - -

Type	Description	Always on?
Full node	Desktop, server, or Raspberry Pi running `tesseras-daemon`. Participates fully in the DHT and stores data for other nodes.	Yes
Mobile node	Phone or tablet running the Tesseras app. Participates in the DHT when the app is active.	No
Browser node	Web browser running the WASM client. Connects via a relay node. Read-only.	No
IoT node	ESP32 or similar device on the local network. Stores fragments passively, does not participate in the DHT.	Yes

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:

- - - - - - - - - -

Tier	Size	Strategy	Fragments
Small	< 4 MB	Whole-file replication	7 copies of the complete file
Medium	4–256 MB	Reed-Solomon 16+8	16 data + 8 parity = 24 fragments
Large	≥ 256 MB	Reed-Solomon 48+24	48 data + 24 parity = 72 fragments

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:

Encode — the tessera data is split into fragments according to its size tier
Find peers — the daemon queries the DHT for the closest nodes to the tessera’s hash
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)
Distribute — fragments are pushed to the selected peers in round-robin order
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:

Requests attestations from known holders — each holder proves it still has the fragments by reporting their checksums
Falls back to ping if attestation fails — to distinguish between “node is down” and “node lost the data”
Checks local fragments — verifies integrity of any fragments stored locally by recomputing BLAKE3 checksums
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:

- - - - - - - - - - - - -

Parameter	Default	Description
Repair interval	24 hours	How often the repair loop runs
Repair jitter	2 hours	Random delay added to avoid network-wide storms
Concurrent transfers	4	Maximum parallel fragment transfers
Minimum free space	1 GB	Stop accepting fragments below this threshold
Deficit allowance	256 MB	Maximum storage deficit before rejecting a peer’s fragments
Per-peer limit	1 GB	Maximum total storage for any single peer

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:

A random content key (256-bit) is generated
Each memory file is encrypted with AES-256-GCM using that content key
The content key is wrapped in a sealed key envelope using your encryption public key
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:

- - - - - - - - - - -

Key type	Algorithm	Purpose
Ed25519	Classical	Signing manifests and key publications
ML-DSA	Post-quantum	Signing (when enabled)
X25519	Classical	Key encapsulation (encryption)
ML-KEM-768	Post-quantum	Key encapsulation (encryption)

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.

- -

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:

Direct connection — if both nodes have public IPs, they connect directly
UDP hole punching — a third node introduces the two peers so they can punch through their NATs
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:

- - - - - - - - - - -

NAT Type	What it means	Hole punching?
Public	No NAT — your device has a public IP	Not needed
Cone	NAT maps the same internal port to the same external port regardless of destination	Works well (~80%)
Symmetric	NAT assigns a different external port for each destination	Unreliable
Unknown	Could not reach STUN servers	Relay needed

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:

-
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.
-
-
I verifies the signature and forwards a PunchRequest to B, including A’s address and the original signature.
-
-
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.
-
-
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:

A sends a RelayRequest to node R (a public-IP node with relay enabled).
R creates a session and sends a RelayOffer to both A and B, containing the relay address and a session token.
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:

QUIC migration (0-2s) — QUIC supports connection migration natively. The app tries to migrate all active connections to the new address.
Re-STUN (2-5s) — discover the new external address and re-announce to the DHT.
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.

- -

Keyboard shortcuts

Tesseras User Guide