Three months later…
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?