Skip to content

Core value

This page states why the Sovereign Family Photo Vault exists, who it is for, and concrete examples for two audiences: people building or operating the stack (developers / technical operators) and people using the product (family members). Technical depth stays in the architecture document and the roadmap.

The promise in one sentence

Your family’s photos stay encrypted with keys you control; copies can live on nodes you trust (two homes, a small VPS), synchronized without handing plaintext to a photo SaaS.

The project is a reference implementation: a Rust node + web UI that proves client-side encryption, policy-aware storage, and trusted-node replication—including WebRTC-friendly paths when signaling and TURN are available—so reachability matches real homes behind NAT.

What “core value” means here

Pillar Meaning
Sovereignty No mandatory central cloud for correctness. Operators choose where nodes run and whom to trust.
Privacy by default The server stores ciphertext; decryption happens where keys live (browser today).
Family-shaped trust Small groups (albums, members, wrapped keys)—not anonymous global scale on day one.
Honest engineering Replication uses shared secrets and HTTP/WebRTC trade-offs are documented—not marketed as formal verification.

Persona: developer / technical operator

Who: software-capable family member, homelab hobbyist, or contributor wiring automation and deployments.

What they care about: reproducible demos, clear APIs, Docker/TURN/signaling setup, tests passing in CI.

Example scenarios

  1. Two-node demo
    Run node A and node B (see repository README), same P2POS_REPLICATE_PSK, add peer URLs, upload a blob from the UI on A, watch replication status until B shows the job completed. Value: proves push replication and queue semantics without a third-party sync service.

  2. E2E compose stack
    Run docker compose under docker/e2e/ (documented in-repo) with signal, coturn, two nodes, nginx UI, Playwright. Value: validates topology (browser isolated from raw node ports), STUN/TURN, and automated regression for the full path.

  3. Transport swap
    Default replication uses HTTP between peers for simplicity; with P2POS_SIGNALING_WS_URL and peer WebRTC IDs, the worker uses p2pos-net (data channel + HTTP fallback). Value: same application framing—reachability upgrades without rewriting album logic.

  4. Extension point
    Implement PeerTransport or tighten blob policy in SQLite—the vault stays an app layer on shared crates. Value: substrate stays reusable for future P2POS apps.

Persona: family user (non-developer)

Who: parent, partner, or relative who wants shared albums without training on SSH.

What they care about: “Our pictures aren’t sitting in someone else’s cloud unencrypted,” backup across two houses, and a simple story: install once, sign in with keys, see photos.

Example scenarios

  1. Two homes
    Mom runs a small PC at House Oak; Dad runs one at House Pine. They add each other as trusted nodes. Mom uploads summer photos from the browser; both houses hold ciphertext copies. If Oak is offline, Pine still has the album for viewing (keys permitting). Value: off-site resilience without subscribing to a photo locker.

  2. No SaaS on the critical path
    The product narrative is: encryption happens before upload; the node never needs photo plaintext for storage. Value: aligns expectations with privacy-first families—even if they still use email or chat for other things.

  3. Shared album with a sibling
    When the UI supports multiple members and wrapped keys (Phase E model), an album AES key can be wrapped for another member’s public key so both can decrypt after signing in. Value: fine-grained sharing inside the family without a shared password for everything.

  4. Honest limits (what users should still expect)
    Someone must run or host nodes (or tunnels). STUN/TURN may be needed for reliability behind strict NAT; that is reachability infrastructure, not “trust us with your keys.” Value: avoids overselling—matches the architecture’s honest infrastructure stance.

How this page relates to other docs

Document Role
Architecture Full technical plan, phases, security audit notes
Roadmap Done vs next in the repo
Core value (this page) Why and for whom, with illustrative—not exhaustive—scenarios

See also

  • Home — documentation landing
  • Roadmap — shipped features and limitations