Axxel

Pretty sure custom keys are broken on 2.0, I see the same thing on Android. My thread here: http://forum.bittorrent.com/topic/34447-sync-20-incompatible-with-custom-secrets/

After several tests, I've come to the conclusion that Sync 2.0 doesn't understand custom secrets for 1.4 folders. I see this problem on Android: http://forum.bittorrent.com/topic/34336-android-14-interop-broken/ And another user reports a similar read-only state on Windows: http://forum.bittorrent.com/topic/34446-20-cannot-change-14-secret-cannot-add-14-folder/ I've tried custom secrets at a variety of lengths with proper key prefixes ('A') and the resulting connection is always read-only. The same key truncated to 33 chars works read/write. Since custom keys were a feature of pre-2.0 versions (http://forum.bittorrent.com/topic/16410-bittorrent-sync-faq/, many references in the forum) I assume this is a 2.0 bug. Can someone from BitTorrent confirm if this is unintentional or something new in 2.0?

No one?

I asked a similar question in a different thread... Since 1.4 folders are limited in various ways, is this expected to be a permanent state of affairs? Or will 2.0 folders eventually not require GUI configuration?

Unless you have more than 10 backup folders, in which case you'd need a separate subscription identity for the backup machine, correct? So one license would be insufficient? Will this limitation be addressed before the Pro trial runs out?

I updated an Android device to 2.0 as a canary, and 1.4 interop appears to be broken. - My existing shares were updated, but all shares were converted to read-only. Folder icons have the "1.4" label and the read-only icon. Read only status was confirmed in the details page. These 1.4 shares do have longer-than-default key lengths, but do start with the read/write "A" prefix and have never been a problem before. - Removing the read-only and attempting to re-add (with a read-write key scanned by QR code off a 1.4 device) results in a new, apparently 2.0 read/write share (identified by icon) that never finds any peers. There does not appear to be any way to have it detect or force a 1.4 share for compatibility even with existing keys. Neither of these results seem to match any claims I've seen about 2.0's backwards compatibility.

I have a server running sync all the time to serve as an intermediary between intermittently connected laptops and Android devices. The server has a larger number of shared folders (various permissions) because it serves as a hub for many different devices. I understand that 1.4-style key-based folder are still supported in the 2.0 release, but its not clear to me that with 2.0 a headless file-based configuration isn't on its way to deprecation. Note that I run sync with a config file on OS X (unsupported, I understand), but running 2.0 on a Linux box appears to have the same incomplete support. Looking at the sample config file dumped from the Linux 2.0 release I see no changes to reflect the new identity concept and the "shared_folders" docs still reference secrets. The developer API docs make it clear that secrets are deprecated and the UI has no affordance to create them. It also appears that at least one forum poster (http://forum.bittorrent.com/topic/34307-how-do-we-create-encrypted-read-only-peers-in-20/) has discovered that ERO peers need to maintain a separate identity from the clients, and I wonder how this applies to the general concept of a self-hosted "cloud" server. My questions: - Will ERO make a return to Sync 2.0? Is it possible to have ERO folders in the new identity-driven world? If so, why is it not in the release? - Will it remain possible to configure a purely headless server from the commandline, preferably via config file? - How do self-hosted servers like you mention in your blog (http://blog.bittorrent.com/2013/08/06/how-to-create-a-secure-cloud-with-bittorrent-sync-amazon-ec2/) fit with the Sync 2.0 model? Will they require their own "Identity" and thus increase subscription costs? - How long will 1.4 folders be supported in 2.0 as a backwards compatibility measure? - In the interim is there a limit on the number of 1.4 folders that can be supported by config file in the 2.0 free tier? I'm avoiding upgrading to 2.0 out of fear that in 30 days I'll lose accees to what I have while you are still updating docs. To be clear, I'm not opposed to payment/subscribing, but its not clear my use case will even be supported, or at what price.