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:
The list of shared directories ;
The list of confirming messages.
We can use the following algorithm:
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”.
The user can send the SHARE_ID to his friend by phone or by mail.
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”.
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.
First part sounds vaguely reasonable. 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.
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:
Alice’s device ID
Folder name
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”.
Alice generates the “magic” string, and their device remembers the secret
Alice shares the “magic” string with Bob offline
Bob enters this into their device
Bob’s device looks up the IP for Alice’s device ID
Connects to Alice’s device and sends the secret along with Bob’s device ID
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).
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).
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 mendelay.com,…
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!!
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
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.
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.