Cordy/Cairn
2
1
Fork 0
Code Issues 15 Pull requests Projects Releases Packages Wiki Activity Actions

Desktop sync client — strategic spike #20

New issue
Closed
opened 2026-07-25 16:25:48 +00:00 by Cordy · 1 comment
Cordy commented 2026-07-25 16:25:48 +00:00
Owner
Copy link

Nextcloud/ownCloud's headline feature is a desktop sync client (delta sync, conflict handling). Cairn today offers WebDAV (rclone/Finder/Cyberduck mount) but no true two-way delta-sync.

Spike, not yet an implementation commitment:

  • Options: lean on an existing client (rclone bisync, existing WebDAV sync tools) vs a real delta-sync protocol.
  • Tension with the "storage backend is the source of truth / no DB index" non-goal — delta sync usually wants a change journal.
  • Output: a decision record + scope call before any build.

Biggest strategic gap vs the incumbents.

Nextcloud/ownCloud's headline feature is a desktop **sync** client (delta sync, conflict handling). Cairn today offers WebDAV (rclone/Finder/Cyberduck mount) but no true two-way delta-sync. Spike, not yet an implementation commitment: - Options: lean on an existing client (rclone bisync, existing WebDAV sync tools) vs a real delta-sync protocol. - Tension with the "storage backend is the source of truth / no DB index" non-goal — delta sync usually wants a change journal. - Output: a decision record + scope call before any build. Biggest strategic gap vs the incumbents.
Cordy commented 2026-07-26 17:18:15 +00:00
Author
Owner
Copy link

Decision record (spike, 2026-07-26): bless rclone bisync as the supported sync path; do NOT build a sync client for v0.4/v0.5.

Options considered:

  1. Own sync client (Go, cross-platform tray app). True parity with Nextcloud Desktop, but it is a second product: conflict resolution, delta detection, three OS packagings, code signing (Apple notarization, Windows SmartScreen), auto-update infrastructure, and an endless client-support surface. Nextcloud's desktop client is by far its largest source of sync-corruption bug reports — this is the "slow and unauditable" trap in client form. Rejected for now.

  2. Bless rclone bisync (chosen). rclone is mature, cross-platform, already part of our interop test matrix, and speaks WebDAV natively. bisync gives two-way sync with conflict handling; rclone mount covers the "network drive" want on all three OSes. Cost to us: a documentation page (Cairn remote config incl. app-password, recommended bisync flags, systemd/launchd timer examples) plus periodic interop runs — near-zero code. Limitations to document honestly: no tray UI, resync needed after interrupted runs, polling not push.

  3. OS-native WebDAV mounts (Finder / Explorer). Already supported and tested; fine for online access, but not offline sync — complements 2, doesn't replace it.

Consequences:

  • v0.4 gets a docs/SYNC.md cookbook (rclone bisync + mount recipes) instead of client code; the interop-rclone workflow already guards the underlying surface.
  • Revisit an own client only post-launch if customer demand is real; the honest trigger is "people pay for Cairn but churn over the missing tray app". If that happens, evaluate wrapping rclone's libraries before writing sync logic from scratch.
  • TUS-based sync protocol design stays out of scope — WebDAV is the sync surface.

Closing as decided; the SYNC.md cookbook is small follow-up work I'll include with the next docs pass.

**Decision record (spike, 2026-07-26): bless rclone bisync as the supported sync path; do NOT build a sync client for v0.4/v0.5.** **Options considered:** 1. **Own sync client (Go, cross-platform tray app).** True parity with Nextcloud Desktop, but it is a *second product*: conflict resolution, delta detection, three OS packagings, code signing (Apple notarization, Windows SmartScreen), auto-update infrastructure, and an endless client-support surface. Nextcloud's desktop client is by far its largest source of sync-corruption bug reports — this is the "slow and unauditable" trap in client form. Rejected for now. 2. **Bless `rclone bisync` (chosen).** rclone is mature, cross-platform, already part of our interop test matrix, and speaks WebDAV natively. `bisync` gives two-way sync with conflict handling; `rclone mount` covers the "network drive" want on all three OSes. Cost to us: a documentation page (Cairn remote config incl. app-password, recommended bisync flags, systemd/launchd timer examples) plus periodic interop runs — near-zero code. Limitations to document honestly: no tray UI, resync needed after interrupted runs, polling not push. 3. **OS-native WebDAV mounts** (Finder / Explorer). Already supported and tested; fine for online access, but not offline sync — complements 2, doesn't replace it. **Consequences:** - v0.4 gets a `docs/SYNC.md` cookbook (rclone bisync + mount recipes) instead of client code; the interop-rclone workflow already guards the underlying surface. - Revisit an own client only post-launch if customer demand is real; the honest trigger is "people pay for Cairn but churn over the missing tray app". If that happens, evaluate wrapping rclone's libraries before writing sync logic from scratch. - TUS-based sync protocol design stays out of scope — WebDAV is the sync surface. Closing as decided; the SYNC.md cookbook is small follow-up work I'll include with the next docs pass.
Cordy closed this issue 2026-07-26 17:18:20 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
v0.3.3
v0.3.2
v0.3.1
v0.3.0
v0.2.7
v0.2.6
v0.2.5
v0.2.4
v0.2.3
v0.2.2
v0.2.1
v0.2.0
v0.0.3
v0.0.2
Labels
Clear labels
No items
No labels
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Cordy/Cairn#20
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?