benguild

If the secret length can't be changed, I think that having a "password" (of a variable length) for the secret would be great. Essentially all peers have to verify this password with each other directly for a given secret in order to actually communicate over a given secret. I realize that finding a way to verify passwords peer-to-peer that can't be easily spoofed/monitored/cracked might be a challenge given that there's no central authority, but a feature like this would definitely ease the wary minds of those concerned about the extreme chances of probability. This way, it's ideal since even if someone finds your secret they're most likely not going to find a matching passcode. ... Even BETTER would be a way to store, generate securely (based on the original passcode) a secure password "key" that is unique for a particular node... so that the original passcode is never actually stored or given to that node in plain text.

Cool

So will OSes that don't support these still "stick" on syncing them, or can we remove these exclusions on Mac OS X from the .SyncIgnore now?

I've been playing around with this quite a bit. I noticed in 1.3.93 that if I add files to the .SyncIgnore on a source machine, the read-only encrypted nodes seem to still retain those files and seed them between each other. Like, if I boot a new machine up and add the read-only encrypted key to it, it'll download all of the "ignored" files from the other ROE nodes but not the original source machine. I tried rebooting all machines (including the source) and it still wouldn't remove that content from the the ROE nodes or move it to .SyncArchive like I expected. I had to remove it simultaneously from all of the ROE nodes manually or it would start resyncing.

Nevermind~

That's true, there might be better options available. Still, the decentralized nature of BTSync is interesting.

I agree that this would be cool, but I also feel like it could be abused to nuke the device that hasn't been stolen. Setting PINs + passwords on both GUIs would be essential.

For shares that I share with other people, I like having notifications when someone starts syncing. However, for me between my devices... repeated notifications are annoying/distracting. I only want to be notified the first time it starts syncing or when something abnormal occurs. (like if a device goes offline) Being able to tweak this would be great

Unlike Dropbox where everyone just kind of dumps stuff in a folder (although I guess you can do that) ... how much are you guys really pushing back and forth? Anyone doing more than 100GB? I definitely like that you aren't confined to a specific folder, but it's also more intensive to manage different folders' configurations....

>33 characters for more security

This is the one feature blocking me right now from setting this up on one of my machines. As more and more users use BTSync, guessing keys will get easier and easier given that there's only the same alphanumeric keyspace. With today's hashing hardware for mining Bitcoins, mining other peoples' data from BTSync will be a passtime amongst a select few. No matter the odds, this is a feature that's definitely important. Right now it doesn't matter while the service is in beta, but this is incredibly essential in the longterm. Getting a read only peer key of either 33 characters (at least), or preferably of a variable partial length of the original would be amazing.

It'd be nice if you could locally generate very long, very secure keys locally and then truncate a % of them into read-only encrypted node keys!

Got it... so don't open any large files on a handheld? The ENC peers shouldn't be doing any encryption/decryption, no? (since they shouldn't have the actual keys)

Got it, so basically if there's an encrypted "peer only" client then the BitTorrent Sync iPhone/Android Apps will have to decrypt it on its own when receiving content from it and it'll eat battery? But an Intel desktop/laptop machine will be fine with it since they support hardware encryption? OR, do you mean that the encrypted "peer only" client will be under heavy CPU load because it's receiving/serving encrypted data?

Question for you all: Love the product, but what I'm wondering is if it's possible to configure the software to only *serve* the content from a destination (ie. a colocated server) but not actually decrypt it? For example, if hardware is stolen, compromised, or recycled... it'd be nice to serve it only from a destination that will never need to access the actual data. It would also reduce distribution of private keys. Please let me know, thanks! _____________________________________________ edit: I was poking through the documentation and I saw this: ... This sounds like exactly what I'm wondering about. Is this pretty foolproof, or is it possible to run into issues where these peers might become unsynced with a future release if just left there indefinitely? Or would they offer an indefinite backup?