Why?

Object storage is cheap, durable, and ubiquitous — every cloud has it, plus self-hostable options (RustFS, Garage, SeaweedFS) cover the rest. But the tools that put files into object storage tend to be one of:

• Backup tools (restic, borg, kopia) — content-addressed, deduplicated, snapshot-oriented. Restore is "rebuild a point in time," not "keep this folder in sync." One-way, by design.
• Sync utilities (rclone, aws s3 sync) — copy files around. No conflict story, no per-device awareness, no concept of "this device deleted this file vs. this device hasn't seen it yet."
• Peer-to-peer sync (Syncthing, Resilio) — no central store. Devices talk to each other directly. Brilliant when it works; intricate failure modes when devices come and go on different schedules.
• Vendor-managed sync (Dropbox, iCloud, Google Drive) — pleasant until you want your data on storage you control.

Dropbear fills the gap by treating object storage as the synchronization point: every device reads and writes the same bucket, content-addressed blobs deduplicate naturally, and each device publishes its own manifest (full snapshot) plus a head pointing at it. Other devices read each other's heads, fetch the manifests they reference, and reconcile.

What problem is actually being solved

A single person with a few devices (eg laptop, server, phone) wants a folder mirrored across them, with:

• No vendor lock-in. The bucket is yours. The blobs are content-addressed; the manifests are plain JSON. You can leave at any time with a copy of the bucket.
• No bloat. A single static binary. No GUI, no menu-bar helper, no FUSE mount, no proprietary database — your files stay as files on disk, and the daemon is opt-in.
• No "the laptop was offline so we deleted everything." Removable drives, sleeping laptops, and revoked credentials never cause inferred deletions. Deletes are explicit — written as tombstone objects — and never inferred from absence.
• No auto-merge. If two devices edit the same file before reconciling, Dropbear writes a conflict-suffixed copy alongside the local file and lets you sort it out. No silent merges, no last-writer-wins.

What Dropbear is not

• Not a backup tool. Backups need retention policy, snapshot browsing, encryption-at-rest by default, ransomware resistance. Dropbear has none of these (yet). Use restic for backups; use Dropbear for sync. They can target the same bucket.
• Not collaborative. Designed for a single user with multiple devices. While technically possible, the lack of auto-merge makes it impractical for multiple actors to modify the same file.
• Not POSIX-on-S3. Object storage isn't a filesystem. Manifests carry directory state because S3 has no real directories. There's no FUSE mount and there's not going to be one.
• Not realtime. Even with the daemon, the model is "scan, reconcile, sync" — eventually consistent across devices. If you need realtime, you want a different tool.
• Not free. You pay your object-storage provider for bytes and requests. Dropbear is free; the bucket isn't.

Why this and not Syncthing?

Syncthing is excellent and you should consider it. The difference: Syncthing is peer-to-peer and assumes devices are reachable to each other (or via relays). Dropbear assumes a central object store that every device can reach but devices never need to reach each other. That means:

• Your devices don't need to be online at the same time.
• The "trust model" is your bucket credentials, not pairing codes.
• The bucket can outlive any device (and any version of Dropbear).
• Storage cost scales with the data, not with the number of devices.

The trade-off: you pay for object storage; you don't with Syncthing.

Why this and not rclone?

rclone is a great one-way file transfer/synchronization tool for moving local files to cloud storage, but it is not designed as a multi-device conflict-resolving replication system. Using rclone sync independently from multiple devices against the same bucket is unsafe unless you impose your own coordination.