Well, this is probably one of the most important issues and there are some things to consider and implement to make things easier and more compatible with other approaches.
I am just beginning to look at syncthing, so I don’t have much idea about it. But being able to sync based on a key (hash) of a share (top sync folder) seems like one of the most desirable things to implement.
Also, using regular torrents “under the hood” could probably help the whole thing greatly and make it more compatible with other existing approaches that are well developed by now and open source code is available.
Then come the issues of peer discovery via standard DHT protocol and using the standard uTorrent type trackers.
This way, you can use hundreds of regular torrent tracker servers and, in combination with DHT, you become a part of the DHT global network and carry some DHT request traffic.
User configurable tracker list is highly desirable, if such is not implemented.
If regular and temporary torrents are utilized, like it is done in BTSync, then the whole thing greatly simplifies because there is a lot of open source quality code available in C++, Java and so on.
For example, here is the qBittorrent source:
http://sourceforge.net/projects/qbittorrent/files/qbittorrent/qbittorrent-3.1.9.2/qbittorrent-3.1.9.2.tar.gz/download
It is written in C++ which should be pretty easy to implement and port, and it includes a fairly complete set of functionality, including the DHT, trackers and so on.
There is basically no point of “reinventing the wheel” because things, methods, policies and mechanisms were already developed and source code is freely available.
The KEY word is torrents.
So, I am not familiar enough with the Syncthing, but it seems that the current approach of node discovery is good for the purpose of using Syncthing for private networks, which, security-wise is pretty good, except there is but.
But you simply must have to implement the general public distribution via SHARE (top sync folder) key, and not only via node key and allow automatic joining of swarms for all public shares without any user interaction or config file modifications, manual or programmatic. These mechanisms may work in parallel. But they are probably quite different and different sets of rules and principles apply.
The program simply must be BTSync compatible functionality-wise, even though to make it fully compatible is problematic because of some weird hashing/semi-encryption algorithms and mechanisms in BTSync, which is FULL of bugs. But you don’t have to be totally compatible with them. All you need is FUNCTIONAL compatibility so you could do the same things they do, and, probably, utilize the existing GUI status and progress reporting like it is done, for example in torrent programs, such as uTorrent. For example, it is highly desirable to show a dynamic picture of transfers, such as which exact files are being transferred right now, what is the progress of transfer, such as speed, percentage done and things like that. Otherwise, you just sit there and have not much of an idea of what is currently going on.
Not sure how this fits into current model, but it looks like Syncthing project is already something working, something functional, and I have tested a few things and, considering the stage of development, it is pretty good “as is”, except of this “but”.
Second issue I have noticed is pretty poor transfer speed performance. Not sure what the problem is. Could be a result of encryption overhead or whatever. It seems that the traffic should pump at the rate of 10 mbits without any problems. BTSync claims that on a LAN they can go at 90 mbits. What I have observed on some sample shares in Syncthing is somewhere around 200-400 kbits max, and that is not such a great performance.
Not sure if multithreading is utilized or design is single threaded, in which case there will be all sorts of problems, such as delays in transmissions while data is being encrypted. Everything in transfer engine has to be fully asynchronous and multi-threaded.
I have never worked with Go language, but it might be possible to use some C++/Java code in a library or via some language interface, which provides the DHT, torrent, tracking and all sorts of standard mechanisms for torrents. That would probably make it pretty easy to wire-in.
Hope this helps.