Tesseras

Phase 1: Nodes Find Each Other

2026-02-14

Tesseras is no longer a local-only tool. Phase 1 delivers the networking layer: nodes discover each other through a Kademlia DHT, communicate over QUIC, and publish tessera pointers that any peer on the network can find. A tessera created on node A is now findable from node C.

What was built

tesseras-core (updated) — New network domain types: TesseraPointer (lightweight reference to a tessera's holders and fragment locations), NodeIdentity (node ID + public key + proof-of-work nonce), NodeInfo (identity + address + capabilities), and Capabilities (bitflags for what a node supports: DHT, storage, relay, replication).

tesseras-net — The transport layer, built on QUIC via quinn. The Transport trait defines the port: send, recv, disconnect, local_addr. Two adapters implement it:

The wire protocol uses length-prefixed MessagePack: a 4-byte big-endian length header followed by an rmp-serde payload. WireMessage carries a version byte, request ID, and a body that can be a request, response, or protocol-level error. Maximum message size is 64 KiB.

tesseras-dht — A complete Kademlia implementation:

tesd — A full-node binary. Parses CLI args (bind address, bootstrap peers, data directory), generates a PoW-valid node identity, binds a QUIC endpoint, bootstraps into the network, and runs the DHT engine. Graceful shutdown on Ctrl+C via tokio signal handling.

Infrastructure — OpenTofu configuration for two Hetzner Cloud bootstrap nodes (cx22 instances in Falkenstein, Germany and Helsinki, Finland). Cloud-init provisioning script creates a dedicated tesseras user, writes a config file, and sets up a systemd service. Firewall rules open UDP 4433 (QUIC) and restrict metrics to internal access.

Testing — 139 tests across the workspace:

Architecture decisions

What comes next

Nodes can find each other. Next, they learn to keep each other's memories alive.