ckesselmeier

Events - as mentioned by some posters before me - would be a great feature. Right now I'm setting up a server to convert some screencasts from wmv to mp4 using ffmpeg when I'm on the go (doing this on a MBA sucks the battery dry before you can close the lid) I'm missing events for - file added - file removed - file updating - file updated The same maybe useful for folders. The events should just execute a shellscript and hand over the filename. That would make life a lot easier

I'd like to test the iOS client, too, iPhone5, iPhone4 and iPad 3 here, 5GHz WiFi, btsync running on OSX, FreeBSD, assorted Windows-Systems

@linux only As yottabit and I write there is no difference between a username:password and a secret from the "something you know" perspective. Except from username:password alone being shorter and thus less secure. The issuer can't be sure that you don't give it away, same goes for giving away the secret, so access is transitive. Nothing can be done to improve the perceived security here, I'm afraid. However username:password or any way of identification of the nodes without a doubt (signatures) would mean accountability for changes to data. Auditors like this.

@linux only I see that authenticating a user and by that connecting changes to an identity is desirable in a corporate environment. But I don't see an effective way of implementation for a non-hierarchical network of btsync-nodes without introducing an external authority eg. a CA or a distributed database per share in which an existing node could vouch for the identity of a newly added node. If it comes to authorization (is the user allowed to r/o r/w access the share?) I'm not sure which additional layer of security a user / password combination would give, except from it being a longer secret effectively.

1.0.128 is working flawlessly for me in a jail on FreeBSD 9.0 / Atom-D510 for two days now. NAT on a fixed port, synchronizing a 1GB and a 36 GB share on ZFS with two Macs running 10.8.3.