Something similar has already been discussed here, but I wanted to bring it up again, in a way that’s hopefully easier to implement.
My proposal is to add a “Share Folder” button to each folder (next to the scan/edit buttons). Clicking this button would show a string in the following form:
folderid=myfolder&deviceid=mydevice
This string can then be copied to the web interface of another Syncthing node. There should be a menu option (or a field in the “Add Folder” dialog) where this string can be pasted. Entering the string automatically adds the device and folder, so all you have to do is confirm it on the other side.
Of course, the exact format of this string can be changed. Other things we could add to the string are the folder label and device name, as well as any specific folder and device settings. We could also include the IDs of other devices that have this folder.
Of course, copying such a long string around is not perfect, but I think it’s still better than copying device ID and folder ID around seperately, and entering all the settings manually.
As someone that just rebuilt my entire Syncthing network (was reformatting my laptop for mint 18 and figured it was a good a time as any to upgrade to the newer share format where the folder name and ID were separate items - THANK YOU for implementing that by the way, devs) Having to enter in all the exact same folder settings for 30+ shares got old really fast. That night, I had dreams about ‘refresh time to 600 s, simple file versioning, 5 copies, normal folder, cut and paste ignore patterns’ over and over and over.
One of the most common activities for setting up syncthing (I would assume) is simply cloning shares and their settings to a backup machine(s). A single step that clones the folder name and settings as a single copyable string would be awesome.
edit - or alternately (and probably more practical), when you sync a new shared folder to another machine, you have the option to copy the folder settings over and review them before copying them to the current machine. When a server sends a folder share request, there would be an additional button that would bring up a modal that lists the server’s folder settings for that share. Each could have a checkbox next to it that you can uncheck. All checked settings are implemented in the local share.
While I sympathize with your pain, do keep in mind that 95% of people have 11 folders or fewer, with three folders being the median (source). That is to say, your use case - not that there’s anything wrong with it - is an outlier.
Sadly, registering URI handlers is super painful.
Plus, your idea of sharing ignores is potentially unrealistic, as some people have a lot of lines in the file, way past the URI limit.
Its just a String to be cut&pasted to the other Syncthing Instance as well. It would be an Improvement for non-Technical Users. You just give them the URI String and say that they should paste it into an specific Field in the Webinterface. et voilà - Folder shared.
Maybe some of the Clients like Synctrayzor would implement an Click Handler (Advanced Stuff; Depends on Platform etc.) as well.
Sharing Ignores is not my Idea (Maybe do you mean Dan?)
Personally i dont see other Settings except of Label (Which is optional/suggestion)
Registering a uri scheme also assumes that there’s a single syncthing instance on that machine which will take responsibility for handling that scheme, which is the case far less often than you might expect.
How about having the graphical wrappers implement the uri-registration. Syncthing, as mentioned in these kinds of discussions before, is not a desktoppy thing, the wrappers are and the uris make more sense in these environments.
Still, providing a “copy and paste”-solution for a device-folder pair would be nice on a server as well, so nutomic’s solution sounds good for “vanilla syncthing”
Yeah, the syncthing: protocol handler could be an optional thing which is handled by wrappers if possible. But I think that’s optional, and having the basic copy/paste option would already be a huge improvement.
As Audrius mentioned, URIs seem like a problematic way to do this. Length limits, dependence on the GUI, etc.
I mean the protocol is sending data anyway. Why not just have a specially marked data packet(s) that accompanies a share request that has the configuration data in it. Essentially mark it as a special file. That means there’s no upper limit on the data length and it can be sent to a command line interface client.
I agree that a “copy link” feature (format: DEVICEID/FOLDERID, no protocol uri) would help non-technical users. But is has to be clear that this is a Syncthing only link and that they have use the “past link” function in the menu on the other side. The question is what happens afterwards: add (new?) device with default settings and open prefilled “add folder” modal? Or open “add device” first, let user enter/confirm, and then “add folder” as second modal
Maybe I don’t understand your situation, but when I add a device, this device receives a message asking if it accepts. So, no need to manually enter the device ID.
Same thing for the folders : when I flag a device OK for a folder, this device receives a message, so no need to enter the folder ID.
Right, but it means that you have to copy less, and generally have to take fewer steps. Of course, there are also other places where we can make the setup simpler. For example, we could merge the notifications for adding a folder and adding a device, so you only have to accept once.
I still don’t understand. The very first step is a creation, not a copy. Even the first device (and others too) isn’t manually created: it is self generated by ST first run. Only the first folder is manually created by the … creator . Other participants only have to accept or decline.
Something else I don’t understand with your copy thing feature : what about the folder’s local FS path ? Would it also be copied from the initial source device ? Same question for other attributes of the folder (std/master, versionning and other advanced setting).
. Other participants only have to accept or decline.