lolcat

Mine? They all have random IPv6 addresses and IPv4 starting with 37.191.*.*. I could check the exact IPs if they are relevant.

https://gist.github.com/sebknzl/8027609 <- If you use Linux or BSD I guess you could use that to bind the to one NIC? If you have an API key you could always set one of the instances to not download anything, and bind it to the other address. If you don't have an API key I suppose you could try to figure out how the "selective_sync" attribute in sync.dat works, and if the client respects that setting. The file seems to be using bencoded lists.

If you use ZFS you could turn on compression in the folder, then it would take a lot less space (as most of the lines are pretty similar). Just make a new zpool for the folder, and enable compression.

It did in the first two pages, then it rolled over to discuss "Should BTSync be open-source?" and "Will BTSync be open-source?", besides it is a rather old thread. For me to derail an already derailed thread seems like an exercise in futility.

Those discusses weather or not BTSync should be open-source, rather than what we could do if it was. These are two very different discussions. Obviously from any users perspective it should be open-source, so that is a rather pointless discussion. The possibilities if it was on the other hand is interesting.

I'm working on it, but they haven't given me my API key yet. So as a work around I decided I could just start modifying the SQLite databases that BTSync uses. It appears I could be able to make selective downloads enabled for any user by just modifying the BLOB in the "files" table of the database associated with the sync. If ignoring a file is as easy as setting "ignored" to something else, then I could make a tool that goes through a database and ignores every file or ignores all the files in a folder. I find the owner string to be somewhat interesting, and it is unclear what the sig part contains.

Or BTSyncs UPnP implementation. It kept trying to communicate with my television. I just disabled UPnP, it is pointless to use. I don't have a NAT and all my devices are open to the internet.

tail -f sync.log | grep whatever Replace "whatever" with a word that only is on the lines where the transfer complete notes are.

I am a bit uncertain if BTSync uses a modified or stock version of the Bittorrent protocol, if it is the sock version that would require a computer to encrypt all the files to create the torrent file, in this case creating a share would always be limited to the speed your CPU can encrypt something with AES. It seems unlikely the developers can somehow revolutionize how AES is done. The process of creating the share would be something like this: Create bootstrap torrent (contains a sqlite database of all the files and their respective torrents) -> encrypt a file inside the share -> make the torrent hash -> update the bootstrap torrent -> rinse and repeat until all folders and files are added. If they use some sort of modified version they would probably get away with something like: Create bootstrap torrent -> create torrent for each file -> update bootstrap torrent. It is also possible they never update the bootstrap torrent but rather add new torrents for new files, exactly how this is done is unclear. If it is the latter method you won't hit the AES overhead until someone requests the files, if it is the first you would have to encrypt it first, and then again every time someone requests it (this can be avoided by having to sets and using the encrypted read-only secrets). In the beginning I'd disagree with this, but since the encrypted read-only keys exists I feel adding backup to BTSync would be pointless. This doesn't mean using it along with a backup program couldn't be done in a good way. Simply use any incremental backup tool to make a backup to a computer on the network, and then use BTSync to replicate that backup to several off-site locations. This solves the biggest problem with backups today, the lack of bandwidth. With CrashPlan I get terrible upload speeds, and to upload to several locations I'd have to use my slow home connection to upload my backup several times. With BTSync my off-site backups could simply sync with each other, thus reducing my bandwidth needs considerably. To use BTSync to copy files seems like a terrible idea. Or you could spend a little time and figure out how the secrets are generated and then make your own.

Would you like to elaborate how it is less reliable? Apart from older files overwriting newer files and the client refusing to sync there should be no problems. I am not sure which of those scenarios would be worst for your setup. If you increase the value, you risk someone updating a file, and then having it overwritten by an older version because their timestamps would be different. I am not sure if BTSync converts the time zone to one of the standard time zones or if it just uses the time as you see it. If it does it in a sane way, it would convert all the times to CET or UTC, and then upload it. Preferably it would also use some other source than the system clock as they can be rather unreliable. I would not increase the setting if you are editing the same files, as that could cause the newest one to be overwritten by the oldest one (it would still store the old version somewhere, but it would be an annoyance). I would probably keep it as it is, and rather use two shares. One that is maintained by one person, where everyone gets read-only access, and one where anyone can dump updated documents.

I am sure anyone with a couple of hours of free time can figure out how the encrypted read-only key is generated. So there would be no need for you to give it to me.

