"use Predefined Hosts" Allowing Non-Defined Peers?

[fragtion]

I understand that this project is still in beta phase, but there are a few obvious quirks which should be fixed asap, and I think this is one of them:

 

I have a share where I have explicitly checked only "Use predefined hosts" in the preferences for that share (no DHT, no tracker, no relay, and no LAN search). I specified the desired hosts to sync with, however under the "Devices" tab, that share is showing all peers using that share key (including those which are not part of the explicitly defined list) - such behaviour continues even after restarting the app on all nodes.

 

This can become problematic if you wish to have a central dedicated server/s and a number of lower-speed clients, and you wish for each of the clients to sync through the dedicated server/s only - but instead they seem to sync with each other as well (or is that just a status report?) which can saturate their respective upstream bandwidth

 

Is there no way to restrict a share configuration to predefined hosts only on a client-by-client basis? This will allow greater control as expected. Right now the "Use predefined hosts" can be deceptive/counter-intuitive if it's still going to connect to the other peers as well. At the very least there should be another checkbox next to that one saying "Restrict to these peers only" ? I assumed such functionality by default, which does not seem to be the case after all. This could greatly enhance security as well, as no alien peers can connect to such a configuration which only accepts the predefined hosts

 

I guess right now the "Use predefined hosts" feature functions more as a "Peer-finder helper" than an "access list"... if so, how could we define a strict access list for a given share, and shouldn't that functionality discrepancy be more clearly defined?

 

It seems I am not the only one who has misinterpreted the behavior of this feature - I've found some articles via Google which review this software, where the authors also misjudged the "Use predefined hosts" feature as being a security enhancer, assuming that it excludes non-defined hosts by default, which clearly it does not. Am I maybe just missing something here?...

[RomanZ]

Hi fragtion

The "Use Predefined Hosts" option is indeed a "peer-finder" first of all. By configuring these hosts and ports you let BTSync know that these peers are going to listen on certain port, but not restricting peer to only these nodes.

 

When exchanging data, all peers also share the information on all peers available. So if only one peer in your setup knows of another peers over internet - it will share this information with all peers it sees online. If you want to prevent such behavior, you need to setup pre-defined hosts on all peers and disable LAN search, tracker, relay and DHT also on all peers.

 

We'll consider your proposal on "Restrict to these peers only" for future releases.

[fragtion]

Many thanks for your response RomanZ. It's good to hear that you guys are going to consider the "Restrict only to these peers" feature idea, which would certainly be great if implemented. Unless I misinterpreted you, then I'm also really glad to hear that it's possible to simulate the desired behaviour in the meanwhile by making sure that all the peers simply have the extraneous search options unchecked besides for the predefined hosts. Will give that a try so long and see how it goes

[kramb0l]

+1

[spacedout]

+1 on this too.

 

This feature would help me allow Sync when the PC is connected to LAN via Ethernet or WLAN and disable sync when I'm connected with OpenVPN via 3G Modem (as the IP address of the laptop would be different when connecting through OpenVPN)

 

Currently I'm having to Pause Sync manually everytime I leave the office and turn it back on as soon as I connect to LAN

[4mc]

What's the state of these considerations?

My wishes and issues are the same as those of the user who started the thread: i want to force (or restrict) the exchange of sync data to certain high-performance networks and keep the weaker ones clean.

Also the mentioned security enhancement coming along with such a restriction, is a concern of mine.

[fragtion]

It really seems to me that the implementation of bloatware and subscription fees became a much higher priority for the developers than the implementation of actually needed/useful features such as this, which would have gradually allowed BTSync to become the very state-of-the-art, widely used/'go-to' tool for simple, flawless and efficient cross-platform syncing capability that is optionally gui-enabled - effectively a bi-directional (multi-peer actually), fully automated/hands-free rsync on steriods - at least that was the very promising experience I had when first trying this software out at v1.3, and indeed it seemed to be well on track to realizing this great goal

 

But their new approach since Sync 2.0 has defeated this objective: BTSync is no longer a lightweight, free utility - there's no real use caring if they even implement this anymore. It's not so simple to deploy, or use anymore (even after you've dealt with the bloat/nagware) - so yes, let us rather keep the suggestions to ourselves and allow the paying customers to instead provide feedback, because the developers clearly won't allow us to reap the benefits of our suggestions anyways, plus the subscribers' ideas/requests will obviously be given higher priority. If this feature does ever get implemented, it will probably be on a 'subscription extra' based model, meaning that you will have to foot an additional monthly subscription to unlock such capabilities. Sounds crazy I know - but how far fetched is it really, in light of what they have already done? The truth is, we have no guarantee anymore so more handicaps such as this, on the free version, become an increasingly more plausible reality

 

I know I am being spiteful, but I simply cannot otherwise fathom/express my infuriating frustration over the fact that this project made such a radical 180 turn on us, especially in principle, given the fact that they EXPLICITLY promised to keep it free for life. For this reason, I can't wait for the open source alternatives to evolve further (just a matter of months now) so that the notion of paying a monthly subscription fee for a decentralised p2p sync tool becomes increasingly more obviously absurd!

[entropyeater]

Hi Fragtion,

As our VP of Sync, Erik Pounds, has expressed, we are still interested in creating a great free product. And we share your vision of a powerful tool for syncing. We really appreciate your engagement and participation in the forum and in helping us catch bugs and make sync better.

 

As for this particular question: we are evaluating whether to automatically prefer faster peers, which would address the key usecase brought up in this thread.

As for the other usecases:

1. Improved security and/or denying peers: we have implemented the permissions control system in Sync 2.0, which is a more secure and more usable way to control access to your data.

2. Enable/disable syncing based on network or location: we are aware that this would be useful for some users in some circumstances. Please let us know if we're missing a widespread usecase where this would be useful. While it's not automatic, using "pause" for Sync or per-folder might meet your need in this case.

 

Sorry it's taken us a while to respond - we are busy making new features, some of which are going to be enhancements to the free product! I hope you you will find them useful, and I trust you'll let us know what else we can do in any case.

 

Best regards,

Daniel Erwin

Sync Design Lead