Automatic node discovery like Bittorrent-Sync

Feature
1

Syncthing support dynamic node name discovering, either by subscription or LAN.

However, as you might know, Bittorrent-Sync(as regular Bittorrent protocol) support a finding nodes whom share the same directory.

I’ve found a similar topic:

It was sound in this topic like public discovery is bad option. But I disagree:

  • Most people don’t mind for anyone to know they share some content, and contribute to files sharing bandwidth. The proof is Bittorrent.
  • For a place with many computers which sync content (I personally in such one), the contribution of distributed content sharing is obvious, but you can’t expect them that for each node they manually add all other nodes…
  • This doesn’t conflict with people who care about privacy. Such node could theoretically disable this feature.
  • In Bittorrent community, there are some private trackers. Such feature could be achieved(if intended) in syncthing by password/key protecting for discovery server.

As I mentioned, if it could be disabled, it’s not a bad feature.

I personally think that this is a great feature that lacks in syncthink vs Bittorrent-Sync fight.

Do you think it’s a good direction? If so, than what priority should it have?

  • Tal
2

It wouldn’t be impossible to add a unidirectional public master feature, meaning;

  • You create a folder, mark it as public.
  • You tell someone else the device and folder ID:s.
  • They add the folder on their side, it connects to you, and gets the repo information.
  • They sync changes from you as they happen.

What doesn’t happen in this scenario is that you sync changes back from them. Because that would require you to keep track of what files they have, which won’t scale when we’re talking “public”. It would also require some work to automatically announce other cluster members etc.

In principle we’d end up reimplementing BitTorrent, but crappier. It’d probably be better to start on top of BitTorrent, if security is anyway not a goal…

3

Hi Jakob,

what you described could be a good workaround for a use case I have in mind and described here: Can I use synthing to distribute content like btsync?

One way sharing is ok as I want to set up a distribution service not a shared folder.

4

Exactly juh2! I don’t think that not-single writing permission is the necessary option right now, but I wish (not manually) distributed file sharing, if the specified user forgive his privacy.

Is this goal doesn’t fit with syncthing? Is auto-discovery is so hard to merge with syncthing?

5

It’s not super hard, it’s just a bit different as everything now is built around the concept of a bidirectional sync (with the “master” exception kind of bolted on).

6

Not being a developer myself, I do appreciate a clean software design, because I believe it is better to have small tools that do it the right way instead of having a multifunction bastard that does nothing in a good way.

But as a user I am interested in use cases. Mass distribution of content might be a corner case that BitTorrent Sync covers better than any other tool.

But there are other use cases where let’s say 50 or 100 devices are involved. A company with sales representatives could update notebooks of their representatives via Syncthing. With the current UI this could be quite a challenging task.

1 Like
7

Sorry to spam the thread but love that, hahahaha

8

First, don’t be confused - I’m not talking about multiply write access, I think it’s good that there is a master node.

And for our matter, it’s just a GREAT feature that Bittorrent Sync has which Syncthing doesn’t. I’m convinced that such feature would attract 80%+ users of Bittorrent Sync, and make Syncthing a real alternative to Bittorrent Sync.

I still don’t see how adding options does not fitting with the UI and the code. I do agree however that this feature could change this software design, but again, I think it worth it. (from the perspective of the user, not the developer). Additionally, minor change in the software design doesn’t make the design less cleaner as said above, I personally think it’s just the opposite!

Lets think about this for a minute. If this feature would be insert, it could be break down to this capabilities(just demonstrating):

1.Write down basic auto-node sharing protocols. The basic one could be tracker-node. 2. Add 2 interfaces, lets call them NodePublisher and NodeFinder for this purpose. 3. Manage a set of NodePublisher and a set of NodeFinder, according to user discovery&privacy configurable options. 4. Activate those sets, and add nodes that has been found to the node set. 5. Integration with the UI.

I didn’t just invented this features, I know this as a user of Bittorrent protocol.

So yes, it’s not something that would be complete in the next month, but why do you claim this feature is so dangerous?

Do you see Syncthing as a potential full(and even more) alternative to Bittorrent Sync, or just another idea of manual nodes list sync?

Don’t get me wrong, I do appreciate your work, I only want this great feature.

9

We welcome all pull requests

10

I do believe that BTSync is removing the “automatic node discovery” in version 2 and you will then have to add each device as you do in Syncthing.

They’re also adding a “Pro” charged version << LOL. Hello new Syncthing users.

11

MY DEVICES All of your devices are now linked up through a common user identity which enables you to more directly manage all of your shared folders. Now all of the devices you have connected will have access to all of your shared folders. Your list of shared folders will be presented, and you can set your folders on this device to one of three synchronization states.

Taken from: http://usyncapp.com/2.0.30/BitTorrentSyncReadme.pdf

12

Looks pretty neat. If anything, we should probably at least copy the concept of a sharing link that contains all the relevant info to join a cluster+folder…

13

I assume the URL should then have all device IDs? Or would we enable introducer by default?