I will assume you are living in a supressed regime, or it is a non-government entity that hassle you for your bittorenting and that what you are downloading from TPB is Bick Buck Bunny and old Wikipedia dumps. The reason you want privacy is a moot point, privacy is a human right, and I am all about enabling people to enforce their universal human rights. Lets just say those american shows are in the public domain, and is about Kim Jung Ill, and that you live in North Korea and would get in trouble for downloading something that could potentially be unflattering for the great leader. I would suggest one of the following setups: 1. Obtain a server or access to any computer that will let you install a bittorrent client and BTSync. Then you set up the bittorrent client with a watch folder and set it up to move finished downloads to a different folder. Then you setup to BTSync shares, one for the watch folder (it only needs read for this folder, I am not certain how torrent clients react to partial torrent files), and one for the finished downloads folder. For the finished download folder I suggest you grab the keys from this random blog that may store your keys for whatever purposes. That would enable you to have the encrypted read-only secret. Now you add the encrypted read-only secret in your home BTSync client. I would not trust that website to generate keys for anything secret, but he does not appear to be working for north korea. If you belive he does you could always just manually encrypt files (way too much effort for the offchance the blogger is working for north korea) using whatever tools your platform supports. Then you just access TPB from a the closest Starbucks, or through a proxy, get the .torrent file you wish to download (remeber to check if the license permits sharing of the work, you wouldn't want to comitt a crime), and put it in the BTSync for the watch folder. Then when the download finishes, BTSync at home will download the encrypted version, when it finishes you unplug the computer, start a second BTsync, and give it the read-only or read-write secret (I would give it the read-only secret). If you do this right, and the great leaders hunchmen come to inspect your comptuer because of suspicious bittorrent traffic, you can show them your computer with an encrypted share that you are unable to open, plausible deniability (would work as a defence against a penal crime, but you would possible be screwed in a civil suit, at least in Norway, my knowledge on North Korean law is a bit rusty). And be sure to remove the torrent files from the watch share after the torrent client is sure to have checked it (some monitors the folder and adds it immediatly, some check at specified intervals, if it checks at specified intervals, make it check every five minutes or something). You obviously have to hide the read-only secret somehow, and even if they catch you with it, that wouldn't be a proof you created it, or intended to download it (the sender could have provided you the read-only secret after you unknowingly downloaded it). Also make sure you pay for the VPS with a prepaid VISA, and set it up using the wifi of the local StarBucks. I planned to add more possibilities but I feel my elaborate explanation is more than sufficient.

Does it support nested shares? It appears I am able to create a read-write share inside my read-write shares (haven't tested if it supports having a read-only share inside a read-write one). I am assuming it has to recreate all the torrents with the new secret, so it is not as usefull as it could have been, but still a nice feature. I feel we should have a Know Issue thread, where all the current issues are updated and listed in the top post.

Version 1.2.82 Starting two users on the same user where one is unconfigured, and one uses a config file running on the same WebUI port causes the two processes to compete to serve the webpage. What I found were that the website would update, and then prompt me for the password, it would then either want the password in the config file, or the password I setup through the WebUI. It should either warn on startup that there is another conflicting process using the port, or exit with an error if it discovers conflict. Took me a little while to debug.

Are these instances running on the same user or using the same folders? When I ran two BTSync instances as root on my FreeBSD server I had strange issues (the webUI would ask for one password, then the other randomly). I can't remember if both were able to download shares.

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.

Does this indicate that every file is its own torrent? If that is the case, then nested shares, and shares refering files elsewhere would be just a simple matter of programming. If each file is its own torrent, then it should be extremly easy to implement nested-shares and shares refering to other files. It would only require tiny changes, and the ability to retrive the secrets for each file and folder inside a share.

Is the location you are syncing to full? Is the files damaged in any way? And did the files change after you started syncing?

In the sync.log I was able to find a bunch of entries like this: [20131228 07:56:55.738] Extension: ipv4:[XX] for '/media/lolcat/btsync/Messy/SOL/Salgsbilda + div/IMG_2781.JPG'If these are the files transfered or some error message is a bit unclear to me. If they are actual requests, then you can see what was downloaded.

With nested shares this seems like a fairly obtainable goal. Simply setup a mediacenter, setup a sync folder, and attach all your media shares to it. Make the mediacenter stream to your television, or connect through HDMI/whatever.

I seem to have found the best way to implement it. Make every folder an individual share. That would enable the ability to attach shares to other shares and allow access to one folder without loosing all the bandwith from the cloud. A user that gets the key to a parent folder doesn't have to see or interact with the shares bellow it, the program could handle it seemlessly. But when someone wants to share a sub-folder they should be able to extract the secret for that share and then send it along. For huge libraries of files this would be extremly usefull. I could myself maintain one huge share (everything on my NAS), ensure there is several nodes seeding using the encrypted read-only secret, and still be able to share everything without having to reupload anything. This would give me my own personal cloud. For management attaching one share to another would be extremly simple. I could setup a share for my grandmother, and then attach shares for whatever she needs (and still have all the seeding that my main parent share would have). I guess there would be some issues with read-only, read-write and encrypted read-only shares, but I imagine that could be cleverly solved somehow. I could then give everyone that is willing to give me storage just one encrypted read-only secret, and then attach the shares I want them to store and seed. It would also enable me to setup nodes that need little or no maintenance, I just give them one encrypted read-only secret and attach and detatch shares as I go along. I feel this would be the optimal way to do this, implementing the features can't be that complicated, all you need is some metadata for each kind of share. When someone downloads a share, it also downloads the shares for all the subfolders, and report that to the tracker. So the tracker would see each folder as a separate share, but the user would just see and interact with one, until the person needs to share a folder within the share they see, then they should be able to obtain the existing secret(s) and send those. For a buisness application this also seems like a very usefull feature for enabling sharing between different people and groups, while maintaing centralized mirrors. Attach the encrypted read-only keys to the share the central server has, and it will maintain an encrypted copy safley stored and backed up.

As a workaround I would suggest adding one of the peers IP and port manually, have you tried that?

What OS are you using? Is there any firewall on your computer? Have you tried it with a different internet connection?

If BTSync was open I imagine the uses for distributing open-source software through it to be amazing. Imagine the port tree in FreeBSD or the repositories that aptitutde uses. If you could create them as a BTSync share, and add web-seeds then you would make every single user able to cache the content, in both FreeBSD and debian based distros the programs you download stays on your computer for some time, if you used the API in addition to shares you could save the bandwith from downloading a file twice to your computer, it would decentralize the distribution (if the repository is down, you can still download from other users), and save bandwith on the LAN. Ofcourse bigger companies can acheive this by using a caching-proxy (like apt-cacher), but with laptops and devices moving in and out of the network this would be impractical. The distro could manage the main share, and then enable the maintainers of software to maintain their sub-share. I am starting to think the best way to organize large shares would be to make each folder its own share (this does not have to be visible for the average user). If you could have an advanced client, or third-party software building around BTSync you could then have the ability to append, and remove sub-shares. This would be extremly usefull for sharing large amounts of data like open-source repositories. If a new piece of software with their own maintainers arrives, you simply make a folder, and give them the read-write key, or append their existing share to yours. If each folder contained their own web-seed property (so the publishers could just publish it to ftp/web if that suits them better) and was its own independent share you could sync a subset (if your entire organization uses Ubuntu 12.04 it makes no sense to sync all the other repositories). You would also need the ability to only download the files you need (for the normal user who just wants to instal firefox and updates), but they could still seed the packages they downloaded from their own caches. Depending on the network topology this could save bandwith on the internal networks as well as internet bandwith. It is more efficient to pull a file from the workstation next to you, rather than getting it from the internet, especially if bandwith is limited to the internet, and to the central parts of the network. Imagine the big corporations like Akamai and such that is doing content distribution, if BTSync was open-source, and easily adaptable, you could build any sort of content delivery that is boosted by the users bandwith, as well as the datacenters. The way I see it the biggest hinderance is restricted features (you need an API key, and you can't really distribute a simple GUI or software because it would have to obfscurify the API-key), and lack of open source. If anyone could develop features, and use the full codebase (rather than a limited client with a kill-switch) then we could truly change the way the internet works. Another usefull feature would be to have encrypted peers that can decide how much they want to download, that way I could host 100GB of the Ubuntu repostitory, and my client would download what lacks peers and help improve the swarm. The peer with the encrypted files will have no need for the whole thing the files will be invisible anyways. This would also be usefull for huge projects like Big Buck Bunny where you would want to share huge amounts of data that very few people would be able to/willing to host, but where a large amount of people would be willing to dedicate some storage for.

This seems so incredibly silly. If I were to bundle BTSync in some malicious software, wouldn't I just wrap the network connections in such a way that the connections goes to another server than yours? Or simply block the API check and the tracker alltogether? I realize you are probably worried about liability for running a torrent tracker that through the API could probably be abused for a bunch of malicious uses (hosting illegal content encrypted, stealing documents, pictures or other files, piracy). If you combine that with a botnet you get potentially scary issues for whomever is hosting the tracker. As I see it all of this is a result of keeping the software centralized. The central tracker is causing all these problems, either eliminating it through better DHT and local peer exchange, or allowing everyone to host their own trackers could solve it. It seems pointless to limit the ability to use features that are ready for the users. The idea that Bittorent inc holds a killswitch for my sync is also questionable.