Product Modes and Roadmap

Status: Implemented roadmap; release-host validation remains Scope: user-facing modes and implementation phase boundaries

Product Modes

Basic

Peer-to-peer sync only.
No mailbox.
No object storage.
Works when devices are online together and reachable.

Better Connectivity

Peer-to-peer sync with scoped discovery, hole punching, and relay fallback.
No durable central storage.
Works across more networks when devices are online together.

Better Offline

Peer-to-peer sync plus mailbox.
Mailbox stores encrypted hints only.
Actual data still requires an online peer or object storage.

Best Offline

Peer-to-peer sync plus mailbox and encrypted object storage.
Devices can catch up even when no other user device is online.

Self-Hosted

User runs relay, rendezvous, mailbox, or object storage on a NAS, home server, or VPS.
The same service separation rules still apply.

Privacy-Heavy

No mailbox.
No hosted object storage.
Direct or relayed peer-to-peer only.
Manual, local, cached, or private discovery.

Production MVP

The production MVP is:

v2 record/resource sync between online paired devices over libp2p, with application-level membership authorization, crash-safe anti-rollback state, and relay fallback.

In the roadmap below, the production MVP consists of Phases 1-3. Phases 4-6 are post-MVP availability and deployment expansions.

Included:

v2-only record/resource sync
local mDNS and cached peer discovery
scoped rendezvous when configured
direct QUIC/TCP dialing
AutoNAT and hole punching when supported
Circuit Relay v2 fallback
application session authorization
signed heads/manifests
tombstone propagation
resource transfer for attachments and custom icons
crash-safe rollback floors
deterministic protocol tests using in-memory transport traits

Excluded:

mailbox service
object storage service
public DHT/provider records by default
public gossipsub head announcements
public proof-of-work mailbox
public unauthenticated durable storage
opaque full-KDBX snapshot sync as the main protocol
mobile background availability guarantees

Phase 1: Online Network Hardening

Deliverables:

phase-1 minimum signed membership artifact
application session handshake
membership document bootstrap during handshake
protocol version negotiation
v2 head exchange over libp2p streams
deterministic in-memory transport tests
unauthorized fetch rejection
relay fallback configuration
relay limits and metrics

Exit criteria:

two online paired devices sync across separate networks through direct or relayed connectivity
non-members cannot fetch vault data
peers fetch and verify the signed membership document before serving vault data
relays remain stateless
app protocol behavior is covered by cargo test

Implementation status: the signed membership handshake, membership-transition bootstrap, hard-cut protocol negotiation, epoch-secret key confirmation, direction-separated request/response authentication, replay protection, unauthorized-fetch rejection, deterministic/runtime transport tests, and restart-safe caching of membership-authorized peer addresses, private epoch-scoped rendezvous discovery, and direct TCP/QUIC transport are implemented. Identify, AutoNAT v2 client assessment, Circuit Relay v2 fallback, and request-safe DCUtR relay-to-direct preference are also implemented with runtime status and in-process topology tests. The packaged bounded Circuit Relay v2 and AutoNAT v2 service, strict configuration, stable identity, OpenMetrics, and systemd system/user units are implemented. The rootless cross-NAT application gate verifies two independent stateful NATs, relay reservation and circuit use, DCUtR upgrade and direct-path preference, attachment propagation, both daemon restarts, deterministic concurrent conflict convergence, signed resolution, and deletion over relay fallback after enforced direct-path loss. The Phase 1 exit criteria are met.

Phase 2: Membership and Rollback Hardening

Deliverables:

full signed membership document lifecycle
default single-admin and opt-in secondary recovery-authority policies
pairing payload format
epoch rotation
revocation behavior
crash-safe anti-rollback persistence
lost-state recovery flow
lost-primary recovery with a distinct recovery Writer and successor Writer

Exit criteria:

revoked devices cannot create accepted future revisions
local state loss cannot silently accept a server-advertised rollback
membership epoch rollback is rejected
pairing does not rely on trusting infrastructure
a prepared vault can replace a lost primary Admin without restoring its private key

