Roadmap
This page describes accepted direction, not released behavior. Current releases target Linux and macOS and ship the synchronization daemon, the CLI, and a read-only desktop status shell.
Items below are planned, proposed, or in progress. They are not available in version 0.2.0unless a release note says otherwise. Roadmap content is not authoritative for released behavior.
Accepted direction
| Capability | Decision |
|---|---|
| Native installers | Next, for the supported desktop platforms. |
| Desktop GUI | Next, on top of the existing sync and daemon core. |
| Windows | Conditional bounded platform port after a blocker spike. |
| Managed hosting | Optional mode only; never required for sync or recovery. |
| Mobile | Foreground and opportunistic companion, not a continuous daemon. |
| Key-file convenience | One-time targeted encrypted handoff with confirmation, expiry, and replay protection. |
| Public DHT and provider records | Keep disabled by default. |
| Public gossipsub | Keep disabled by default. |
| Snapshot sync | Bootstrap and recovery only; preserve CRDT state, tombstones, and rollback protections. |
| Public unauthenticated storage | Out of scope. |
| Anonymous networking and full metadata hiding | Research topics with no delivery commitment. |
Delivery sequence
0. Preserve protocol and security invariants
Document the stable boundary between the reusable Rust core and platform adapters before platform work. The core owns membership, authorization, revisions, merge behavior, tombstones, resources, cryptography, and anti-rollback state. Adapters own process lifecycle, paths, atomic persistence, secret storage, IPC, user interaction, and packaging.
1. Native installers and desktop GUI
Ship native installers first, then a desktop GUI that controls the existing service through a narrow authenticated local interface. The GUI must rely on the real daemon and core, not mocks, and must not duplicate protocol or merge logic.
2. One-time key-file handoff
Add key-file convenience only as an explicit transfer from one authorized device to one identified target device, with ephemeral target-bound key material, an explicit preview, and no server persistence.
3. Platform expansion
A bounded Windows port and mobile companions follow the adapter boundary. Windows release artifacts are not produced yet, and the mobile work is in progress.
The full accepted scope and acceptance criteria are inPost-MVP scope. The KDBX behavior specification is in Full KDBX semantic synchronization.