danhunsaker

The RO key is used when you don't want changes to sync back to the source. For example, if you're backing up data, you don't want the backup to change the data on the device you're backing up. Perhaps a better example, if you want to distribute files to other people, you may not want them to be able to make changes to those files, and then have those changes sync to everyone else in the swarm. So you'd give them RO keys, to prevent their changes from being synced back to the rest of the swarm. You *might* be able to use RO keys to sync a given folder in two directions, but that increases the number of keys used, and conflicts become a lot harder to resolve. Not to mention the increased traffic from "Oh, new file! Sync it to the other guy!" going *both* directions, because at that point each sync has no idea who actually created the file and who already has it. RW keys are immensely more efficient for these purposes. Encryption keys are even more complicated. They work the same as RO keys, except the data stays encrypted on disk. That means you can *only* access that data over the swarm that synced it to the disk in the first place. It also, however, ensures the data can't be accessed by untrusted parties with access to the storage system, meaning it's a secure backup even when used on an insecure storage. Not entirely sure if encryption keys are supported outside the API, yet, though, so you may not need to consider them for a while. At any rate, I wouldn't recommend the two-RO approach to two-way syncing. It would end up causing more problems than it would solve, most of them involving inefficiency of the file transfer, but with a healthy side of conflicting versions never resolving themselves. Create sync shares on the machine with the master copy, use RW keys on machines where you want changes to sync back to the master, RO keys on machines where you don't want changes synced back to anyone, and encryption keys where you don't want changes synced back and also don't want your data to be readable outside the swarm.

Let's say you have your folders set up like this: My Pictures (Source [RW]) |-- A Folder |-- Dan's Cell (Backup [RO]) |-- Another Folder |-- Dan's Tablet (2-way [RW]) My Pictures is a share created on your computer, so by nature has the read-write key. Dan's Cell was created on a cell phone, and is intended only to back up photos taken on the phone, so this computer only has the read-only key. Dan's Tablet, meanwhile, was created on the tablet, but is meant to be a 2-way sync, so photos can be shared from the tablet to this computer, but also from this computer to the tablet. Here's where the trouble comes in. BTSync has no way of knowing, when you create a new share, which key you're going to use on other computers/devices. So it has to assume the share will be used in the most permissive mode - that is, read-write. If it were to sync in a file from another device that belongs in the Dan's Cell folder, that new file couldn't ever be synced to the rest of the peers for that share. Similarly, changes to existing files couldn't be synced either. Without a way to determine which version of a file to keep, BTSync would end up not knowing how to proceed. There are a number of potential ways around this, but each is a hack. The only real solution is to prohibit creating shares on parent folders of read-only shares. Unless we could somehow create a share that doesn't generate a read-write key, which will never allow syncing files in from other peers. A "seed-only" share, as it were. That would resolve any issues. Until then, though, this is what we have.

@lexoyo - That's one option. However, it's mostly so that you have a BTSync API to access in the first place. BTSync uses HTTP for its API, so it has to be running someplace your PHP script can access it via HTTP(S) - the simplest option is the same server PHP is running on, though you can of course set things up differently if that suits your use case.

I don't see any mention of this in the documentation; might be a good idea to add it. Just in case that isn't the default policy for questions like these.