It looks like there is already a thread dealing with introducer nodes:
So, not sure what to do with this thread. If you decide to delete it, I’ll just move the per repo introducer related info to that thread, if you think it would be better that way.
Does anyone have a functional description of the Introducer concept or a pointer to the article where it is covered?
It would be great to see how it helps to automate joining the shares (repos) and to what degree for the general public situation where you do not have access to other nodes and have no means of contacting them.
We’ve been promoting Syncthing on our pretty busy site in the context of BTSync and its latest release where they have completely changed the GUI to run under IE (Internet explorer).
We would like to cover all the aspects of Syncthing that relate to as automatic joining of repos/shares as possible. Our main use of sync process is for general public distribution of valuable information and not merely using it to sync between the devices one has access to and can manually approve the new nodes to join the repos. In our case, automatic joining the repos, just like with torrents, is a vitally important issue.
Update 1:
If I understand it correctly, the introducer works not on per repo basis, but also includes all other repos known to the introducer node. If that is correct, then this seems like an issue for us. Because we would like the other nodes to see only ONE specific public share/repo, and not necessarily all other repos on other nodes.
So, what we would like to be able to do is to pass some REPO key, which might be interpreted as the itroducer node ID for that particular share ONLY. The other nodes should not see any other repos/shares but the one identified by the repo key.
The alternative could be for the introducer node to be able to exclude some repos that are private.
Another alternative could be for Syncthing to run a separate instance of the program that has a different node ID, used exclusively for private repos. The other node ID could be made available to all the public repos and other nodes could chose which repos they wish to join out of that collection.
Because you might also have some other private repos on the introducer node that you do not want others to be aware of, such as backups of certain data on your sever, which is strictly private information.
Are we on the same page here?
Update 2:
Yet another alternative could be to add a flag in each repo/share. It could be either public,
or private or introduce.
The public could imply that this repo could be introduced by others. Else, it is considered private.
Private could imply that this particular repo can not be introduced by others, meaning private. Except that you might also want to be able to introduce the private collection, but to different set of nodes.
Introduce would simply mean that this share can be introduced.
All these are basically the variations on the same theme. So, if you make some node the introducer, then all the repos that have the above flag could be introduced or vice versa - introduction is denied to them.
It seems to me that logic with introducer nodes still needs some refinement, but the very idea looks like the logic is going in the right direction. I am pretty sure that once the process of joining the repo/share/collection is made easy and users who have the key can start downloading immediately, without waiting for any approvals, at least from all the nodes marked as “introducers”, then we will see MANY people switching to Syncthing from BTSync. Many people are tired with all the bugs and “but it is still beta” excuses.
They want something that simply works and they want to be certain that all the claims as to encryption/security related issues can be trusted and their private info is not used for some other purposes, and especially passed to the agencies, such as NSA in the process of global surveillance. And they want all those tons of bugs to be fixed. The amount of problems of all kinds with BTSync is just mind-boggling.
I hope you don’t mind us taking a closer look at some options. Since “public” and “automatic” are my “operative words” in terms of public information distribution on as automatic basis as possible, just like with torrents, I’d like to take a look at Public flag of each repo/share.
Let us assume that it is something acceptable to the main developer.
So, now…
It seems to me that if Public flag is set, first of all, it is propagatable and not reversible. Once the repo is marked public, it can not longer be reverted to private with the same repo key. Logically, you can make it “private” only as far as your own node will no longer automatically feed/seed the other nodes. But it does not prevent any other nodes from seeding this share. So, no matter what you do, once public, public forever. Just like a torrent. Once created, it can no longer be destroyed. It lives forever, for as long as there are some participants with data on this torrent/repo.
Then, once public flag is set, that means that any node that has this repo key will join that repo, including all the nodes that are currently marked as introducers (for this repo ONLY, preferably), and, furthermore, any new node that just joined this repo will immediately and automatically start downloading that particular repo [equivalent of check box set in the list of nodes for this repo] (or a list of ALL the repos marked as public via particular introducer node. Or, alternatively, it only atomatically joins and starts downloading only a specific repo available on a public repo and the list of other public repos will not be automatically joined, but will be made visible on the GUI for that repo on their nodes so they could manually join some other repos that are marked “public” by the introducer node.
In other words, introducer works as a tracker server, that is it exposes and expands the list of all known nodes for that repo.
Furthermore, the effect of a tracker is cumulative. That is, in whatever way the new node, (or any other node, for that matter), got the list of nodes on some share, from then on, it will pass the list of all the nodes that this particular node knows about, regardless of how it was obtained. This means, that in a very short time ALL the nodes that participate in this repo with “public” status will know the entire list of all the nodes, regardless of which particular node(s) was seen by which other node.
That means that if some node no longer has interest in SEEDING some repo, it simply resets the Public flag for that repo on his node. Then, he may disconnect from any of the nodes on this repo either by individually deselecting them via GUI Edit repo screen, or disconnect them ALL in a single mouse click. Just like with torrents, you may have a number of torrents that you chose to seed, but it does not mean that you ALWAYS HAVE to seed them. You just click on “Go” button in the menu and you start seeding. At ANY given moment, you click on that button again, and you STOP seeding that repo. The same thing with Pause button for any repo.
Well, I am not certain about it at the moment. I can not quite formulate it, but it seems there is a need to resolve the conflicts between “allow” or “deny”.
For example, if you say this share is introduceable, you may wish to “ban” some specific nodes for whatever reason, such as you know for fact that these nodes are bandwidth suckers. They come, load a bunch of data and then split without sharing it with others and seeding. In general public applications there are plenty of those guys, who just want to get more and more and more and never give anything back. So, you can handle those easily. I see no problem here.
Another case would be: you can specify it to be introduceable, but ONLY to the developers team or to your department ONLY, or whole set of other criteria, and so on.
I intuitively think this needs more thought and refinement of logic and consideration of all sorts of other aspects we may not even think about at the moment. But, yes, introduceable on PER SHARE/REPO basis is definitely a huge improvement in my mind.
Yes. Not quite sure what it is at the moment though.
Not sure what you mean here. May be, if I understand you correctly.
Well, it is definitely a start in the right direction in my opinion. Again, the KEY here is on PER REPO basis and not per node global. It seems that to have introduceable flag for the entire contents of the node, even if it an introduced, is too rough of an approximation. You certainly have multiple and at times contradictory use cases in many real-life applications. That triggers a whole slew of options that become available to you.
So, to sum it up, you may have your node that is generally used for the private applications/networks. At the same time, you may let it also carry a public data to anyone who is interested in it. THAT data is no secret of any kind and there is no need for protecting of it, regardless of anything. The only realistic issue I see with this is that you may wish to protect things and make them invisible for some evil parties or those whose who are interested in destroying your information distribution network via all sorts of blocking, be it on the highest level network or router basis. But that is a totally different set of issues, even though it should be given a thought in my opinion.
Considering massive efforts to block the “undesirable” information in modern information war that is raging on as we speak, they have adopted the laws throughout the world to classify the information as “evil”, “fueling all sorts of things” and so on. In this situation, virtual distributed sites become about the only way to protect the information. And for that, sync on P2P basic assures the availability of information, even if some of it is blocked. For example, Google started blocking some search queries on one of our main sites on the keywords like “money politics”, “wars”, “political manipulation”, “corruption” and so on. They claim it is done upon request of some unspecified European agency and/or government, based on unspecified to us allegations and unknown to us “law” or regulation. And this is serious business, if you realize what they are trying to do. The same thing happened in a few months ago with one of the biggest providers in the world threatening to block the entire site in the entire country if we do not remove one specific book, written by one of the foremost experts in the world, which means their claim is utterly illegal and is in fact an act of gross violation of Basic Human Rights Convention, signed by most countries.
So, to have virtual, fully distributed sites at this junction is VITAL in our opinion to make sure the evil is exposed in full, no matter where and what it is.
I think the added complexity of this doesn’t make it worthwhile.
You don’t think you can achieve this granularity of control in BTSync, nor I think any other tool available.
This special case that you have is very corporate, and I think that average Joe who wants to sync his pictures from his phone to his laptop, and perhaps later share them with his wife doesn’t need this case.
It seems that you want to make Syncthing a swiss army knife, which does everything in every possible way, though I already feel that Syncthing is complex enough to repel average Joe from using it, hence adding more knobs and buttons to specify some very specific set of cases is not what I think should be done.
I think for this very special use case, and you can already achieve what you want by switching off introduction, and do your thing manually, or scripting stuff up via CLI…
This way, you are happy, and average Joe is happy not having to understand what 10 additional buttons do.
But then again, I am not the project owner, hence this is my personal opinion which does not influence anything.
Well, initially I did not feel like replying to this post. But that would mean disrespect.
So, just briefly:
Depends on how you define “worthwhile”.
What does BTSync have to do with this? Secondly, do you consider BTSync as some kind of a standard by all are to measure?
Sorry, I do not see it this way, by ANY means. Me, personally, have nothing to do with any kind of corporate anything, and I’d love to see this feature, and have seen plenty of users asking for this sort of thing. Implementation wise, this is probably one of the simplest things to implement and could be done is a couple of hours I suspect. Unfortunately, I do not know Go and it will take a few days to study the code. Secondly, I would not want to fight with main developers trying to prove something. I have no interest in that. Thirdly, I am as busy, as it gets and for me to get involved on development level would mean I have to dedicate every minute of my life to the project, and for weeks and months. Yes, it would look and like a tank, and I have not doubts about that because I have developed a methodology of development in general. But this is a totally different subject.
Fine with me. There is such a thing as Default behavior. I could also be considered “an average Joe” with quite a few programs I use, especially during the complex installs and configuration. But I just accept whatever defaults the program provides. I do not have to even understand every checkbox and its esoteric meaning.
Well, that certainly would be great, but I do not have expectations set so high and there are only few most important things I am concerned with as far as sync goes. And I know precisely what I want to see, and the list is not that long. But that does not mean that others agree with it, and I have no problems with it. Everyone has a right to see the world and Life in the way they choose and experiment with things THEY like, not me. I am not anyone’s judge as to their choices. But it does not mean I have to be like others, does it? I also have the same freedom as anybody else, if you don’t mind.
Well, again, “default behavior” is an operative world here, and no, you don’t need to add tons of checkboxes. Just one would be sufficient for now and its default behavior could be configurable via configs, just like any other default which you can change if you are not “an average Joe”. And if you are, just skip it. Shouldn’t be a problem.
Life does not start with average Joe, not does it end, nor the planetary systems turn around him, nor creativity of any kind becomes possible thanks to him.
Introduction is currently per node global, unless I am missing something here.
Where do you see 10 buttons? Could you enumerate and give a functional description of more than one at this point?
Let me ask you one thing: do you consider yourself to be “an average Joe”?
I did not even suspect Syncthinig was written for the “average Joe”. I think it is pretty good as is considering that it is a relatively new product. I am using it for a few months and it works reasonably well so far.
The question, from the creative standpoint, would be: where do you take this thing from now on? In which direction do you develop it? What are the most desirable things to be done that are, at the same time, interesting to developers to work on?
Am I hearing that development stops from now on because the needs of an “average Joe” are fully satisfied?
Finally, at this point I have a complete architecture that, as far as I can see at this point, fully describes and covers all possible cases and in very simple and clear fashion. It would be clear even to an “average Joe” if he bothers to even spend a minute or two to understand it. And it is many times over more sophisticated than just one or two chckeboxes functionality. And it is very simple to implement. In a couple of words: you need a list of clusters and you can announce each cluster in any way you please without any logical conflicts or contradiction of behavior or logical complexity. If you are interested to really investigate this thing, I’d be willing to give you some time and my energy, but only on MY turf. I would not like to interfere here with things that are not of interest to developers.
So, just ask, if you care, and I will give you a link where we can discuss it in a very relaxed and productive manner, without any interference from any one and with full freedom to express whatever opinion one might have.
That is ALL I can do for you in case you care.
Otherwise, I am done with this subject here. If anyone cares to clarify something, fine with me. But ONLY in a CONSTRUCTIVE and creative matter. I am not interested in insults, post mutilations and reverting to violence of any kind. I just do not like that energy. By the way, when I got back to my box, the first thing I saw is your post. The second thing I saw is I lost my main disk. It was just gone. It was a situation where your hairs may raise.
In case you did not know, there is such a thing as energy projections, and they could be very destructive and could have profound effects on others, but eventually on the attacking entity. Essentially, they just hurt themselves more than anything else. I hope you can comprehend what I am saying here.
Good luck and enjoy. Life is a Grand Ride for me, and for anyone I care to deal with.
Introducer - setting up, step by step instructions
Sorry to bother. But I am beginning to think that Syncthing, even as is, may be already suitable for the general public applications. So, in that case, we may start working on a Detailed Manual for it, where we will try to cover the major issues and points from the standpoint of using it, just like we did with BTSync manual, which, at this point, is probably the best manual for BTSync there is, and that is the idea.
So, what we’d like to cover at this point, is Introducer functionality. For that, we need the exact, step by step instructions on how to set it up, what happens when you push this or that, what do you see on the screen and what exactly does it mean, what actions should you take when you see this or that message and what that message means logically, from the standpoint of a user. What kind of error or warning messages you may expect, what do they mean and what to do about it to make the whole thing work “as advertized”. Things like that. And it has to be simple and clear, even for the “average Joe”, or for the best of developers there are, except they might decide to skip some things.
Now, since I do not have a sufficient understanding and only tried to play with one case, and it is not even clear that what I see and understand is actually correct, would anyone who really understands the whole concept contribute to the step by step instructions?
Unfortunately, currently we are working with only two nodes, which is probably not enough to test the functionality in all possible permutations and in all possible aspects. So, we may start writing something that is either incorrect or incomplete.
But Introducer functionality is something of interest at this point.
So my overall point which I was trying to make, but clearly didn’t deliver due to the time of night I was replying.
I’ll try again, and will try to upset people less this time, which I tend to do quite well because of my arrogance.
Therefore apologies.
Just for the record, I am trying to force myself to use the new terminology (node -> device, repo -> folder) hence it might sound fishy.
Some background from my assumptions on how syncthing works:
Currently as the devices connect, each of them advertises a list of device IDs that they have accepted, plus folder names they have available. I think that previously this extra information was advertised but just ignored by the receivers.
Since you had this information, you could make requests against something you had no access to, which would just result in a failure.
Same happens when you try to connect to a device which doesn’t have you approved as one of its peers… It just fails…
I agree that the current behaviour is not excellent as it’s an all or nothing situation.
I agree with your statement that having per device and per folder flags to indicate if we want to advertise this folder/device would work (I still don’t understand this third state though).
Ok, that adds a checkbox per entity, which I guess is not too bad, but If you start giving users control over this, rapidly more complex scenarios will appear which the basic system will not be able to handle:
I want to advertise folder Z with devices A and B but not C, and at the same time I want to advertise folder Y to devices B and C but not A, and folder X to devices A and B
Which is starting to look like a full feature access control system, which in my unexperienced opinion would be a tragedy to implement from the UI and usability perspective.
I am not saying this is a bad idea but to me, in the current stage it seems it will make the simple thing of establishing a trust between all my devices more complicated. Furthermore, I feel that there are things in the project which have more value to the user, such as being able to resume a broken sync for large files without having to restart, efficient renaming without re-downloading the file.
Lastly, if you want this fine grained access control and introduction system, you are more than welcome to keep the introducer feature switched off everywhere and craft up something of your own .
There is easy to use REST api and CLI which you can use to add and remove devices, share and unshare folders, which is all you need to establish a trust and start syncing. This can be used to write any type of trust system you want.
One of the reasons I wrote the CLI was the struggle I’ve gone through writing a script which would automatically setup a large cluster, and then later be able to add more devices to the cluster with a single command. But look, times have changed, and now we have the introducer feature which does exactly what I was hacking up 4 months ago.
This message might be too long for some. So, just skip it and don’t bother with it if you have no time.
I am really glad to hear that. As far as apologies go, it is fine as long as you do not feel guilt, because it will eat you from within.
Secondly, the ability and willingness to recognize ones arrogance is one of the most valuable qualities of a human being. In my understanding and experience, programmers tend to be about the most arrogant people, and in is not without a reason. Because they feel like “superior” entities. Because they are the “professional” logicians. Professional means that their logic can be verified “objectively” by how their program works, how flexible and powerful it is and so on.
The logicians of an abstract kind, such as philosophers, lawyers, politicians and so on, most of the time simply blowing the “hot air” and pronouncing the slogans of all kinds, just to be “popular”, “powerful”, “influential” and so on, all of which is is distortions. Because they simply shout out the slogans, but very little of it can be verified as reality.
But with programmers, it is all “down to earth”. It is all verified in their code. And since with time you get a sense that you are a “pro”, then it is kind of “natural” to get arrogant, or, rather, impatient with views of others, since you know YOUR stuff “works” and most of others are simply “blowing the hot air” for the most part. So, arrogance is kind of “protective mechanism” of your sense of “I”, helping you to “cut the crap out”, which is not a problem, unless you are CLOSED to ANYTHING else, but your own “I”.
The recognition of ones own arrogance is one of the greatest steps the human being can make, and it may be that “golden key” with which all the doors of the Infinite Intelligence, ALL pervading, may start unfolding between you in the most miraculous ways.
Because you have the COURAGE to admit some things that could be done “better” or differently. That means you are not dead. What a grace!
Hope you don’t mind this.
Anyway, “back to business”.
Fine with me. Except I’d prefer to look at it the other way around. From the standpoint of how you work via GUI, you have, first of all, shares/folders/repos. Within those, you have nodes/devices which you may chose to enable/disable individually.
This is the first sticky point in my mind. I assume we are talking about dynamics in the context of the Introducers, and this might help me to understand the dynamics better.
The first issue is Introducer bootstrapping. Some node was marked by someone as introducer. The new node just installed Syncthing or someone else marked some other node as introducer.
At that point, me, as a new node, starts getting the messages in a GUI saying something like "some unknown repo (node?) exists and it gives you the repo name. At that point, you can create a new repo on your end and copy/paste the repo name from the message, specify the directory.
At THAT point, I’d like to assume that ALL the nodes known to introducer at that moment are AUTOMATICALLY added to this repo/share/folder on my end. Is this correct assumption? Or do I have to manually enable the checkboxes on each individual node to enable communication with it?
Then, if that introducer node has more repos, I will see more messages about each of them and can chose at that point to add those to me, and, therefore, all the other nodes who are the suppliers to me at that point?
Is this correct?
Fine with me. I just hope to see the warning message in GUI soon as I click on checkbox trying to add that node/device, saying: Not accepted by device device_name. But only once. At that point, it could probably reset the checkbox to inactive to avoid being confused as to which exact devices on a given repo you ARE in fact connected fully.
Except here we have a little bootstrapping problem: I click on your node, but you still did not accept my node, so I get “kicked” by you and my checkbox is disabled. How do we connect then?
Well, this means to me that when you add a share as a result of the message from introducer, the nodes known to him are NOT automatically enabled on my end and I have to add them manually, one my one by clicking on their checkbox for this share I just added, which is fine with me. I’d just like to know the reason why are they not automatically enabled as soon as I add that share after introducer’s message.
This seems to add more manual interaction that might be necessary. For example, if these nodes are automatically initially enabled on my end without any user interaction on my part, then my node would send a request to join to the nodes, and in case of the introducer node, I’d receive the automatic approval message back at which point my checkbox would remain enabled, and, therefore, we fully established communication with it.
The same thing happens on the introducer side. Once it receives a request to join the share, it will AUTOMATICALLY grant the approval and mark my node as connected to him.
Is this correct?
This stuff gets hairy in a hurry!
Does this all happen automatically, or is there a need for any user interaction to enable/disable things?
I REALLY like to hear that.
Well, that third state is simple, really. It means you ARE introducer, but ONLY on selected shares.
For example, currently we use BTSync to live update the master web site. That means that as soon as I click on Save button in my text editor, the stuff gets shipped to the web site. But I also have a “not so hot” folder for the same exact share, which contains the same exact information. That folder is a public feed (via BTSync) to all the nodes that are sitting on this share. Because the way we do things is to constantly review the information as things happen and there might be a number of rapid concession edits, even within a few seconds in some cases, if we find some syntax errors. In that case, that would create unnecessarily large number of updates of all the nodes, while we are not necessarily fully done with some document and there might be more edits, syntax or clarifying things, adding some quotes and so on.
So, the way it is done currently is that we have Syncthing feeding us back a copy on the site, but to a different folder and we can enable/disable that channel any time we want. If we suspect a number of potential edits in more or less rapid succession, we temporarily disable the Syncthing channel, and so people do not get overwhelmed seeing all these transfers, nearly non stop, and for the same exact file.
That means that we would like to have an option to exclude some repos/shares/folders at one time or another.
That is that “third” case, essentially.
You can prolly come up with a number of other cases of exceptions to per node global introduction logic.
Well, what seems to be pretty important here is that you clearly place the limits on your logic. Just like you say, there might be some quite wild cases of combinations of things that will “confuse the hell” out of your logic.
That is why my latest version includes the notion of the cluster list. That means that you organize the information in logical clusters, such, for example, as “politics”, “entertainment”, “computing”, “news” and so on. That is the highest level of your categorization system, except I would not like to get into categorization systems at this point, even though I have a pretty interesting architecture of the UNIVERSAL categorization system, which, if I am not mistaken, would be an explosion of information mining in all sorts of places and areas, which is one of the most critical areas of information distribution and mining. But let us not get sidetracked.
So, the initial version would look like: you have some share, but it can belong to one specific cluster. Once in that cluster, you can not add the same share to any other cluster. That should cut off the myriads of logical and database consistency problems. And database consistency here implies not only data itself, but the combination of effects of your checkbox and general program logic.
Basically, the idea is simple: you MUST maintain and assure the consistency at ALL times, no matter what. Else, sooner or later the system will “crash” on you. One of the main issues with consistency is carrying around the duplicate values, be it duplicate states, checkbox setting or whatever in your logic.
Because, if you have multiple references to the same data and there exists multiple copies of that data, and some references refer to different copy, then you are pretty much GUARANTEED eventual database inconsistency and your entire database may no longer be trusted, at least from the standpoint of those particular values, variable, states, checkbox setting and you name it.
This means that once you have the same share in several different clusters, then you, pretty much, are inviting the eventual disaster, at least until you consider every conceivable case in all its aspects, which is a job I would not be willing to do at this point.
But what can be done right now is to assure that you can handle most of the realistic cases, and not necessarily all possible cases that could theoretically arise. For what? Why do we have to suffer if we can enjoy? So, fine, we do not have all the money and the “fame” of the world. But do we really NEED it?
So…
If we can cover 70 to 90% of all cases, I’d be really happy at this junction, before this thing evolves in its natural cycles. We don’t have to suffer unnecessarily, do we? What does it “buy” us?
And that is precisely why I said what I said above. At this point, there is no need for the grand unifying equations of the Universe. We’ll get that at some future point, no matter what we do.
And we do have a choice:
Suffer,
or giggle.
That choice we have no matter what? No one can take away that choice from us.
Again, if in doubt, use DEFAULT behavior. Stay with only those things that do not make your head ache. Any well written program should provide you this behavior. But when you want more excitement and have time and interest to dig in deeper, then you can spend some time on looking at things at less superficial level. Why not?
Yes, this is important to the point of being critical. But hey, I do not know much of what is going on with the project and I have not seen the priority list or the direction of development. About ALL I can do is to give my view on those things that are of main concern to me. And even if there is not time for it now, the information is already there. Who knows, may be some time will come where you say: hey, I LIKE this idea! That is about all I can do at this junction. And it does not much matter to me whether anyone does anything about it or not. I am not in a hurry that much. I can wait.
Well, thank you for the invitation.
I am glad to hear that, and, considering it is an open source, I DO appreciate that option I have with Syncthing.
This is probably the best part of it all, which I did not even think about. I did notice that CLI flying by my eyes here, but I did not quite pay much attention to it. Only literally yesterday it started buzzing inside me.
Yes! My opinion on the CLI is clear as a bell: Any well written program needs to have an interface that is available programmatically on the level of plain text.
In particular, I am not really much in favor of the web browser based GUI. Primarily because the browsers are not designed to be a sophisticated GUI to begin with. Things like drag and drop, huge lists and all sorts of other things simply can not be handled by the browser on top notch, high performance level.
So, if the program has full interface to all its mechanisms, then you can use it as a library of sorts and hang on it your own user interface where you can make miracles with the whole thing.
For example, sorry to mention the BTSync, but it has a Transfer screen which shows you the list of files being currently transferred and from where and to whom. So… Once you see some network activity, you may simply switch to that screen and see all the simultaneous transfers to all the nodes that are currently being updated or supply the info. I find this one of the most valuable views on the system.
If I had an interface to the engine, I could relatively easy hang a GUI on it which would do exactly what I want to do or see. With Java, which is as portable as it gets, you can throw in a fairly good GUI within a few days. Sure, it is not going to be “the latest and greatest that wold has ever seen”, but I do not have such requirements to begin with.
I have to think about this CLI thing and see if I could make it work and, preferably, hang a GUI on it.
Do you think it is doable?
Scratchy step-by-step instructions on setting up the introducer
After some preliminary testing on setting up the introducer, here is what it looks like:
On introducer node add a new repo/share via Add Repository choice.
Specify the repository name and path so it can be fully identified.
Click on the nodes you wish to share this repository with in “Share With Nodes” section of the edit dialog.
Note: If you do not enable all the nodes you wish to share this repository with, they will not get the notification of a new repository available to them.
At this point, after you restart Syncthing, you will begin sending the messages to all the nodes the introducer knows about informing them:
1:46:38: Unexpected repository ID “Reposityory_Name” sent from node “node_name”; ensure that the repository exists and that this node is selected under “Share With” in the repository configuration.
When some other node sees this message and it would like to join it, it needs to create that new depository on his side, specify the directory path and click on the checkboxes of all the nodes it wants to exchange this depository with.
Once it adds that depository and clicks on all the nodes it wishes to communicate with, then the connection is fully established and actual transfers start.
In other words, the communication with the introducer is not fully automatic and requires constant attention on the introducer’s end (to see which new nodes are there and then decide if it wants to grant them the access), and on the new nodes end (to enable all the nodes it knows about) to exchange this depository with.
If that is the case, it seems that the introducer node could automatically enable all the nodes it knows about, so they could start automatically receiving the notifications about the new depositories.
Unfortunately, we could not test the cases of completely blank new nodes coming on line. So…
Well, this seems to imply that the introducer has to periodically watch his repo edit dialog to see which new nodes are there and then individually enable communications with them. Until this is done, no new nodes will get the notification from the introducer about a new share available to them.
Is this correct?
Update #1
I am trying to understand the introducer functionality.
It looks like the introducer node can not enable the exchange with other nodes automatically. First of all, it might not even know that it is an introducer for some node(s). Since the introducer status is not set by the introducer itself, but by any node that considers that node an introducer.
This seems to raise some questions. First of all, any node can “fish” on the repos of other nodes by classifying them as introducers. So, even if there are some repos/shares that the introducer node (and its cluster) consider to be private, and not public, any node can “fish” on ALL of its repos. Sure, since introducer does not grant the rights to access its repose automatically, it does not mean they can actually get its data. But this could be a start. If some other node inadvertently grants some access to such a node, for whatever reason, then otherwise private share becomes public.
Am I missing something here?
The introducer concept seems to be vague in my mind as to what does it actually add compared to the situation where there is no introducer as such? The process still seems to be fully manual. The only thing the introducer add, it seems, is that it can broadcast the availability of some repo to some node(s), but only if it is even aware of them. Since new nodes may come in at any time and classify this node as introducer, and it manually looks at that particular share, it can not even start generating the information messages to them.
