Phase 0: Foundation Laid
-2026-02-14
-The first milestone of the Tesseras project is complete. Phase 0 establishes the -foundation that every future component will build on: domain types, -cryptography, storage, and a usable command-line interface.
-What was built
-tesseras-core — The domain layer defines the tessera format: ContentHash
-(BLAKE3, 32 bytes), NodeId (Kademlia, 20 bytes), memory types (Moment,
-Reflection, Daily, Relation, Object), visibility modes (Private, Circle, Public,
-PublicAfterDeath, Sealed), and a plain-text manifest format that can be parsed
-by any programming language for the next thousand years. The application service
-layer (TesseraService) handles create, verify, export, and list operations
-through port traits, following hexagonal architecture.
tesseras-crypto — Ed25519 key generation, signing, and verification. A -dual-signature framework (Ed25519 + ML-DSA placeholder) ready for post-quantum -migration. BLAKE3 content hashing. Reed-Solomon erasure coding behind a feature -flag for future replication.
-tesseras-storage — SQLite index via rusqlite with plain-SQL migrations.
-Filesystem blob store with content-addressable layout
-(blobs/<tessera_hash>/<memory_hash>/<filename>). Identity key persistence on
-disk.
tesseras-cli — A working tesseras binary with five commands:
-
-
init— generates Ed25519 identity, creates SQLite database
-create <dir>— scans a directory for media files, creates a signed tessera
-verify <hash>— checks signature and file integrity
-export <hash> <dest>— writes a self-contained tessera directory
-list— shows a table of stored tesseras
-
Testing — 67+ tests across the workspace: unit tests in every module, -property-based tests (proptest) for hex roundtrips and manifest serialization, -integration tests covering the full create-verify-export cycle including -tampered file and invalid signature detection. Zero clippy warnings.
-Architecture decisions
--
-
- Hexagonal architecture: crypto operations are injected via trait objects
-(
Box<dyn Hasher>,Box<dyn ManifestSigner>,Box<dyn ManifestVerifier>), -keeping the core crate free of concrete crypto dependencies.
- - Feature flags: the
servicefeature on tesseras-core gates the async -application layer. Theclassicalanderasurefeatures on tesseras-crypto -control which algorithms are compiled in.
- - Plain-text manifest: parseable without any binary format library, with
-explicit
blake3:hash prefixes and human-readable layout.
-
What comes next
-Phase 0 is the local-only foundation. The road ahead:
--
-
- Phase 1: Networking — QUIC transport (quinn), Kademlia DHT for peer -discovery, NAT traversal -
- Phase 2: Replication — Reed-Solomon erasure coding over the network, -repair loops, bilateral reciprocity (no blockchain, no tokens) -
- Phase 3: Clients — Flutter mobile/desktop app via flutter_rust_bridge, -GraphQL API, WASM browser node -
- Phase 4: Hardening — ML-DSA post-quantum signatures, packaging for -Alpine/Arch/Debian/FreeBSD/OpenBSD, CI on SourceHut -
The tessera format is stable. Everything built from here connects to and extends -what exists today.
- -