Phase 2: Memories Survive

2026-02-14

A tessera is no longer tied to a single machine. Phase 2 delivers the +replication layer: data is split into erasure-coded fragments, distributed +across multiple peers, and automatically repaired when nodes go offline. A +bilateral reciprocity ledger ensures fair storage exchange — no blockchain, no +tokens.

What was built

tesseras-core (updated) — New replication domain types: FragmentPlan +(selects fragmentation tier based on tessera size), FragmentId (tessera hash + +index + shard count + checksum), FragmentEnvelope (fragment with its metadata +for wire transport), FragmentationTier (Small/Medium/Large), Attestation +(proof that a node holds a fragment at a given time), and ReplicateAck +(acknowledgement of fragment receipt). Three new port traits define the +hexagonal boundaries: DhtPort (find peers, replicate fragments, request +attestations, ping), FragmentStore (store/read/delete/list/verify fragments), +and ReciprocityLedger (record storage exchanges, query balances, find best +peers). Maximum tessera size is 1 GB.

tesseras-crypto (updated) — The existing ReedSolomonCoder now powers +fragment encoding. Data is split into shards, parity shards are computed, and +any combination of data shards can reconstruct the original — as long as the +number of missing shards does not exceed the parity count.

tesseras-storage (updated) — Two new adapters:

FsFragmentStore — stores fragment data as files on disk +({root}/{tessera_hash}/{index:03}.shard) with a SQLite metadata index +tracking tessera hash, shard index, shard count, checksum, and byte size. +Verification recomputes the BLAKE3 hash and compares it to the stored +checksum.
SqliteReciprocityLedger — bilateral storage accounting in SQLite. Each peer +has a row tracking bytes stored for them and bytes they store for us. The +balance column is a generated column +(bytes_they_store_for_us - bytes_stored_for_them). UPSERT ensures atomic +increment of counters.

New migration (002_replication.sql) adds tables for fragments, fragment plans, +holders, holder-fragment mappings, and reciprocity balances.

tesseras-dht (updated) — Four new message variants: Replicate (send a +fragment envelope), ReplicateAck (confirm receipt), AttestRequest (ask a +node to prove it holds a tessera's fragments), and AttestResponse (return +attestation with checksums and timestamp). The engine handles these in its +message dispatch loop.

tesseras-replication — The new crate, with five modules:

+
Fragment encoding (fragment.rs): encode_tessera() selects the +fragmentation tier based on size, then calls Reed-Solomon encoding for Medium +and Large tiers. Three tiers:
+
- Small (< 4 MB): whole-file replication to r=7 peers, no erasure coding
- Medium (4–256 MB): 16 data + 8 parity shards, distributed across r=7 +peers
- Large (≥ 256 MB): 48 data + 24 parity shards, distributed across r=7 +peers
+
+
Distribution (distributor.rs): subnet diversity filtering limits peers per +/24 IPv4 subnet (or /48 IPv6 prefix) to avoid correlated failures. If all your +fragments land on the same rack, a single power outage kills them all.
+
+
Service (service.rs): ReplicationService is the orchestrator. +replicate_tessera() encodes the data, finds the closest peers via DHT, +applies subnet diversity, and distributes fragments round-robin. +receive_fragment() validates the BLAKE3 checksum, checks reciprocity balance +(rejects if the sender's deficit exceeds the configured threshold), stores the +fragment, and updates the ledger. handle_attestation_request() lists local +fragments and computes their checksums as proof of possession.
+
+
Repair (repair.rs): check_tessera_health() requests attestations from +known holders, falls back to ping for unresponsive nodes, verifies local +fragment integrity, and returns one of three actions: Healthy, +NeedsReplication { deficit }, or CorruptLocal { fragment_index }. The +repair loop runs every 24 hours (with 2-hour jitter) via tokio::select! with +shutdown integration.
+
+
Configuration (config.rs): ReplicationConfig with defaults for repair +interval (24h), jitter (2h), concurrent transfers (4), minimum free space (1 +GB), deficit allowance (256 MB), and per-peer storage limit (1 GB).
+

tesd (updated) — The daemon now opens a SQLite database (db/tesseras.db), +runs migrations, creates FsFragmentStore, SqliteReciprocityLedger, and +FsBlobStore instances, wraps the DHT engine in a DhtPortAdapter, builds a +ReplicationService, and spawns the repair loop as a background task with +graceful shutdown.

Testing — 193 tests across the workspace:

15 unit tests in tesseras-replication (fragment encoding tiers, checksum +validation, subnet diversity, repair health checks, service receive/replicate +flows)
3 integration tests with real storage (full encode→distribute→receive cycle +for medium tessera, small whole-file replication, tampered fragment rejection)
Tests use in-memory SQLite + tempdir fragments with mockall mocks for DHT and +BlobStore
Zero clippy warnings, clean formatting

Architecture decisions

Three-tier fragmentation: small files don't need erasure coding — the +overhead isn't worth it. Medium and large files get progressively more parity +shards. This avoids wasting storage on small tesseras while providing strong +redundancy for large ones.
Owner-push distribution: the tessera owner encodes fragments and pushes +them to peers, rather than peers pulling. This simplifies the protocol (no +negotiation phase) and ensures fragments are distributed immediately.
Bilateral reciprocity without consensus: each node tracks its own balance +with each peer locally. No global ledger, no token, no blockchain. If peer A +stores 500 MB for peer B, peer B should store roughly 500 MB for peer A. Free +riders lose redundancy gradually — their fragments are deprioritized for +repair, but never deleted.
Subnet diversity: fragments are spread across different network subnets to +survive correlated failures. A datacenter outage shouldn't take out all copies +of a tessera.
Attestation-first health checks: the repair loop asks holders to prove +possession (attestation with checksums) before declaring a tessera degraded. +Only when attestation fails does it fall back to a simple ping. This catches +silent data corruption, not just node departure.

What comes next

Phase 3: API and Apps — Flutter mobile/desktop app via +flutter_rust_bridge, GraphQL API (async-graphql), WASM browser node
Phase 4: Resilience and Scale — ML-DSA post-quantum signatures, advanced +NAT traversal, Shamir's Secret Sharing for heirs, packaging for +Alpine/Arch/Debian/FreeBSD/OpenBSD, CI on SourceHut
Phase 5: Exploration and Culture — public tessera browser, institutional +curation, genealogy integration, physical media export

Nodes can find each other and keep each other's memories alive. Next, we give +people a way to hold their memories in their hands.

+ +