Manual intervention for Introducer feature


(André Colomb) #1

Hi all,

I’ve seen several threads here that circle about the Introducer feature sometimes re-adding devices that should not be. That gave me an idea for a new feature, a “soft introducer”.

My background is actually trying to maintain a mesh without total everyone-knows-everyone topology. Every device owner gets to choose what other nodes to connect to. There IS a central cluster node that everyone should have in their list. However, if everyone sets the introducer flag, the mesh will be completed automatically – not my goal as it could lead to performance problems with large clusters.

So I was thinking about putting a list of device IDs as a text file within some share, so everyone can pick their desired connections. However, the data is already there in BEP’s cluster config message.

So I propose for discussion:

  1. Memorizing the known other device IDs for a folder after a cluster config message (not persistent).

  2. Adding a link to each share in the GUI, with tooltip “List other devices you might want to share this with”. It will be hidden if all devices are already in our connection set. It should be non-intrusive so the user can easily ignore it if a complete mesh topology is not desired (so not a notification box).

  3. Show a list of “unknown” devices with the same share when clicking the link. Choosing an entry there will a) add the device ID and b) set the folder’s flag to be shared with that device. Note: The other end will have to acknowledge the connection request after getting a notification box and possibly verifying the device ID over an independent channel.

  4. For devices that are already known to us, but do not directly share a folder we both have, maybe also suggest enabling the respective “share with” flag. Haven’t thought out a GUI concept for this yet.

All of this is not meant to automate trust management, like introducers do. It just tries to simplify device ID distribution and manual setup of network topology.

Looking forward to your comments, regardless of who will have time to possibly implement which parts. I think it could be useful even to less sophisticated users that would not mock about with introducers, but don’t like reading long device ID strings over the phone.


(Simon) #2

UI wise I wouldn’t add a new link for that, but put it in the “Share With Devices” section of the folder edit dialog (moving it to its own “Sharing” tab, which should already happen now to be consistent with the device dialog). There your point 4. is already present: a list of all known devices to share with. Now a second list of advertised but not yet added devices would appear there with some kind of explanation what it will do (add this new device). I actually think this would be quite nice, but you already mentioned the “time to possibly implement” problem :wink:


(André Colomb) #3

Actually the current list shows all known devices to share with. So maybe it should highlight those which are known to also have that folder ID shared with someone, but not us.


(Simon) #4

You’re right, I missed that aspect. So basically there are these categories of devices:

  1. Paired devices that we share the folder with.
  2. Paired devices that share the folder with a remote device, but not us.
  3. Paired devices that do not share the folder in any way as far as we know.
  4. Unpaired devices that share the folder with a remote device.

Now you’d have to somehow formulate/present that in a way, that the average user understands it - I think that would be hard. I don’t think visualizing 2. is important. The main benefit in my opinion is, to have all possible devices presented. Devices 1-3 are already present, devices 4 are not.


(André Colomb) #5

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.


(André Colomb) #6

Ping? @calmh or another project leader, what do you think?

I’ll try to find some time at the end of this year to experiment with an implementation. Need to learn Go first, though… :roll_eyes:


(Jakob Borg) #7

I think something like this could be useful, but I don’t have too much of an opinion on the UI at this point. Certainly indicating somewhere that there are further possible devices to add / share with seems reasonable.

There’s no plan to remove the cluster config stuff, afaik. The one possible improvement I could see in the future is the ability to send a new such message without tearing down the connection, for when important properties change.