I’d like something like receive only too, but as I read a part of all the discussion about it, indeed lots of various expectation are behind these same words. Maybe formuling in first step a few scenarii to be sure everybody expects the same various option behaviour would help to afterwards create what is needed.
So here is my point of view : I see a 3 level abilities : master, collaboratives, slaves. A master is read only, nothing affects it because none should update him. It can be set locally as a deaf device. Collaboratives are the usual level devices : one change on anyone propagates changes to the others. Slaves receive only and no other change from local action should be propagated. They are muted devices. Status modification should be set from addition of authorization from both local and other devices. A device pretending to be a master should be alone in the cluster of this level. The case of at least 2 masters at same time should lock the propagation of any changes from each of them. Other devices can’t promote themself as master as long as a master is present. But even in this case, a master never listen to the others so no change can occur from the cluster back to him. A slave is set as slave by a master or a colaborative, or by itself. As long as one of these condition is set, the device remains a slave. So a slave cannot promote itself (but can unset himself as slave) without akcnowledgement of the others, and can’t change/mess up because not allowed. It could be considered as muted, or other collaboratives may be deaf to its’ changes.
This should solve all the part of adding files. Concerning deleting, from master and slave point of view, no difficulties : one serves, the other obeys and follows, like now when files are changed. The collaboratives point of view isn’t obvious. If changes occurs between them, how should they handle the will of the master ? I propose, as long as they follow at least the rule of the master, they may add, modify or delete other files and propagate between each other collaboratives. But what about slaves ? Should they follow the master only / or the master and the collaboratives ? Well, the 2 cases could be handled by the 2 level authorization : A slave set as slave by the master follows the master only; if set by at least a collaborative it follows the collaboratives considered as sender only, and if set by itselfs, it follows the master only. So I think all cases should be handled. Now, how to display the stats and status of the cluster… I didn’t think at it yet.
Waiting to see your opinions 