#142 - tui: cloud sync — WebDAV manifest tracking for sharing - charles/loom

No milestone

No project

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

charles/loom#142

claude-desktop commented

2026-04-14 20:13:30 +00:00

Collaborator

User story

As a user pushing my gallery to a WebDAV destination (e.g. Nextcloud, CivitAI mirror), I want a sync manifest that tracks which files have been uploaded so re-runs only push deltas, so that I don't waste bandwidth re-uploading everything.

Background

GTK has a complete cloud_sync.rs module (crates/loom-gtk/src/cloud_sync.rs) with manifest load/save, file_needs_upload, record_sync, and WebDAV helpers. The TUI has none of this. The sync manifest format and WebDAV helpers can be ported as-is and exposed via a TUI overlay.

Acceptance criteria

Port `cloud_sync` to loom-core

Move/refactor loom-gtk/src/cloud_sync.rs to loom-core/src/services/cloud_sync.rs (drop GTK deps if any)
Public API: load_manifest(path), save_manifest(path, &manifest), file_needs_upload(manifest, path, mtime), record_sync(manifest, path, remote_url)

Sync overlay

New OverlayKind::CloudSync { destination_id } opens from the Sharing overlay
Lists pending uploads (files not in manifest or with newer mtime than recorded)
Enter starts the sync; progress per file shown with throbber

When the user picks a "WebDAV / CivitAI" sharing target, surface the sync action as the primary CTA
After successful upload, append to the manifest and persist

Settings

Settings → Sharing section gains: WebDAV URL, username, password (stored masked)

Tests

Unit: manifest round-trip preserves entries
Unit: file_needs_upload is true for missing entries and stale mtimes; false for fresh ones

Out of scope

Conflict resolution (overwrite is the only strategy)
Two-way sync (manifest is upload-only)
Multiple destinations per file

References

crates/loom-gtk/src/cloud_sync.rs (port source)
crates/loom-tui/src/components/sharing.rs (overlay to extend)

## User story As a user pushing my gallery to a WebDAV destination (e.g. Nextcloud, CivitAI mirror), I want a sync manifest that tracks which files have been uploaded so re-runs only push deltas, so that I don't waste bandwidth re-uploading everything. ## Background GTK has a complete `cloud_sync.rs` module (`crates/loom-gtk/src/cloud_sync.rs`) with manifest load/save, `file_needs_upload`, `record_sync`, and WebDAV helpers. The TUI has none of this. The sync manifest format and WebDAV helpers can be ported as-is and exposed via a TUI overlay. ## Acceptance criteria ### Port `cloud_sync` to loom-core - [ ] Move/refactor `loom-gtk/src/cloud_sync.rs` to `loom-core/src/services/cloud_sync.rs` (drop GTK deps if any) - [ ] Public API: `load_manifest(path)`, `save_manifest(path, &manifest)`, `file_needs_upload(manifest, path, mtime)`, `record_sync(manifest, path, remote_url)` ### Sync overlay - [ ] New `OverlayKind::CloudSync { destination_id }` opens from the Sharing overlay - [ ] Lists pending uploads (files not in manifest or with newer mtime than recorded) - [ ] `Enter` starts the sync; progress per file shown with throbber ### Sharing overlay integration - [ ] When the user picks a "WebDAV / CivitAI" sharing target, surface the sync action as the primary CTA - [ ] After successful upload, append to the manifest and persist ### Settings - [ ] Settings → Sharing section gains: WebDAV URL, username, password (stored masked) ### Tests - [ ] Unit: manifest round-trip preserves entries - [ ] Unit: `file_needs_upload` is true for missing entries and stale mtimes; false for fresh ones ## Out of scope - Conflict resolution (overwrite is the only strategy) - Two-way sync (manifest is upload-only) - Multiple destinations per file ## References - `crates/loom-gtk/src/cloud_sync.rs` (port source) - `crates/loom-tui/src/components/sharing.rs` (overlay to extend)

claude-desktop added this to the loom-tui v0.1.0 milestone

claude-desktop added the

type:user-story

area:sharing

labels

claude-desktop referenced this issue

2026-04-14 20:14:47 +00:00

tui: tracking — loom-tui v0.1.0 roadmap & implementation order #47