I am not sure whether this is already possible, but I have looked for how to do this and been unable to find any way. Apologies if I have been too stupid to find the right documentation or something – if so, I’d very much appreciate a pointer in the right direction.
What I’d like to do is when I share a folder with a remote device, force the remote device to receive-only sharing mode.
Alternatively – and possibly “cleaner,” but I’m not sure about that – be able to set the sharing mode of the local folder to send-only for that one remote client only.
The general idea being that I would like to be able to share data with a given device and be sure that that if (inadvertent) changes are made on the remote device, they are not propagated back.
Well, I do want the data to be shared with other devices as well, and those devices should be able to send modifications. Maybe I don’t understand your suggestion correctly? How would those tie in with the new folder?
Ah. I didn’t realize that was possible (and, indeed, it does feel like quite the hack to me ;-)).
So, I will go down that route for now, thanks! I also think that some functionality should be implemented to allow for this scenario to be addressed without anything too hacky. What would be the proper way to submit such a feature request?
Thanks a lot for your quick and helpful responses!
As for quickly implementing this in a non-hacky way, I’m not so sure.
Folder type in Syncthing is currently not so much about what gets sent/received to other devices, but about what routines run to manage the files locally. A send-only folder doesn’t have functionality for pulling changes. A send-receive folder does, but doesn’t have any way to distinguish which device changes originate from.
If you had the granularity you expect, and you peer with two devices, one in the new send-only mode and one normally, and they also peer with each other, how do you filter changes that come from one via the other? What does it even mean to do so? What if one of the other devices also used granular sharing modes, but in the opposite direction? We could build a directed triangle where files only propagate in the clockwise direction but anyway get to everyone despite half of the relationships being “send only”…
Flexibility is good, but it’s also nice to have a system where it’s possible to understand and predict the behavior by just looking at the local device configuration.
I cannot comment on whether this is easy or hard to implement, but from where I sit, it sure looks like a valuable feature.
Having said that, I agree that the design would not be trivial. I did think about possible issues that arise from the transitivity of sharing folders, much like you describe, and I agree that it’s not obvious what the best approach would be. However, I do think that an argument can very much be made for just implementing it the straightforward way (so that all of the transitivity issues that you describe can, in fact, arise), because in the end, it doesn’t matter whether changes are propagated along unforeseen paths automatically or manually. In the end, if you absolutely want to be certain that no changes whatsoever will come in from the outside, you can still ensure that by setting the entire folder to send-only (or all shares, whatever the concrete notion would be).
But, yeah, I do see the difficulties, but I do tend towards thinking that the benefits would outweigh the downsides (given that this might be marked clearly as an advanced-usage option meant for users that know and understand what they are doing).
The basic assumption in Syncthing is that files are shared with other trusted nodes (leaving aside the untrusted / encrypted options). The goal is to synchronize folders, as the name tells, meaning that changes on any node are propagated to all others. Forcing any kind of behavioral pattern on other nodes was never part of the equation, thus any feature in that direction will be going against the grain and cause issues in implementing it.
That’s why the existing options are always configured from the local node’s perspective: Folder labels, device names, protecting against changes from elsewhere or preventing local changes to be announced to others.
I don’t think Syncthing is a good fit for use cases where you want to control other nodes’ behavior. For sharing data read-only, a simple web server might be the better choice.
It may well be that the original idea that sparked Syncthing was that all nodes are equally trustworthy, but that does not mean that it must stay that way. Syncthing has already gained functionality that is meant explicitly for non-trusted remote devices (namely, encryption), so I think this argument is essentially moot. Besides, I do maintain that the use case I have sketched is very much a valid and useful one, and furthermore that Syncthing is perfectly suited to handle that use case except for that one missing feature that I was asking about. A web server is a much, much worse fit in many ways. Also, please note that the use case itself does not in any way mandate that the behavior of a remote node be controlled. That is merely one way (possibly the easiest, but as I have already written in my original post, conceptually likely the least “clean”) to approach the use case. In fact, I do agree that is is likely preferable to be able to set the send-only property on a per-remote-device basis (as opposed to forcing behavior on a remote device).
I wasn’t making an argument against your feature request. Merely tried to explain what assumptions led to the code working and being structured in the way it currently is. And that makes it harder to integrate that feature based on different assumptions.
The reasons why it is a bit of a footgun were explained very well by @calmh. You may be able to control the direction of one link, but you cannot control what the other nodes do that may circle back to yours on a different path. So to protect your node from changes effectively, you’d need to set all remote devices to send-only. Which is the situation we do support already.
