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.