Post-MVP Scope Re-evaluation

Status: Accepted direction for the next implementation cycle Date: 2026-07-15 Scope: Re-evaluation of capabilities previously deferred or excluded

Decision Summary

Capability	Decision
Native installers	Bring in next for the supported desktop platforms.
Desktop GUI	Bring in next, on top of the existing sync and daemon core.
Windows	Bring in conditionally as a bounded platform port after a blocker spike.
Managed hosting	Offer as an optional mode; never make it a requirement for sync or recovery.
Mobile	Build a foreground and opportunistic companion, not a continuously running daemon.
Key-file convenience	Permit only a one-time, targeted, encrypted handoff with confirmation, expiry, replay protection, and no server persistence.
Public DHT/provider records	Keep disabled by default.
Public gossipsub	Keep disabled by default.
Snapshot sync	Use only for bootstrap and recovery while preserving CRDT state, tombstones, and rollback protections.
Public unauthenticated storage	Keep out of scope.
Anonymous networking and full metadata hiding	Keep as research topics, with no delivery commitment.

These decisions do not change the core trust model. Paired devices remain the authority for vault state. Relays, discovery services, mailboxes, object stores, and any managed service remain optional and untrusted for confidentiality and correctness.

Delivery Sequence

0. Preserve Protocol and Security Invariants

Before platform work, document the stable boundary between the reusable Rust core and platform adapters. The core owns membership, authorization, revisions, CRDT merge behavior, tombstones, resources, cryptography, and anti-rollback state. Platform adapters own process lifecycle, paths, atomic persistence, secret storage, IPC, user interaction, and packaging.

Acceptance criteria:

• a platform adapter interface covers filesystem commits, secret storage, IPC, lifecycle notifications, network changes, and user-mediated file access
• existing protocol compatibility and authorization tests run unchanged through the platform-neutral core
• no new mode treats hosted infrastructure as a source of canonical state
• unsupported platform behavior fails closed and produces an actionable error

1. Native Installers and Desktop GUI

Ship native installers for the currently supported desktop operating systems, then ship a desktop GUI that controls the existing service through a narrow, authenticated local interface. Installer work comes first because the GUI must be able to rely on predictable binary locations, upgrades, service lifecycle, configuration directories, and uninstall behavior.

The GUI should cover the normal user journey: initialize or import a vault, start and stop synchronization, pair or revoke a device, inspect connectivity and last-sync state, resolve conflicts, configure optional availability services, and perform explicit recovery operations. It must not duplicate protocol or merge logic in the UI layer.

Acceptance criteria:

• clean-machine install, upgrade, repair, and uninstall tests pass on every supported desktop platform
• packages have reproducible provenance, checksums, platform signing where available, and an upgrade path that preserves vault and rollback state
• upgrades are interruption-tested and cannot leave a partially replaced executable or silently reset configuration, identity, or rollback floors
• the GUI completes import, pairing, sync, conflict resolution, revocation, and recovery against the real daemon/core rather than mocks
• GUI and daemon IPC authenticates the local peer and applies least-privilege permissions
• diagnostics redact vault contents, credentials, key material, capability tokens, and pairing secrets

2. One-Time Key-File Handoff

Add key-file convenience only as an explicit transfer from one authorized device to one identified target device. The sender encrypts the key file to ephemeral target-bound key material and displays exactly what will be sent. The recipient must explicitly confirm receipt before local installation.

Any relay or rendezvous component may forward the encrypted handoff but must not persist it. The transfer has a short expiry, a single-use identifier, sender and recipient binding, authenticated encryption, and durable replay-consumption state on the participating devices. Failure, cancellation, timeout, recipient mismatch, or repeated use invalidates the transfer. This mechanism must never become a general key escrow, backup, account recovery, or server-side key store.

Acceptance criteria:

• sender and recipient both display and confirm the vault and target device
• ciphertext is bound to the intended recipient, vault, transfer identifier, purpose, and expiry
• expired, cancelled, altered, misaddressed, or replayed transfers are rejected
• a successful transfer cannot be consumed a second time, including after process restart
• forwarding services retain no key-file plaintext or ciphertext after the active request ends and expose no retrieval API
• logs, crash reports, metrics, and UI history contain no key-file bytes or decryption material

3. Conditional Windows Port

Treat Windows as a bounded port, not a rewrite and not an open-ended parity promise. Begin with a time-boxed platform spike. Continue only if the spike demonstrates that the existing Rust core can be retained without weakening atomic persistence, secret handling, authorization, or rollback guarantees.

The initial blockers are:

• Atomic replace: define and test Windows replacement, flush, directory handling, sharing-mode, antivirus contention, and crash-recovery semantics; map the current atomic commit contract to supported Windows APIs rather than assuming POSIX rename behavior
• Secret backend: provide a supported per-user secret backend, such as a DPAPI-protected store or an appropriately scoped Windows credential facility, with explicit identity and backup semantics
• IPC and service: replace Unix sockets and Unix service assumptions with ACL-restricted named pipes or an equivalent local transport, and define the split between the Windows Service, interactive user session, and desktop GUI
• CI and package: add Windows build and test runners, fault-injection and restart tests, an MSI or MSIX packaging decision, upgrade/uninstall coverage, and Authenticode signing in the release path

