Read-only vs Distribution Sync

[pmow]

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.

[kos13]

It is interesting use case. However this is first time users ask about such behavior. Do I understand correctly that you want a share, that will be emptied when all piers got the data?

Complexity is that Sync doesn't know how many peers share the Secret. So if two peers got data, there might be a third peer that will come in few hours.

[pmow]

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:

If you delete a file by the sync application, you should be asked if you want to keep a deletion stub. That would mean, that the file on the other side is still being kept, but you could move the original file to another (non-shared) place (i.e. to save space on this volume).

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.