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.

- -