Search the Community

Showing results for tags 'wishlist'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Resilio Sync
    • Sync General Discussion
    • Sync Troubleshooting
    • Sync for NAS (Network Attached Storage)
    • Sync Stories
    • Developers
    • Feature Requests

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 4 results

  1. Hi Folks, We now have a dedicated "Feature Requests" sub-forum for BitTorrent Sync! If you've got a suggestion as to how Sync could be improved, or ideas for possible new features or functionality you'd like to see in future versions of Sync, join in the discussion over in the new Feature Requests sub-forum The BitTorrent Sync forums are now arranged as such: Sync General Discussion (the forum you're reading now!) - A place for general discussion of BitTorrent Sync Sync Troubleshooting - Having problems with Sync? Found a bug? This is the place to post about it! Sync Hacks - Share awesome things you can do with BitTorrent Sync! Sync Developers - Building something with the Sync API? Discuss it here Sync Feature Requests - Got a Feature Request or a suggestion you think would improve Sync? This is the place to post and discuss! So, when posting about Sync, please select the most appropriate forum from the list above in which to make your contribution.
  2. Hello. Recent Windows can mark a network profile marked as "metered connection". I do want BitTorrent sync to have an option to prefent file transfer over metered connection profiles, but only with peers over non-metered network profiles. Thanks,
  3. If we had a BTSync CDS (Content Delivery System), as a separate client with some extra abilities I can see endless possibilities. In this post I realized BTSync creates a new torrent for each file. This is a far more clever way to deal with updating torrents that what I would have imagined. Props to the devs who came up with it! If each file is its own torrent, then all we need (if it isn't so allready) to make a sofisticated CDS is to be able to construct a share out of the existing torrents, and distribute the appropriate keys to decrypt, or download the files. The most important feature of BTSync is the ability to be used by someone who doesn't know left from right on a computer. You can make an installer that creates the folder, and sets up a share for your grandmother, all she has to do is download an executable, double click it (then click past the billion warnings if she uses windows) and voila, you have a shared folder(or folders depending on your needs). You could make two folders for instance, one for sending (where she has to have read-write access) and one for receiving (where read-only would be better). Hoarders of data like me is likley to have several terrabytes of data, to sync all this to my grandmother would be extremly inconvinient, and undesirable as parts of the files are private, and parts of the files are uninterssting to her. But when I setup one or more nodes to mirror all my files, I wouldn't want to have to make a symlink on each and every node (I might even be unable to if they use read-only encrypted secrets), if I then were able to use the BTSync CDS to link my /massive-btsync-folder/picutres/respectable-christmas-photos/ to her /home/grandma/shared-folders/lolcat/incoming, she would be able to join the swarm and benefit from the aggregate bandwith of my servers, and whomever else I shared the file with. The BTSync CDS could allow all kinds of interessting combinations of data, something that would be far out of the scope for the average Joe who just wants his girlfriend to get his phone pictures, but would be perfect for people who share a lot, and have a lot of files. This way we enable advanced users to fully utilize the opportunities the software provides, while still making the basic features extremly simple for the normal users who is just thrilled that someone after all these years invented a way to send files without hassle. I am not sure if this is features that "Sync Enterprise Beta" is planning, and therfore Bittorrent inc is unwilling to allow API calls to enable the creation of this software. I do see how this would be usefull for managing massive shares for a big company. An intranet where access is ensured, and speeds are fast both internally and externally. The ease of adding all the encryption read-only keys to an existing share would allow seeding, backups (if the secrets are also backed up) and distribution without having to care about the platform, or implement additional encryption. Either deploy the btsync application to a server (virtual or dedicated), or find a provider that will accept your encrypted read-only key, and voila it is good to go. It is so simple, yet so brilliant. I can see so incredibly many uses if you could cross refrence files between shares, add shares to other shares, and modify the share structures. Bill quits, no problem, make a new group share, sync the old one, attach it to the required users shares, and delete the old one. Downloading is slow in the building across campus with the slow uplink: just add a node there, install any OS, give it an encrypted share, and add the shares and files relevant for that group to it. Data is encrypted, and speed is ensured. A few client features would also be benificial for this system, first it has to be able to get the secret for each file and store it in a database. In addition it should have some way to backup the entire list of secrets, think something like KeePassX, a master password, and you can see all your secrets, you could even sync it to your phone, then if you need to share a folder, you can simply generate the QR code, and they can add it. And the clients API would have to be greatly enhanced. It seems the features of the API is rather limited at this moment. The ability to add web-seeds and a share browser would be nice (almost like ĀµTorrent, you can walk through folders, see what is there, and then download the files you would like), although a setting to not download anything, and ability to download one and one file through the API would make us able to produce this ourselves. Improved statistics would also be important to monitor preformance and discover bottlenecks. It would be nice if BTSync provided a way to easily identify if the storage media, or network, or the cpu, or ram is the bottleneck. This would make improving preformance much easier. The ability to bind to different interfaces is also important, maybe you have multiple networks, NICs or internet connections. Being able to bind to only the network interfaces you want makes setting the network up easier. Then you also need to be able to configure them differently, and preferably be able to setup rules for seeding. Being able to specify a blacklist or whitelist would enable this. The BTSync CDS should be able to analyze the preformance of the nodes, I wonder if the easiest way to do this would be to add your own tracker, and then have all the BTSync instances report back their numbers (max speed, min speed, average speed, how much downloaded, how much uploaded, possibly CPU use, ram use, free disk space too). It should also be able to connect to nodes and specify behaviour, like when to sync, bandwith limits on different days, and times of day, limits on who to seed to, and prioritizing specific shares or users. A node only serving the LAN would be desirable in many setups, or a "master" node only used to sync the other "master" nodes. Then you could setup a master node to sync other master nodes and ignore users (preferably the ability to limit or ignore users or user groups based on the day and the time). So now all we need is to fork BTSync, or hope for the developer to open up the API and add the few missing features to allow us to make this work. After the API and the features are implemented it is just a simple matter of programming. I would love to hear more about your thoughs and ideas around this.
  4. The main wishlist thread has become somewhat cluttered because all issues (protocol, features, UI, bugs) are mixed together. I would like to clear that up a little by starting a separate thread for all UI improvements, i.e. all things that can be made better without adding core features or changing the core behaviour of sync. Since I only use the Windows GUI, I cannot speak for Mac / web GUIs, but from what I could see on screenshots they should be pretty similar. Feel free to add your ideas or comment mine here. My wishes: show the folder (number or short name) in both the "transfer" and "history" tabs add a separate "queue" tab showing all yet unsynced files as a treeview per folder and device with options to skip / ignore single files (or maybe integrate it with the "transfers" tab?) show conflicts / overwritten / deleted files in a separate tab with options to restore the overwritten version show an ETA and/or overall sync progress show a drill-down report at the "finished syncing with <DEVICE>" event so the user can easily determine what exactly was changed without having to scroll through the history tab add an option to skip / defer a running file transfer from the "transfer" tab so more "important" files can be synced first separate the GUI from the worker daemon so BTSync can run as a native Windows service (or use the existing web GUI also for Windows - whatever works)