pmow

A CDS with a simple interface (like a download manager, just configured with a download location) should be possible though right? I'm not sure what your requirements are. The API app would simply move the file out of the share, to the configured directory. Would that not accomplish what you need?

Couldn't some rudimentary CDS functionality work with the API as it is? Using a read-write share for each user, and the "end user" removing the files/folders once sync is done?

You want to multihome one or some of your peers. The problem isn't exactly commonplace. If anyone has multiple internet connections, I would imagine they would do bonding to achieve better speeds on all applications, for upstream and downstream.

You have a data-integrity distro installed and not making use of it. Ideally you would push snapshots (incremental backup) to your Ubuntu box. Assuming normal use case, they don't take much space so you can probably do daily full backups. You can't do that with BTSync. At a moment's notice you can do an export of any given snapshot. You can't do that with BTSync. You can trash old data based on space available; You cannot do that with BTSync.

Yes, it would be great. This was requested already. I think the design would be a problem for multiple destinations. After all, how does the app know how many people attended the birthday party? Or if you're sharing with colleagues, and the sync keeps a record of which computers it's completed a sync to, you would have to know computer hostnames of everyone. It's a nightmare. This is useful in so many situations, though.

Sparkleshare doesn't do large files well. Peerdrive doesn't have downloads, and the others are a joke. Gosh I love BTSync.

Dropbox has done this forever. I don't like Dropbox, just sayin'. Other sync apps, like Insync and AeroFS don't do it though. Exactly...just frustrating!

In reality there are two uses. One is a single-use case, which would replace locker services. The other is a subscription model. Your understanding is exactly right. While you may have less interest, there is at least one I found: The reason I think that you have less interest is that users don't know this is possible. It would replace having to use services like the old drop.io or other "drops". Based on how you say BTSync operates, I would say the easiest way to implement would be the following: 1. A flag for a synced folder for the other peers to ignore deletions at the "source peer". This would be similar to how you have a read-only peer now. 2. Options at the source peer to auto delete files/subfolders based one or more factors: number of peers completed, number of days since creation, etc. 3. Options at the source peer to auto delete the synced folder based one or more factors: number of peers completed, number of days since creation, etc. There are more elegant ways of implementing this but I think the above is the easiest for BTSync to do. After all, it's a "sync" app. This is similar to rsync's --remove-source-files option.

You could try writing a program to generate .Syncignore files and config files for all clients based on the Windows ACL or maintaining your own. It wouldn't solve your issue with local admins. Local admins aren't really something you should do anyway, but it's understandable since half the company is in the field, and if there's a critical issue, it can save the day. The biggest issue isn't a technical one, it's a trust problem. You trust your employees with absolute control over the computer, but not over the shared files. You require a client-server solution to centralize control.

In today's world, an Rsync-based app would want to override Rsync's block size maximums. It's better to hash less and waste a bit of transfer, otherwise NAS devices would be off the table.

BTSync serves its purpose, and I got slightly excited when read-only sync was listed as a feature. My excitement was unfounded but I do understand the whole point is to "sync". I just feel that read-only sync misses the mark in terms of popular use cases. It would be great to have either an option in ready-only syncs, or a new sync type for file moves across the internet. IMHO this would fill a huge void for the large file problem. I'll use a couple examples with pictures. Scenario 1: You take some photos and want to provide copies to an acquaintance. You create a "Distribution Sync" share, and BTSync would automatically delete the entire share once the entirety is transferred. Scenario 2: You want to "subscribe" a family member to your family photos, and will provide the pictures ad-hoc to this folder. Since you are making copies of only family-related photos, you want to get rid of them as soon as they have a copy. By using the "persistent" option, the folder doesn't get deleted but instead is preserved for future use (for new photos next month). There are obvious questions/concerns, but even a rudimentary way of doing this would be awesome in tackling the "large file problem". This would be most similar to something like Leapfile or a locker site.