New idea using.DHT

I would like to present you an idea to get Syncthing more like BTSync.

However, I love Syncthing and I think that we shouldn’t change how Syncthing is working but we can develop an extern application to add the BTSync philosophy to Syncthing.

I propose to use a DHT (key => value) which has two types of data:

  1. The list of shared directories ;

  2. The list of confirming messages.

We can use the following algorithm:

  1. When a new shared directory is created, we generate a new ID called SHARE_ID. After that, we add a key/value in the DHT:

a. key = SHA512(SHARE_ID)

b. value = AES512( syncthing device id, syncthing directory id) which the crypto key is “SHARE_ID”.

  1. The user can send the SHARE_ID to his friend by phone or by mail.

  2. The friend enter the SHARE_ID. Our application hash SHARE_ID and find the value in the DHT. The value is decrypted using SHARE_ID and user’s syncthing adds the “syncthing device id” and “the syncthing directory id” of the initial share. After that, the friend’s application adds a new key/value in the DHT like this:

a. key = SHA512(syncthing device id)

b. value = (new user to syncthing directory id, friend’s syncthing device id) which ) which the public crypto RSA key is “SHARE_ID”.

  1. Finally, the initial syncthing instance check regularly the DHT if the key= SHA512(syncthing device id) exists. If this is the case, then get the value, decrypt the value with his private RSA key and adds the friend’s syncthing id to the share.

What do you thing about this ?

First part sounds vaguely reasonable. :slight_smile: The second part I think is unnecessary - since the SHARE_ID is a secret, the new device could simply present it as a password / one time token when first connecting, to validate themselves. I think is quite similar to what was discussed recently in some topic around here, except then we were using the discovery servers instead of a DHT, but same-same.

Some refs:

Do you have any security concerns? Otherwise it seems fairly plausible to implement.

No, no particular concerns, I mean it’s inline with what we’ve discussed before except then I called the SHARE_ID a “one time token”, and was thinking the discovery servers could do it instead of the DHT. But no, either way would be fine I guess.

So I am not concerned about where stuff goes, but rather how to do it. I guess if we do this HelloMsg business, we could trivially implement this. Otherwise polling could be used.

I might be missing something, but I don’t see the need for the DHT in this process?

If I understand correctly, this just achieves setting up a shared folder between two devices, without the initial device having to manually confirm that the new device is permitted?

I don’t see why that needs to involve a DHT to pass information between two peers. You’re already sharing a secret outside of the application, that secret can just be used to authenticate the new device…

If the owner of the initial device (Alice) sends the following to a friend (Bob) by email or however:

  1. Alice’s device ID
  2. Folder name
  3. A single-use SECRET

Now, copy and pasting these three manually is annoying, but we can just concatenate them into one string (device IDs are already long so what’s a few more characters?) and have a single input field for “quick-add new folder”.

  1. Alice generates the “magic” string, and their device remembers the secret
  2. Alice shares the “magic” string with Bob offline
  3. Bob enters this into their device
  4. Bob’s device looks up the IP for Alice’s device ID
  5. Connects to Alice’s device and sends the secret along with Bob’s device ID
  6. Alice’s device can then confirms that the folder should be shared with Bob and skips the manual confirmation usually required 1.1 Both Alice and Bob then forget the secret as it’s no use any more

The only reason I can see for the DHT is to allow the initial device to add the new device without both devices needing to be online at the same time. Given Syncthing is P2P there isn’t much benefit to that…

Again, sorry if I’m missing something, but I just don’t see the need for a DHT to pass messages between two devices who already have a shared secret…

Agree, DHT is totally redundant here, and all of this can be delivered via discovery servers.

So this is all well if you have 2 devices, if you have more, it’s not clear what the right thing to do here is. At the point you connect to Alice, should you auto-trust all the devices Alice is sharing the folder with? At which point any of them might be an attacker which exploits a bug in syncthing…

If not, and you are expected to add all devices manually, then it’s just as bad as sending the device ID around (because you already have the folder).

I purpose to use a DHT for two reasons:

  • don’t change the core of Syncthing
  • don’t depend on a central server

You still depend on server(s) for bootstrapping the DHT, and introducing anything of this type will be a change to syncthing.

It’s for that I purpose to add this in the GUI wrappers and not in Syncthing.

I’m all for prototyping this outside of Syncthing. If it turns out to be awesome, we’ll happily integrate it.

I am just afraid that we will end up with another out of process bolt-on ;D

People, more often than not, use Syncthing between multiple OSs. That makes implementing it in the existing wrappers a bit painful…

Agreed, sharing folders is a core part of Syncthing functionality that affects every platform. Implementing it in wrappers means lots of duplicated efforts.

If you don’t want to roll it out to all users, make an alpha version, or hide it somewhere in the settings.

So I am fond of this whole idea which removes extra steps in getting up and running (and potentially getting us closer to hiding devices, as they stop mattering), we just haven’t fleshed it out how users expect it to work, hence I think we should have a discussion, summarize and create a wiki/feature/milestone/whatever.

Yes. I’m pro having this in the core. But it’s not fleshed out. Hence if someone wants to work on it, doing it externally would be one way to get it fleshed out. But by all means do write up the details etc and implement it in core if you like (for “you” being anyone out there).


Synchting is GREAT!

There is need at science people to have open system to distribute scientific paper’s. Also we open eBook’s and libraryes.

Syncthing could be easyly developed to work as well as public shareing system Open Science paper’s, Open eBooks,… This type information need’s more complex search/index system and connectivity to library indexing programs like,…

There could be choice to have encryption in use or not depending network, material source,…

So,… BTSYnc whit better indexing and possibility not to use encryption to save system resources!!

There are better solutions for that. IMO that’s out of scope for syncthing.

No, see site search:


I started with Syncthing two weeks ago and it’s a great piece of work. I’m running my own infrastructure with relay and discovery server. Btw. running a discovery server behind an Apache reverse proxy wasn’t that easy to figure out the details :wink:

Back to the topic: I have one node which is always online. Therefore it is reachable by all my mobile nodes. I defined the shares from my mobile devices and gave them share names. I published these shares to my central node. Unfortunately I gave them identically names. That is a problem. Finally, I ended up with names like ‘Devicename/Sharename’. Now it works.

It would be great to have share IDs. When I create a new share on a node, it should calculate a random id for that share. Additionally, I would enter a name, which has nothing to do with the syncing process itself.

What do you think?

Cheers Micha