Skip to content

Roadmap

This page is the short, maintained view of where the project stands. Deep design, security notes, and historical phase definitions stay in P2POS Sovereign Family Vault architecture (especially §16 phased plan, §12 WebRTC reachability, §12.4 mobile M1/M2).

Done (high level)

Area Status
Phases A–D Node HTTP API, SQLite vault indexes, blob store, peer registry, replication queue + worker, HTTP PeerTransport, internal replicate HMAC, vault-web flows
Phase E Sessions bound to identity + TTL, album membership + wrapped AES keys (X25519-style on client), blob read policy
Phase F Demo scripts, Docker Compose, E2E stack docs
Phase G p2pos-net: WebRTC blob replication (signaling, ICE/STUN/TURN, data channels, HTTP fallback), p2pos-signal, node ingress
Browser (optional) Vault API over WebRTC data channel (p2pos-vault / P2VT tunnel) when built with VITE_VAULT_WEBRTC=1; auth + first GET /v1/nodes stay HTTP
CI cargo test, vault-web tests/build, Docker Compose E2E (signal, coturn, two nodes, nginx, Playwright)

Current limitations (honest)

  • Docker E2E builds the UI with VITE_VAULT_WEBRTC=0 so Playwright uses HTTP for vault calls. Node-to-node replication still uses WebRTC when configured. Reason: replicate and vault signaling paths share ingress on the node and can race in automated CI.
  • Browser vault WebRTC is best-effort / opt-in: needs reachable signaling, working ICE/TURN, and (for production) separate or queued ingress vs replication—not yet fully solved for “always on” vault-over-WebRTC beside heavy replication.
  • Security / ops: demo defaults (shared PSK, CORS, localStorage keys)—see architecture § Security audit and § Gaps before internet-facing deployment.

Next (priority-shaped, not dated)

  1. Ingress architecture — Separate or serialize replicate vs browser vault WebRTC sessions on the node so both can run without tearing down the other; then revisit E2E with VITE_VAULT_WEBRTC=1 if desired.
  2. Phase M1 (mobile, asymmetric) — Phone talks HTTP/WebSocket to home node (LAN or tunnel); home nodes keep WebRTC mesh among themselves (architecture §12.4).
  3. Phase M2 (mobile, symmetric) — Expose p2pos-net to iOS/Android (e.g. UniFFI) or hybrid WebView; mobile as full WebRTC peer.
  4. Product hardening — Strict CORS, httpOnly/sessions, rate limits, TURN ops runbook, optional per-peer replicate secrets (architecture suggested milestones).