I only skimmed over the new posts, so please excuse me if I don’t perfectly represent some parts or miss others. I just have an urge to comment on the “maintainers this, maintainers that” parts:
I believe maintainers do consider this important, and I know at least one does (I). However that doesn’t really come into it, whether or not something like selective sync happens or not doesn’t depend on what maintainers think of this (beyond that basic “yes, the feature is welcome” stance that you’ll find all over already for this). We are all full-time employed (not to work on syncthing) and we need to deal with all things syncthing (that’s what maintainer means). There’s simply not much time left for us to “do things”, especially not big changes. And besides the churn work, there are also a crapton of “very important” things, this is just one of them. And yes, we tend to prioritise issues both by our goals and our interests/abilities, where the latter admittedly doesn’t lie on the front-end for any of us. So it’s accurate to say that you shouldn’t hold your breath for us to implement this. However there’s already one third-party tool that does it, one beta ios app that does some of it, one alpha quality abandoned attempt at an android app (and java/kotlin BEP implementation), multiple PRs attempting to add it to our UI (remember at least 2, one of which quite recent), … What I am saying is that syncthing and the ignore system functions in a way, that all the pieces are already there for some kind of selective sync feature, and we maintainers will definitely not stay in the way of it, the contrary.
Oh wow, typically for me I just wanted to write something short about “maintainers”, and end up with a wall of text.
tl;dr:
Don’t focus on maintainers. We will not stand in the way of getting this feature done (the opposite), syncthing already has pieces in place to make some variant of it possible and we’ll keep working to make sure syncthing stays usable (and thus ready for this feature) - indeed for a variety of reasons it’s unlikely that we’ll implement the feature.
(Damn, even my tl;dr is a classic German-style bandwagon of a sentence (well two). )
The original poster at the very top wanted to be able to share with other people some of the folders and files that are in his Syncthing folders, but not all.
I tested a solution that works for me and that is to create a copy of the data on a cloud drive. In my case I’m using Pcloud.
Now that I have the data on a Pcloud drive, I simply use the Pcloud file and folder sharing feature to share the data that I need to with others bypassing the need to have syncthing do the work itself.
I know that people who are using this software are in some cases doing so to avoid having to use a cloud drive however in this case it is to me a logical solution to the original poster’s problem.
What would the cost be, in terms of your time, to make it possible for the syncthing team to get selective sync into the official version of Syncthing? I have used it to replace iCloud because it essentially functions the save way but with the caveat that I must have every file stored locally on each device (and instead of an Apple server in a building somewhere it is MY computer in my house somewhere! That is fine for me because I just move the most important documents into Obsidian and sync my vault with Syncthing and everything else can wait until I get home. However, it does make sense for this feature to be included if your team had the time to work on it. If you guys open up a crowdfunding pool with an estimate of the cost somewhere I will rush to be the first to donate $100 or more.
tldr; thank you so much for Syncthing because it is great, and I will put my money where my mouth is and contribute to a specific campaign to help fund this feature addition.
For iOS or macOS, just use Synctrain, it has selective sync + on-demand file access basically bolted onto Syncthing (using its ignore functionality) that (at least I think) should work reasonably well in your use case.
From my perspective (developer of Synctrain) implementing selective sync is complicated not just because of the necessary changes in Syncthing core ( although the app in fact demonstrates you can do it roughly without any changes to Syncthing core code) but primarily because of two other reasons:
There are just so many edge cases that would need to be addressed. In the app I am able to address most of them by limiting functionality and because of the fact that the feature there is mainly aimed at facilitating media consumption (select a file, sync it, watch it on the plane, deselect it is a rather simple scenario - renaming, moving, modifying the file etc. are not, let alone dealing with complete folder structures that need to be consistent somehow, i.e. certain macOS app documents are actually folders).
Implementing selective sync is (imo) a (complex) user interface challenge. In the iOS app I went to great lengths to try and make it as obvious as possible what the user is doing when selecting/deselecting files, and conservatively blocking certain dangerous actions - i.e. deselecting a file that is not present on any other peer, which would permanently delete it. Even still the app has some really sharp edges. The current Syncthing web UI isn’t even focused on dealing with individual files (it is a control panel first and foremost for controlling which folders sync to where) so would need quite a rethink.
I have thought about it, but (1) I have no use for it myself, (2) the UI would have to be written from the ground up as SwiftUI is unavailable on Windows, and (3) I have little experience developing modern native Windows UI (last I wrote native Windows apps I used Win32 directly - still have nightmares about lpfnWndProc and its friends sometimes :-)).
)