Tesseras

Phase 3: Memories in Your Hands

2026-02-14

People can now hold their memories in their hands. Phase 3 delivers what the previous phases built toward: a mobile app where someone downloads Tesseras, creates an identity, takes a photo, and that memory enters the preservation network. No cloud accounts, no subscriptions, no company between you and your memories.

What was built

tesseras-embedded — A full P2P node that runs inside a mobile app. The EmbeddedNode struct owns a Tokio runtime, SQLite database, QUIC transport, Kademlia DHT engine, replication service, and tessera service — the same stack as the desktop daemon, compiled into a shared library. A global singleton pattern (Mutex<Option<EmbeddedNode>>) ensures one node per app lifecycle. On start, it opens the database, runs migrations, loads or generates an Ed25519 identity with proof-of-work node ID, binds QUIC on an ephemeral port, wires up DHT and replication, and spawns the repair loop. On stop, it sends a shutdown signal and drains gracefully.

Eleven FFI functions are exposed to Dart via flutter_rust_bridge: lifecycle (node_start, node_stop, node_is_running), identity (create_identity, get_identity), memories (create_memory, get_timeline, get_memory), and network status (get_network_stats, get_replication_status). All types crossing the FFI boundary are flat structs with only String, Option<String>, Vec<String>, and primitives — no trait objects, no generics, no lifetimes.

Four adapter modules bridge core ports to concrete implementations: Blake3HasherAdapter, Ed25519SignerAdapter/Ed25519VerifierAdapter for cryptography, DhtPortAdapter for DHT operations, and ReplicationHandlerAdapter for incoming fragment and attestation RPCs.

The bundled-sqlite feature flag compiles SQLite from source, required for Android and iOS where the system library may not be available. Cargokit configuration passes this flag automatically in both debug and release builds.

Flutter app — A Material Design 3 application with Riverpod state management, targeting Android, iOS, Linux, macOS, and Windows from a single codebase.

The onboarding flow is three screens: a welcome screen explaining the project in one sentence ("Preserve your memories across millennia. No cloud. No company."), an identity creation screen that triggers Ed25519 keypair generation in Rust, and a confirmation screen showing the user's name and cryptographic identity.

The timeline screen displays memories in reverse chronological order with image previews, context text, and chips for memory type and visibility. Pull-to-refresh reloads from the Rust node. A floating action button opens the memory creation screen, which supports photo selection from gallery or camera via image_picker, optional context text, memory type and visibility dropdowns, and comma-separated tags. Creating a memory calls the Rust FFI synchronously, then returns to the timeline.

The network screen shows two cards: node status (peer count, DHT size, bootstrap state, uptime) and replication health (total fragments, healthy fragments, repairing fragments, replication factor). The settings screen displays the user's identity — name, truncated node ID, truncated public key, and creation date.

Three Riverpod providers manage state: nodeProvider starts the embedded node on app launch using the app documents directory and stops it on dispose; identityProvider loads the existing profile or creates a new one; timelineProvider fetches the memory list with pagination.

Testing — 9 Rust unit tests in tesseras-embedded covering node lifecycle (start/stop without panic), identity persistence across restarts, restart cycles without SQLite corruption, network event streaming, stats retrieval, memory creation and timeline retrieval, and single memory lookup by hash. 2 Flutter tests: an integration test verifying Rust initialization and app startup, and a widget smoke test.

Architecture decisions

• Embedded node, not client-server: the phone runs the full P2P stack, not a thin client talking to a remote daemon. This means memories are preserved even without internet. Users with a Raspberry Pi or VPS can optionally connect the app to their daemon via GraphQL for higher availability, but it's not required.
• Synchronous FFI: all flutter_rust_bridge functions are marked #[frb(sync)] and block on the internal Tokio runtime. This simplifies the Dart side (no async bridge complexity) while the Rust side handles concurrency internally. Flutter's UI thread stays responsive because Riverpod wraps calls in async providers.
• Global singleton: a Mutex<Option<EmbeddedNode>> global ensures the node lifecycle is predictable — one start, one stop, no races. Mobile platforms kill processes aggressively, so simplicity in lifecycle management is a feature.
• Flat FFI types: no Rust abstractions leak across the FFI boundary. Every type is a plain struct with strings and numbers. This makes the auto-generated Dart bindings reliable and easy to debug.
• Three-screen onboarding: identity creation is the only required step. No email, no password, no server registration. The app generates a cryptographic identity locally and is ready to use.

What comes next

• Phase 4: Resilience and Scale — Advanced NAT traversal (STUN/TURN), Shamir's Secret Sharing for heirs, sealed tesseras with time-lock encryption, performance tuning, security audits, OS packaging for Alpine/Arch/Debian/FreeBSD/OpenBSD
• Phase 5: Exploration and Culture — Public tessera browser by era/location/theme/language, institutional curation, genealogy integration, physical media export (M-DISC, microfilm, acid-free paper with QR)

The infrastructure is complete. The network exists, replication works, and now anyone with a phone can participate. What remains is hardening what we have and opening it to the world.