Reading through the issues #3993 and #1939, apparently no way was implemented to notify other devices that one does not want to accept a shared folder? This was also suggested, but seen as unnecessary in How to stop sharing a folder in a cluster?
I still think this would be a very useful feature and want to suggest it based on the following arguments:
Keeping a list of share notifications to silently ignore is unneeded overhead. I’m not sure about the protocol implications, but could syncthing even save network traffic by not announcing a rejected folder over and over to a device that does not want to accept it?
Telling other devices to stop bugging me with this particular shared folder will also help those other users see that the folder is not actually shared with my device and therefore give an up-to-date look at who could access a folder.
If a folder was rejected and added to an “ignore list”, how can it be rediscovered if I later change my mind and want to add it anyways? Even if the peers unshare it and share it again, I will never see any more notifications and might not even remember that it was ignored in the first place.
I’m not suggesting that a device should notify the cluster after locally deleting a folder or unsharing it with a specific remote device. The reminders I currently get (device X wants to share the folder Y with me) should just allow to tell them “no, thanks, and please remove me from your sharing list” in an automated manner. This would give control over which folders might just be temporarily ignored (with regular reminders), and which are no longer needed (deprecated, only for testing or to explain Syncthing to another user, etc.)
Why can’t you just unshare it from the other side?
Because I do not have control over the other devices. Real-world example: I set up Syncthing for a colleague and established a folder “test” to show him the procedure. He never cared to remove that folder again or unshare it for my computer, so I get the reminder all the time for something that will never be needed again.
For this case with one colleague, I could call him and walk him through unsharing the folder. But for larger clusters, clicking 10 buttons is way faster than calling 10 other people, who might not be tech-savvy.
This decision of what shares with who is calculated in completion status etc, so the right thing to do here is to ask remote people to unshare folders, as otherwise you will permanently look out of sync to them.
Exactly, and I am proposing a way to ask the remote people in an automated fashion, through the protocol instead of calling them on the phone.
If I just want to express “please don’t bother me with this folder anymore”, there is no need to ask for approval from the other end. So a button in my Syncthing GUI would do exactly what is necessary.
I’m not philosophically opposed, but I do think the problem is niche enough that it doesn’t carry its weight in terms of added complexity in protocol and implementation.
A local ignore list, combined with a way to see and edit that list, would probably be fine. (There is precedent.)
Maybe that’s because you usually encounter more tech-savvy people in your cluster, who understand what to do when you tell them to unshare something you no longer need?
AFAICT, it’s only one extra protocol message and a button in the reminder popup?
Yeah, it’s one new message or, if implemented, 12.5% of the protocol. With docs, testing, potential implementation required in current and future protocol implementations, and so on. It’s not an impossible burden, but there’s a high bar to pass to warrant a new message type.
However, if one really wanted to, it strikes me that it could be bolted onto the initial cluster config message. We send the list of local folders there, and if we had the ignore list of folders we could also send a “do not want” list in there. And then auto remove from the ignore list when not present in the remote peer’s list any more. That’s still more mechanics than I feel it’s worth, but if a non-intrusive PR passed my way it might get in there.
You were the one that suggested to remove the local folder ignore list functionality when it was available in the initial PR, and now we are talking about adding protocol messages to support this…
I must be going mad…
Could be, or maybe I am. I do change my mind randomly. But to me it sounds like I’m still saying “I don’t think it’s worth the code”, which is probably what I said then as well. OK I’ll clarify with fewer weasel words:
- Protocol addition for this purpose ain’t gonna happen. The cluster config stuff was a bad idea, it’s already too bloated.
- Local ignore list implementation would have to be really neat to be palatable
So you mean the local device’s folder ignore list (introduced in #4179) would be pushed to other nodes so they can unshare anything that’s ignored on the other end anyway? If so, I would not want that. It turns a reversible decision (mark this on my ignore list) into an irreversible one (ask others to revoke my access). For the latter, I imagined a very conscious and clear user action would be needed. So as it stands, I will probably live with using the local ignore list and trust that the overhead is negligible.
What do you mean “the cluster config stuff was a bad idea”, and what would be an alternative?
Actually, #4179 implemented the thing that @calmh didn’t want at first, so that’s the workaround I was talking about already.
I guess I don’t understand why the ignore list doesn’t work for you, but asking someone to remove access remotely is somewhat an DoS vector, so I am not a huge fan of that.
If a hero does step up and implement this, then I guess as @calmh said it should be part of the ClusterConfig message.
I think it is a good thing that your partner’s device shows you as being out of sync. They believe they are sharing to you, so they should have a way of noticing that something is not right. If you choose to ignore, they know you are not getting their files. If you wish to have them no longer share with you, you should contact them. Human to human communication means that everybody in a cluster has the best possible understanding of other people’s intentions. When I worked in IT support I abhorred having to sometimes just ask a user to trust me, when I couldn’t give them a basic reason for what I was doing. Sure, if they didn’t understand the reason, so be it, but I wouldn’t make changes to other people’s device settings that might impact their understanding of which files were shared, without at least mentioning I was doing it.