So your category 1 is the subset of checked items in the current list.
Categories 2 and 3 are currently impossible to distinguish as both are in the list as unchecked items. I see category 2 as one of the major improvements with my suggestion, because it helps to create “missing” links in the cluster for performance or better opportunistic sync behavior.
Technically there is another distinction within categories 2 and 3, because if we share a folder with a device, it might not do so the other way round. But for me it would be okay to not visualize such “pending acceptance” states, at least not in a first step.
So here’s my suggestion (any empty section should be hidden):
First section “Shared With (uncheck to revoke):” All the devices of category 1 with checked boxes. Unchecking and saving removes the folder sharing flag.
Second section “Suggested Devices (check to offer share and improve cluster connectivity):” Devices of category 2 with empty checkboxes, friendly name only. Checking and saving sets the folder sharing flag. Sorted below that, devices of category 4 with a plus sign instead of the checkbox, with the device ID and friendly name. That makes it clear that we have not verified who that ID stands for. Clicking the device name opens the “Add Device” dialog, with the respective folder sharing flag pre-selected.
Third section “Unrelated Devices (check to give them share access):” Devices of category 3 with unchecked boxes. Checking and saving sets the folder sharing flag.
So most of these UI changes can be done already without knowing about the category 4 devices. Moving the device list to a separate tab (like the folder list in the edit device dialog) should be done in any case for consistency. Should I create an issue for that?
Splitting the list as outlined above is beneficial to show the user whether checking a box will make data initially available to someone, or just close a missing link. Which is important information from a data security point of view, avoiding accidental sharing to the wrong guys (and gals).
I seem to remember @calmh has issued some critical remarks about having the cluster config message at all, so I’d kind of like to hear an opinion whether this proposal would make the collected information useful or stand in the way of rather yanking it from the protocol. How likely do you think the “memorizing the known other device IDs” part could be implemented, as a prerequisite for category 4 devices?
Finally, the same GUI concept should be applied to the “Shared Folders” list within the “Edit Device” dialog. But let’s get started on one thing first.
The GUI is a somewhat naive/half-hearted thing to begin with, which has since grown … organically, let’s say.