Implementation status: complete rollback floors, crash-safe membership adoption, explicit trusted-admin baseline recovery, vault-bound durable initialization evidence, and signed fresh-key replacement of a lost non-admin writer identity are implemented. Local retained-secret reporting and proof-gated pruning cover repository bridges and resource epoch secrets without making revocation wait for cleanup. single-admin-v1 remains the default, with passphrase-encrypted offline backup and vault-bound restoration of its private membership identity. The opt-in recovery-admin-v2 policy additionally keeps a distinct Writer as a constrained secondary authority: with a third Writer it can remove a lost primary, rotate repository and epoch secrets, and promote the third device through a dual-confirmation, exact-head cutover. The recovery authority remains an ordinary Writer, and primary loss is an operator-attested condition rather than a cryptographically provable fact. The Phase 2 exit criteria are met.

Phase 3: v2 Compatibility Completion

Deliverables:

attachment resource transfer
custom icon resource transfer
resource deduplication by payload hash
tombstone retention and compaction rules
equal-version content mismatch rejection
KDBX materialization of remote-created items

Exit criteria:

supported KeePass vaults with attachments and custom icons sync without v1 fallback
local deletes do not resurrect
incomplete resource payloads are rejected before KDBX or encrypted-state commit
all v2 compatibility behavior has focused tests

Implementation status: attachments, custom icons, payload-hash deduplication, tombstone retention, equal-version mismatch rejection, deterministic conflict preservation, and remote-created KDBX materialization are implemented. Resource descriptors and chunks are verified before a revision can be materialized or committed. Signed conflict resolutions are monotonic, and retired encrypted payloads are pruned only after current-epoch historical eligibility disappears. Stale source-file and pruning-plan races fail closed. The Phase 3 exit criteria are met.

Phase 4: Optional Mailbox

Deliverables:

mailbox envelope format
blinded mailbox IDs
capability-token admission
poll/deposit protocol
TTL and quota enforcement
mailbox policy discovery

Exit criteria:

offline devices can later receive encrypted hints
mailbox stores no full vault data
mailbox absence or staleness cannot roll back the client
abuse is bounded by policy

Implementation status: the envelope and capability formats, blinded IDs, bounded durable store, strict libp2p poll/deposit/acknowledgement protocol, policy discovery, dedicated mailbox process, operator commands, and systemd system/user packaging are implemented. Automatic daemon hint deposit/polling, restart-idempotent outbound delivery, retained-epoch polling, and the offline-notification outage/restart E2E are also implemented. The Phase 4 exit criteria are met.

Phase 5: Optional Object Storage

Deliverables:

immutable encrypted object format
manifest/chunk upload and fetch
storage capability tokens
pinning and garbage collection policy
quota enforcement
advisory signed head pointer rules

Exit criteria:

a device can catch up when all other user devices are offline
storage cannot decrypt, forge, modify, or silently roll back accepted state
storage usage is bounded by quotas

Implementation status: epoch-encrypted immutable record/resource bundles, historical conflict records, capability-scoped upload/fetch, pinning, garbage collection, quotas, signed advisory heads, and the dedicated object-storage process are implemented. The daemon publishes bundles alongside mailbox hints and can fetch, verify, and materialize one after every user device that held the new state has gone offline. Restart and stale-redelivery E2E coverage proves that storage remains advisory and cannot roll back accepted local state. The Phase 5 exit criteria are met.

Phase 6: Helper Peers and Self-Hosting

Deliverables:

helper peer mode
NAS/VPS deployment profile
private relay/rendezvous profile
combined mailbox/object-storage deployment guide
observability and admin tools

Exit criteria:

users can self-host availability infrastructure
hosted infrastructure remains optional
service separation is preserved in combined deployments

Implementation status: helper-role replicas, targeted authoritative bootstrap, the isolated rendezvous service with optional peer allowlisting, bounded relay/AutoNAT, mailbox and object-storage processes, system and user self-hosted targets, shared health/readiness/OpenMetrics endpoints, capability administration commands, and the combined deployment/backup guide are implemented. Hosted infrastructure remains optional and each state or trust boundary retains a separate identity, process, state directory, and system account in the hardened system profile. The Phase 6 exit criteria are met.

Implementation Guardrails

Do not expand MVP scope to mailbox or object storage until online v2 sync is correct.
Do not add public DHT or gossipsub defaults before a privacy and abuse review.
Do not accept remote state without signed membership and rollback-floor checks.
Do not let opaque snapshot work bypass v2 tombstone/resource semantics.
Do not require root/admin networking tests for normal cargo test coverage.