Dropbear is pre-1.0. This page is the honest list of what isn't done, what's known-broken, and what's deliberately out of scope for now. It's distinct from [Failure Modes](/failure-modes), which covers things Dropbear _is_ designed to handle gracefully — this page is the stuff that's still rough.

## No installer / automatic bootstrap yet

There is no packaged installer — no signed `.app` bundle or `.dmg`, no `.pkg`, no `.deb`/`.rpm`, no Homebrew formula. You build the binary yourself.

`dropbear daemon install` does write and activate a per-user service (a systemd user unit on Linux, a launchd `LaunchAgent` on macOS) and drops a commented-out starter `daemon.toml`, but that's service registration, not distribution. Standing up a new device still means: get the binary onto the machine, set the `DROPBEAR_S3_*` credentials in the environment, and `dropbear register` (or hand-fill a `[roots.init]` block so the daemon self-bootstraps the root on first run). None of that is one-click.

The [desktop tray](/features/desktop-tray)'s start/stop toggle now drives the daemon directly through the OS service manager (`launchctl` on macOS, `systemctl --user` on Linux), so it is no longer a stub — but it still requires the service to have been installed first with `dropbear daemon install`, so it doesn't remove the bootstrap steps above. "v1.0 is when the bootstrap story stops being rough" remains the bar.

## ~~macOS file-watcher exhausts file descriptors on large trees~~ — Fixed

_This gap is closed. The daemon now uses a native [FSEvents](https://developer.apple.com/documentation/coreservices/file_system_events) backend on macOS (`//go:build darwin`). FSEvents watches a root path **recursively in a single call**, holding no per-file or per-directory descriptors. `lsof` confirms the fd count stays constant regardless of how many files are under the root. The kqueue/fsnotify backend — which opened one fd per watched directory and could exhaust `ulimit -n` (256 by default) on a large tree — is still used on Linux and other platforms where it is not a problem._

_The fix is in `internal/fswatch` as of the `macos-fsevents-hint-backend` change. Watcher wakeups remain non-authoritative hints backed by the interval and head-poll backstop, so correctness is unchanged._

## No iOS client

There's an Android viewer (see [Mobile Client](/features/mobile-client)), but no iOS equivalent. iOS's sandboxing — no arbitrary filesystem access, no persistent background daemon, no user-controlled xattrs, files reached only through abstractions like the Files app — makes even a read-only client a much heavier lift than on Android, and it isn't built yet.

## Manifest file is unoptimized

Each device publishes a single `manifest.json` that is a **full snapshot of every tracked path** — relative path, mode, size, hash, symlink target, and so on for the whole root — and it is rewritten and re-uploaded in full on **every** sync, even when one file changed. (This is a deliberate MVP choice; full snapshots are simple to reason about and trivial to verify against the bucket — see the [manifest-full-snapshots](https://git.tfks.net/tfks/dropbear/wiki/decisions/manifest-full-snapshots) and [single-manifest-layout](https://git.tfks.net/tfks/dropbear/wiki/decisions/single-manifest-layout) ADRs.)

The cost shows up on big roots: a manifest for hundreds of thousands of entries is a large JSON object, re-serialized and re-PUT on each sync, and re-fetched by every peer that notices a new head. There's no compression, no delta encoding, and no chunking yet. Candidate directions — none implemented:

- compress the manifest on the wire and at rest;
- publish **deltas** against a base manifest instead of a full snapshot every time;
- split very large roots into chunked manifests so a small change touches a small object.

If your root is enormous and changes constantly, the manifest is currently the most likely thing to feel heavy.