Windows proceeds only when the spike passes the following gate:

• the protocol, KDBX, merge, cryptographic, membership, and rollback core builds without platform forks in those domains
• atomic replacement survives kill and power-loss simulation without accepting partial or older state
• secrets are unavailable to unrelated users and processes under the documented threat model
• service-to-GUI IPC is authenticated, access-controlled, and restart-safe
• a Windows CI lane exercises install, upgrade, daemon/service restart, pairing, two-device sync, conflict convergence, deletion, revocation, and recovery
• the package can be signed, installed, upgraded, and removed without manual cleanup or loss of user data

If the gate fails, keep Windows deferred and record the failed invariant and evidence. Do not broaden the port merely to claim platform support.

4. Optional Managed Hosting

Offer managed relay/AutoNAT, scoped rendezvous, mailbox, and encrypted object storage as an optional operating mode using the same role separation and protocols as self-hosting. Basic direct or relayed peer sync and local recovery must not require an account with the managed service.

Acceptance criteria:

• users can choose no hosted service, self-hosted services, or managed services without changing vault format or device authority
• managed infrastructure cannot decrypt vault content, forge accepted state, bypass membership, or silently roll a client back
• capability issuance, rotation, revocation, quotas, expiry, deletion, and service migration have tested operational flows
• export and provider-exit procedures let a user return to peer-only or self-hosted operation without re-creating the vault
• service outages degrade availability only; local access and direct sync keep working when peers are reachable

5. Foreground and Opportunistic Mobile Companion

Build mobile as a host application around the reusable core. Sync runs while the app is in the foreground and in bounded, platform-approved opportunistic work triggered by connectivity, notifications, explicit user action, or the operating system scheduler. Do not promise an always-on daemon, immediate background propagation, or continuous peer reachability.

The first mobile slice should use private app storage for the managed vault, platform-native secret protection, user-mediated file import/export, lifecycle and network callbacks, and mailbox/object-storage catch-up where configured. Platform-specific discovery and transport limitations must be measured rather than hidden behind desktop assumptions.

Acceptance criteria:

• the product states the foreground and opportunistic availability model accurately and never reports continuous background sync as active
• foreground pairing, sync, conflict resolution, deletion, revocation, and recovery interoperate with supported desktop peers
• bounded background work is idempotent and survives cancellation, process death, network changes, and device restart without state rollback
• secrets use the platform security backend and vault files remain in private app storage except during explicit import or export
• tests cover lifecycle transitions, offline catch-up, scheduler delay, battery restrictions, Wi-Fi/cellular/VPN changes, and interrupted file handoff

Snapshot Bootstrap and Recovery

Snapshot transfer is permitted only to accelerate a new-device bootstrap or an explicit recovery operation. A snapshot is not an opaque KDBX overwrite and is not the normal synchronization protocol. It must carry enough authenticated state to resume normal record/resource synchronization safely.

Acceptance criteria:

• the snapshot is signed and bound to the vault, membership epoch, source head, protocol version, and required resource hashes
• it includes the CRDT metadata and tombstones required to prevent deleted or superseded data from reappearing
• it includes or advances verified rollback floors and can never lower a device’s existing floor
• import verifies membership, signatures, hashes, epochs, completeness, and compatibility before committing any state
• bootstrap installs the snapshot as a verified base and then performs normal head exchange; recovery requires explicit user intent and preserves newer local state or enters a conflict workflow
• stale, incomplete, inconsistent, or rollback-inducing snapshots fail closed
• fault-injection tests cover interruption before and after every durable commit boundary

Defaults and Deferred Research

Public DHT/provider publication and public gossipsub announcements remain disabled by default. Any future opt-in must be separately threat-modeled, clearly expose metadata and abuse tradeoffs, isolate public discovery from authorization, and prove that disabling it restores the private/scoped mode.

Public unauthenticated durable storage remains out of scope. Durable mailbox or object-storage use requires scoped authorization, quotas, expiry or retention rules, and abuse controls.

Anonymous networking and full metadata hiding remain research. Experiments must not be presented as product guarantees and must not delay the installer, GUI, bounded Windows, managed-hosting, or companion work above.

Implementation Process

Implementation should be divided among subagents with narrow ownership and explicit integration contracts. Use separate subagents for platform adapters, packaging and CI, GUI, protocol/security review, and acceptance-test work where the phase warrants it. The coordinating agent remains responsible for invariant tracking, integration, and end-to-end verification.

Code-producing subagents should use gpt-5.3-codex-spark when that model is available. Review-only or research subagents may use the most suitable available model. Every phase must finish with the acceptance evidence recorded before the next conditional scope decision is made.