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.