gorpo

It's great that you're engaging your users to improve the product. I'm interested in using btsync, which is why I'm giving my feedback. Please don't misunderstand it as anything other than constitutive criticism. The api key will be used, as you said, to verify that the software is used for good What's worrying me is that "good" is subjective: what's good for the company may not be the same as for the user. I agree with having an api key for accessing bittorrent's servers and services (e.g. your central tracker), but I don't think it's your position to dictate how the software is used otherwise. As a developer interested in using the btsync API this makes me wary of investing my time. I understand that you seem to be reasonable, but I'd rather not depend on that if at all possible.

Thanks for the reply, but I'm still confused. What's the API policy? I didn't see it in the documentation. I'm using this url: http://www.bittorrent.com/sync/developers/api I'm also unclear on why Bittorrent Inc. is enforcing the policy for clients accessing my servers. I agree that API keys are useful, but I argue that if it's my server, then the assigning and blocking of keys should be under my control. Mainly I think the API key policy as it's currently implemented goes against the original idea of btsync being decentralized and independent of third parties.

I've been reading on the new API and was a bit confused by the need for an API key. Normally API keys are used as a gatekeeper to enforce a contract and/or to block abusive clients without affecting the service to other clients. In this case however, I'm a bit confused since the servers are being run either by the users themselves or third parties, so why would Bittorrent Inc. act as a gatekeeper for that access? I can understand this being used for accessing a server provided by Bittorrent Inc., but for my local server it strikes me as a bit odd that an external party is granting or refusing a client access to my system. I feel that if there would be a gatekeeper to my servers at all, it should be fully under my control. Please understand I'm not criticising. This is genuine curiosity: Is there a technical reason for this policy? Is it a temporary solution during development, or is it intended for the long-term?

I've been testing with the new new Android app (I'm using the version published in the Play Store yesterday) and wanted to give some feedback. There are a couple of confusing elements in the UI: 1. What's the difference between the "Sync" tab and the "Backup" tab? 2. When setting up a sync folder, there's an option to "Automatic sync". I guess it means that remote files are downloaded automatically, but the option isn't really self-explanatory. The ability to send files is great, but it's a bit difficult to use - you have to open the app on both sender and receiver and browse for the specific file. It'd be great if you could make at least the sender's life easier by making BtSync a share target, so it appears in the share menu when you want to share data from any app (like Dropbox, or Gmail do). On that note, it'd also be nice if you could share a file directly to one of your existing shared folders (say, to send the file to your PC). Otherwise it's looking great, and better yet - working great!

@kfchoong when adding a folder you can type in the hash manually under the "Scan QR code" button.

I was on 1.1.12, sorry for the distraction. It's working fine now.

I've been testing with the new Android app, and whenever I try to sync two different Android devices (phone and tablet) to a single share in my PC (Debian Linux), btsync crashes on the PC. This happens whether I sync a normal folder, or use the camera backup.

I've been using BtSync for a while now, and I'm quite happy with it. However, recently my ISP has decided to start migrating everybody to IPv6, and I can't access my (Linux) server's WebUI from an external network anymore. From the internal network it's working if I use the server's private IPv4 address. I'm able to access that server's SSHd over IPv6 though, so I think my setup is correct. It seems to me that the WebUI code doesn't support IPv6. Can anyone confirm this? Are there plans for support (hopefully in the short term)?

As an app developer, I have somewhat simple needs for an API. Basically, the API should be enough to implement a Dropbox-like app for accessing BTSync shares: Search for a share by key List contents of share (without synching the entire share locally) Upload/Download a specific file (again without a full sync) Sync a share (probably on demand, to avoid killing the device's battery and bandwidth) In my case the motivation isn't so much to build a Dropbox app replacement, but to implement sync functionality so the users can have their data replicated on all of their devices. In an ideal world this would be possible through a library which could be added to any app. A not-so-ideal possibility would be some sort of web-API which would essentially mean the app would be talking to a remote btsync client. This would still allow for all of the above functionality, but it would turn the app into a power-user thing: they would have to know how to setup and access their remote machine from anywhere.