I would like to open up a discussion a new folder type: Receive Only.
Currently only 2 folder types are supported e.g: Send Only, Send & Receive. But these two options do not support the scenario where only fewer node should introduce new changes to the peers. The other nodes/peers should not publish any local changes to the network. This is a typical use case where repositories/files can be synced to multiple peers but writes to these repositories/files are only accepted in a single or fewer nodes.
In some use cases, it would be dangerous to have a non-designated peer/node advertise local changes globally. For an example, if we are to sync critical configuration files using Syncthing, if we changed anything in one of these files by mistake/accidentally, that change would propagate to all of the other peers in no time. This is unacceptable in certain environments.
To this end, I have created a new pull request:
With this patch, I am introducing a 3rd folder type: Receive Only. Only few nodes with Send Only share would be responsible to introduce new changes to the network. Rest of the nodes/peers would have the Receive Only folder type set. So any local changes in these non-designated peers would not be advertised across the network. Local changes would rather be deleted/overwritten. Thus protecting critical data from accidental changes.
This new folder type is exposed via config file as well as GUI.
I added some points to consider to the pull request. Technical discussion probably fits better there since the PR exists, although the philosophical basis can be discussed here I guess.
I know this issue has been discussed earlier, because I was part of the discussion, and exchanged a few posts with Jakob. Iām glad to see it resurface.
Receive-only folder types are philosophically correct because they complete the option space. With s/r, s-only, and r-only, there are no other options. The symmetry would be complete.
Practically, I have needed this for a while. I sync/aggregate multiple work computers onto a single computer, which is used as a gateway to backups. I have no desire to risk propagation errors ~from~ the aggregation computer and there is no reason for it to ever source a change. Ideologically, it should be r-only. Having an option to actually do this would be great.
Iām not skilled with the github framework. Does Kumartejās anouncement mean r-only will be released in the next release, or is this just a proposal that the patch be done?
It seems to me like this should really not be a property of the individual device, but a property of the rest of the cluster. That is, instead of someone considering themselves āreceive onlyā and going through contortions to avoid announcing broken state to the rest of the cluster, the rest of the cluster should know to ignore updates from the device that is not supposed to generate them.
Doing that is even relatively simple - announcements from the device are simply never eligible to become the globally latest version, unless they already match the globally latest version announced by someone else.
To enforce it, a device that marked device XYZ as untrusted should ideally only talk to other devices that also distrust XYZ. This could be part of the connection handshake. (Otherwise updates from the receive only device could escape via another device.)
The receive only device then uses file permissions to avoid inadvertent modifications. All is good.
Jakob, that sounds functional. There would have to be some way to manage that over the entire cluster though. I have a cluster of 7 devices, 6 of which need to be treated as Recieve-only. WHould you envision the introducer (which is Send-only) telling all the other devices to ignore the ones marked as Receive only? Else it would be cumbersome to setup even on my small cluster if I had to go into each device and tell it to ignore requests from every one of the others but the āmasterā. I know there are people requesting this with thousands of devices, so some way to propagate settings would be required.
The right way to do this, I feel is by adding ecdsa keys, public part becomes folder id, private part decides who can write (produce signed indexes) and who canāt.
I am again convinced that a Receive-only folder designation is a good idea. Hereās the architecture I have been unable to accomplish without it.
I have a sync cluster that operates fine. Now I want to add one more node into the cluster that is always on and collects or aggregates files from the others. I want it to never propagate data or data deletions back into the main cluster.
In one case, a work cluster node is Send-Only to all the others, so it works to hook up the aggregator into that sync cluster because any corruption can be āstomped outā by the existing Send-Only. But in the generic case, all work nodes should be send/receive peers and allow changes to propagate inbound.
A Receive-Only option on the aggregator node would directly accomplish the architecture Iām after. It would protect against operator mistakes. However, when considering trust relationships (see Jakobās 7/2 post), this canāt really be done as Receive-Only because any bad operator at the aggregator node could change it to Send/Receive and send corruptions back to the rest of the cluster. It really needs to be implemented as an option on every other node to ārefuse updates from node xxx, but send updates to xxx.ā
Soā¦ I think Iām augmenting my my suggestion to allow the Send-Only option to be specified against designated other nodes rather than a broad application to all other nodes.
Am I missing another architectural way around my original goal?
I would love (and need) this feature too. ItĀ“s annoying to use different tools for different jobs that one tool could easily cope with.
I expected that āsend onlyā folder would only send and do nothing else. But this feature deleted the residing files in the target folder!! args! that was not intended!
I even have use for another one: āmoveā folders. all files on source-host are copied to hosts, that are subscribed to this folder. after that the files on the source-host can be deleted.
this would be great to
push music to my smartphone (donĀ“t want two additional copies of it on my two computers).
push new photos from smartphone to computers.
automatically move files to another host when it comes back online.
as I said: annoying to use different tools for every job.
+1 : Iād like to set up a master server directory (send only) that will be spread to users,
I want all the users to act together in spreading files from the master (send/receive),
but I donāt want any of them unsyncing my structure one to each other (receive only) nor, ofcourse to the master (which is solved by send only).
At present time (V. 0.14.43), is it possible to do this and if so, how could it be done without this feature ?
Thanks.
A month laterā¦ I use Syncthing for a quite a while now. It gain my trust if handling files and syncing my three machines. I would like to add another one wit READ ONLY permissions. I sync my home pc, laptop and works pc at this moment. I want to share one folder with one of my friends but I donāt want him to be able to change anything. SEND ONLY is not an option as I work on all thee machines (not at the same time )
Are there any plans/solutions?
Well, I definitly would like this feature enabled.
)
Are there any plans/solutions?