ChrisH

I didn't say that. But the reason I am reading this forum at all is that I want to make sure requested features are thought through all the way before a developer acts on them. Development resources are limited, so let's make the best out of them. And in my opinion showing the free space on a device only if it is actively connected is not as useful as showing the last known value if the device is currently offline in BTSync (which phones tend be to save power). Why can't you take that the way it was meant - as an improvement of your idea?

I fail to see how. The idea here is to have a type of secret that allows only uploading without access to the files already in the shared folder. Your idea is to create shares automatically by putting the secret in a special file. How are those two connected?

Then maybe BTSync just isn't the optimal solution for your requirements and you would be better off with a traditional system that uses distinct credentials like username and password specific to each user. Anything slapped onto BTSync with its peer-to-peer design will just be a makeshift solution, not an inherently secure one.

I know, but asking for a feature that only works for your (pretty specific) use case is a bit short-sighted, don't you think?

It would also need some history function to show the last reported space even if the device is not connected right now. If I have to start / wake up BTSync manually on my phone so I can see the available space info in my desktop's BTSync, I can just look on the phone myself.

As soon as you share a folder with someone, you lose control over the contents anyway. Even with your idea of communication codes, you cannot stop them from just creating a new BTSync share (with a secret THEY control) with your data in it. Or posting it to Facebook or whatever. You are looking for a technical solution to a social problem. If you don't want someone to give away your data or your secret, tell them. If you don't trust them, don't give them your data. It's as simple as that.

So... your idea is just a workaround so you don't have to create folder two on the server yourself? Seems a bit involved to me, and it doesn't really have anything to do with the original proposal in this thread.

(1) no idea (2) last change wins (3) depends on your configuration - you can have circle, star or full-mesh setups

I like the idea, but it needs more security than just the device name (which could easily be brute forced and then existing files could be overwritten). I would also like to see some sort of quota to restrict the upload size per device.

The "problem" in the current design is that there is no single machine A. There are (potentially) lots of As and they are all equal. If you have only one A, simply re-create the folder with a new secret. (Yes, you have to send the new secret to all other Bs that shall continue to have access.) I unterstand your requirement, but as I see it that would mean a major change in BTSync's design. You would have to introduce a central instance or control server. I would like to have that as well, but like I said, that might be something for the business version.

That works in Dropbox because the Dropbox servers are the central instance. This differs conceptually from the way BTSync is designed. There is no "master" that could control access or distribute new keys. Maybe the long-promised "pro / business" version of BTSync contains something like that.

Yeah. Encrypted data does not compress well (or at all).

I use BTSync only over tinc connections with compression already in place, but +1 from me anyway. Since the transfer is already chunk-based it should be trivial to compress the chunk before sending it and decompress it before writing it to disk.

- Warning if storage device is full (I was syncing photos to a EDS container and spent an hour finding out why BTSync would not sync new photos to my mobile until I thought of checking the container size) - Option to show all files NOT on the device

You could just create an upload folder on your server with identical structure as your normal work folders. Share that via BTSync and let a script run regularly (or on an "upload complete" event triggered by BTSync API) on the server that moves all new files from the upload structure to the work structure. As soon as that is done, BTSync will delete the file from the client's upload folder. You still won't have access to your existing files while offline, so I'm not sure if that idea covers your requirements.

One without the other is pretty much useless.

What's the advantage of NSSM over just running BTSync as a scheduled task? You still have no access to the GUI because BTSync on Windows was not designed to run as a background process.

I think for that you'd need some kind of master node with a separate "upload" share. Any member can put files in the upload share, and the master node moves those files into the main share (that is readonly for everyone else).

I think the way to do that is take an already working VPN solution (like tinc, maybe) and add some sort of tracker server and NAT hole punching functionality to it. Developing the VPN part seems to be more complicated and error-prone to me than the tracker part BTSync already has.

You make a lot of good points. I'd just like to point out TrueCrypt, which IS open source and recently had a (community funded) audit that proved the binary files are indeed compiled from the public source code AND contain no backdoors. I agree that open source is overrated by many people, but the fact remains that such independent verification IS possible with open source software, and NOT possible with closed source. Whether the verification is done at all and if you trust the people that do it is another topic.

I think there are enough remote control solutions (personally I use Teamviewer) that work without the need for port forwarding. I think your request would be more in the scope of a bigger Mesh-replacement application that integrates both RDP and BTSync functionality. Maybe Hamachi and BTSync might make a good combination for your purposes?

What's the difference between two secrets consisting of 128 bits each, and one secret consisting of 256 bits? You still have to guess all the bits. And whether you have to change the pre-shared key or the secret on all non-outdated nodes does not make any difference, does it?

I would never use BTSync or any other distribution system without per-user-access control for that scenario. If you have to use BTSync, use it in the internal LAN or over a VPN with additional user authentication only. What happens if the employee just stops or blocks BTSyncControl so the wipe command never gets there? How do you make sure the secret change command (you did not describe that, but you'd need one, right?) reaches all nodes? How do you stop employees from creating their own shares without them using the control mechanism?

+1, see also http://forum.bittorrent.com/topic/29659-btsync-as-a-windows-service/

So simply set up one shared folder per client. And for true backup functionality remember to set sync_trash_ttl to 0 - otherwise deleted files and old versions will disappear from the backup copy.