I just found this thread and would like to add my vote too! I see that it's already being planned which is great news! I want to add that I don't think this should be a very impractical thing to add that some early commenters have said. BTSync already does encryption. The benefit of building it in is to make it hassle-free, which is a critical quality to bring encryption to the masses. While using third party solutions work (well... not quite as well now that TC went bust), they take effort and expertise that the average person doesn't have. what I envision should be fairly straight forward in terms of user experience: have two secret keys, Key A is for encryption, Key B is for linking each client for file syncing. All clients encrypt all files being synced using Key A before doing anything else, that way only Key A-encrypted data is being synced. This avoids the versioning problem since the same data is being compared across all clients. Key B is then used to link each client together - this is the same as the current secret key that facilitates syncing. Key B is mandatory (it's needed to establish a link), but Key A is optional. If Key A is provided the client transparently decrypts the data on disk so the user can access it. If Key A is not provided, it can't decrypt the data on disk so the user can't access it. This will effectively enable untrusted remote machines that can sync just fine but protects the data even while it's running (unlike FDE which is useless for an always-on server). Friends/family can share space or one can setup a low-power always-on "server" (or several) at untrusted locations in order to avoid the need to leave actual home computers on all the time. Heck, you can even be fancy and protect Key A (once it's been entered into a client) using the local user account so that even physical possession of a Key A-enabled machine won't do any good if they can't break into the user account.