Hi Syncthing Team,
First off, I love the project, I use it every day and couldn’t live without it.
I’m not the first to request selective sync - and to my dismay I’ve seen several previous proposals fizzle out (e.g. #193, #7985, #3940 (there’s a two hyperlink limit LOL).
Those were great suggestions but all kind of worked against SyncThing’s existing functions and would have required substantial work.
I’d like to propose a refined approach to selective sync that builds on previous discussions while addressing some of the architectural and UX concerns that have stalled progress in the past.
Rather than introducing a virtual file system or reworking the sync engine, I’m suggesting surgical per-file “optional” toggle that determines whether a file should be downloaded to a given device.
Here’s what I’m thinking, and I’d love to get this group’s input on feasibility:
If the toggle is enabled, the file syncs as usual.
If disabled, the device
-
Skips the actual file transfer.
-
Writes a placeholder stub (either empty or metadata-only).
-
Marks the file as “synced” locally to avoid repeated attempts.
This preserves folder structure and sync state while giving users control over what gets downloaded.
Past proposals often assumed:
-
A need for full metadata indexing across devices.
-
A virtual file system layer (e.g. SAF on Android or FUSE on Linux).
-
Complex hydration/dehydration logic across platforms.
This proposal avoids those pitfalls by keeping the opt-out decision local to the device, by using a placeholder file to represent skipped content and respecting BEP protocol expectations without disrupting sync logic.
Devices that opt out of syncing a file do not advertise that decision. Other devices continue syncing normally. No metadata leakage occurs, and the opting-out device is treated as “up to date.”
First-Time Setup Flow (Selective Sync Mode)
When a new user installs Syncthing and adds a shared folder, they’re prompted with a simple question:
“Would you like to download all files now, or choose files selectively?”
If they choose selective sync, Syncthing proceeds to sync the full folder structure and metadata—filenames, sizes, timestamps, etc.—but does not download the actual file contents. Instead, each file is internally marked as “declined,” meaning it’s known to the system but not yet hydrated.
This gives the user immediate visibility into the folder without consuming disk space or bandwidth. It also sets the stage for on-demand downloading via the Web UI.
New Web UI Experience (File-Level Control) component required:
• Adding a file browser panel to the Web UI, capable of listing remote files before they’re synced.
• Surfacing per-file metadata (name, size, timestamp) from the sync engine.
• Tracking and displaying the download status of each file.
• Allowing user interaction to trigger hydration (i.e., download on demand).
In the Web UI, the user sees the full folder tree as usual. But files that haven’t been downloaded yet are visually distinct—perhaps grayed out, tagged with a “placeholder” icon, or listed with a status like “Not downloaded.”
Clicking on a file gives the user the option to:
- Download now (hydrating the file)
- Keep as placeholder
This interaction updates the internal toggle for that file. If the user chooses to download, Syncthing begins syncing the file normally. If they leave it declined, the placeholder remains.
No .stignore rules are touched. The existing system handles everything through internal flags and sync logic as is.
Handling Opted-Out Files (Placeholder Strategy)
Files marked as declined are represented locally by placeholder stubs. These could be:
- Empty files with the same name
- Metadata-only files (e.g. JSON or
.syncthing-placeholderextensions) - Read-only or hidden files to prevent accidental modification
These placeholders serve two purposes:
- They preserve the folder structure and give users visibility into what’s available.
- They prevent Syncthing from repeatedly attempting to sync the file, since the system treats them as “intentionally declined.”
Importantly, these placeholders are local-only. Other devices don’t know or care that this device has declined the file. From the network’s perspective, the device is “up to date.”
This approach keeps the UX clean, avoids OS-specific dependencies, and respects Syncthing’s sync model. It also opens the door to future features like “sync on access” or “sync when connected to power/Wi-Fi.”
At least that’s the idea. Copilot helped me with this. Whatever appearance there might be of programming skills is purley machine generated. The fan and appreciation part is real.