GreatMarko

At a guess I'd say that it's likely to be a firewall issue at one end. Either your home firewall is preventing SyncApp from receiving incoming connections/traffic, or, more likely, your office firewall is not permitting SyncApp to make outgoing connections/send data. Have you perhaps tried experimenting with diferent ports for SyncApp on each machine? (Preferences -> Network -> Listening Port)

SyncApp is currently in a limited "alpha" phase, and is not available for general download at this time Please see the following blog post: http://blog.bittorre...sync-pre-alpha/ ...the above post contains a link to a sign-up form, should you wish to register your interest in becoming a tester. (Note: I understand there is currently a waiting list of at least 6 weeks!)

Not if the length of Secrets was improved - I'd like to see someone try crack a secret of length of let's say 512 characters (including symbols!) - rather than just the current 21 alpha-numeric character secrets! For this to work, the service would rely on a connection to BitTorrent, and your details stored there in a database! I would suggest that this is actually LESS secure than being responsible for your own unique secrets that only you generate and use. The whole point of SyncApp is that it doesn't require a central server (or any connection to the internet for that matter - you can sync directly accross a LAN!) As I said previously, SyncApp needs to be both secure AND user-friendly. I don't think users would like the idea of their secrets being "checked against a master database at BitTorrent" as it were... and beside I still don't see the need for this as long as SyncApp removes the current 21 alpha-numeric limit on secrets, to allow you to generate/manually enter secrets of any length, and include symbols as well. Seriously, it would take decades for the best super computers in the world to "guess" an extremely long secret!

In your "Shared Folders" tab, right-click on a folder and select "Show folder preferences". In the resulting dialog, untick the "Use relay server when required" option (and probably also "Search BitTorrent DHT network" - although, this isn't usually ticked by default anyway) This should, I believe, prevent SyncApp from connecting to BitTorrent servers in any way (of course, you'll have to repeat the above for each of your "Shared Folders")

That seems a bit over the top IMO - If you think back to the very recent days of Windows Live Mesh, when you consider all you needed was someone's email address and their Live password and you'd then have full access to all their Mesh'd files, their SkyDrive, and Remote Access to their sync'd devices - no-one questioned the poor security that just a simple password provided for Mesh! I agree that the "secrets" system for SyncApp does have some big drawbacks at present, however, I believe that if they removed the current fixed-length size limit on secrets, allowing users to enter/generate a key of much greater/any length, as well as permit symbols along with numbers and letters - this would make "secrets" extremely secure indeed - it would take the fastest super-computers centurys to crack a very long "secrets" then! So whilst of course users want an extremely secure product that no unauthorized persons can access their data with, they also want simplicity and ease-of-use! - I think a "two-step" verification process requiring you to respond to a code via an SMS or phone call etc whenever you want to setup a new sync will put a lot of users (myself included!) off! ...not to mention people would then have to have some form of SyncApp "account", with their phone number associated with it! (and this is one of the things that currently sets SyncApp apart from competition - you don't need an "account", you don't have to associate your email address with SyncApp in the same way you do if you want to use say AeroFS and Cubby, etc) I believe that by simply allowing variable length "Secrets", and allowing symbols in them also, this will allow users to achieve extremely secure syncs, whilst not making SyncApp any more complicated to use!

67.215.229.106 would appear to be a server owned/operated by BitTorrent- so my previous comment about it likely being SyncApp trying to establish communication with your other devices (that it couldn't otherwise make a direct LAN connection to), would seem to hold true. See the additional information for: http://whois.domaint.../67.215.229.106 ...one of the contacts there is listed as a "Jason Whitlark" - jwhitlark@bittorrent.com

I would be more concerned if you were seeing connections from an actual physical unknown IP address/port. For information on 0.0.0.0:0 please see: http://en.wikipedia....i/Default_route I'm no expert, but I would suspect you are seeing "0.0.0.0:0" because SyncApp is unable to connect directly (i.e. across your LAN) to one or more of your other syn'dc devices, and therefore is attempting to "tunnel" either through your firewall, router, gateway, or via BitTorrent's servers (which might explain your American IP connection anomaly) in order to establish a connection to your other devices. I therefore don't believe that in this particular instance you are being "hacked" or that your data is being stolen by a 3rd party. That said, I know the SyncApp team are aware of users concerns here on the forum with the current length of "secrets" and how likely they would to "guess"/crack, etc.. and I'm sure they are looking at ways all the time of improving security of SyncApp, which - let's not forget - is still in an early "alpha" phase after all.

In my "sync-within-a-sync" testing, if you setup a sync on a parent folder, and another different sync on a sub-folder - this will cause issues! The way around it would be to NOT setup a sync on your parent folder ("TV Shows") at all, but to setup separate syncs for each individual sub-folder ("Series") within. That way you can selectively choose which "Series" folders sync to which devices - i.e. some devices could sync all of them (essentially the entire content of your "TV Shows" folder), others just a selection of them. *** DISCLAIMER *** I should perhaps also add that my advice here is given on the assumption that you own the digital copies of these "TV Shows" you wish to share with "friends" - my advice is in no way meant to encourage or facilitate the illegal sharing of any content.

...another couple of auto-update queries that occur to me having thought about it some more - (and assuming that even if the auto-update feature isn't currently working, it will be implemented at some stage) Firstly, if you've got the "Check for updates automatically" option selected, how often will SyncApp check for updates? Will it be on a recurring interval in the background whilst SyncApp is running (i.e. every X days)? ...or will it only auto-check for updates upon launch of the application? (and therefore if you leave SyncApp running for days, it won't check for updates until you restart the app!?) Secondly, if you do have "Check for updates automatically" selected - will this just alert you to the fact that there is an update available, or will it/can it actually download, install, and restart SyncApp for you? - this second option would be preferable if you have SyncApp running unattended/on remote machines i.e. SyncApp could keep itself updated without any user intervention? (also useful if all your devices must run the same version of SyncApp in order to sync properly?) Anyway, I'm sure Kos, or one of the other SyncApp team here could explain a little more how the update system for SyncApp is envisaged to work?

From what I can determine - the amount of memory used by SyncApp seems directly related to the number (or perhaps the total size?) of files being monitored. For example, on one of my machines, SyncApp is currently only using 9,484 K, where as on second machine it's using 178,168 K ! The first machine is syncing approx 1.6G of data over 1,223 files The second machine is syncing a total of 75.2G of data over 169,365 files Whilst over 178M of memory usage does seem rather high - on the plus side, at least it remains faily stable (i.e. I can have the machine on and running SyncApp for days on end, and the memory usage of SyncApp stays pretty much the same, and doesn't slowly increase over time!) In addition, I know the SyncApp team have acknowledged that are currently issues when trying to sync more than 100,000 files, so it may be that the high memory usage is also related in some way to that. A good point about the auto-update though! - Whilst there is a "Check Now" button in SyncApp 1.0.75, when I click it, it doesn't seem to do anything and gives me no indication that there is/isn't an update available - so it may be that this hasn't been implemented yet? (I have previously reported this non-action when the "Check Now" button is clicked as a bug)

My best guess - and I stress it is only a guess - would be that if there is to be another round of invites made available, this would likely be timed to coincide with the next update to SyncApp, which I understand won't now be before April.

Thanks for the update, Kos!

Kos posted last week on 27th Feb, "We plan to release next version in three weeks." See: http://forum.bittorrent.com/topic/8818-syncapp-progress/

It's important to remember, though, that this is primarily a file syncronization utility - NOT a cloud storage solution!

You may be able to recover your lost files if you check the .SyncTrash folder (a hidden folder created by SyncApp) in the folder concerned. My understanding in relation to "file conflicts" is that SyncApp will assume that the most recent version of a file is the one to keep - perhaps it's worth checking that the system time on both of your machines is correct, as this potenitally could be a cause for your files being incorrectly replaced? It is strange that your folder vanished from the Shared Folders list in SyncApp though!

@pols1337 A couple of other things to check/be aware of as well.. it could be that your University network intentionally slows down/limits traffic on certain ports? Also, in relation to Hamachi? Are you a "free" user or a paying user (paid Hamachi users tend to get better speeds, or I at least noticed an increase in performance when I switched from their free to their paid offering!) ...also, are your Hamachi connections to your other devices "Direct Tunnels" (shown as a green dots in Hamachi), or "relayed tunnels" (shown as a blue dots in Hamachi), as this will also likely impact on the speed at which SyncApp can sync your data. In my experiences of Hamachi behind corporate networks, it's only able to make "relayed" connections, rather than direct. Anyway, maybe this information is of use in helping you determine whether your slow sync speeds are due to restrictions imposed on your Uni network, your Hamachi connection types, or a SyncApp issue?

They're working on improving speed - see Kos's post at the top of this thread "Currently we are working on... Improving synchronization speed for LAN" Speed issues aside, I have SyncApp running via Hamachi between two sites.. so it does work! ...strange that it's not for you?

I agree, offline devices should also be shown in the device list with an indication that they are "offline", and the time they were last seen (and sync'd)... there's isn't a central "host" device... do you just mean a way to indicate which device you're currently on? Yes, "Sync Folders" would be less ambiguous than "Shared Folder", which to novice users could imply that their data is being "shared" publicly, rather than privately sync'd. As for the "Cannot open destimation folder" error that's shown when you enter a Secret but no folder, this would be more user-friendly if it showed "Please select a folder to sync", or similar. They're already working on "Improving synchronization speed for LAN" see: You can already pause/resume sync via the tray menu! The "scheduler" idea has been suggested by numerous people now - I'm sure it's on BitTorrent's radar!

See my above comment!

MonoTouch does raise an interesting point! I wonder though if by simply setting SyncApp to use a "standard" port - i.e. Port 80, this would have got around this particular issue of SyncApp raising alarms with corporate IT departments, as it would then just look like standard internet traffic? But what IT Departments need to realise is that P2P itself is NOT inherently illegal - downloading & publicly sharing illegal .torrent files, etc may well be, but the P2P technology itself isn't, and SyncApp has nothing to do with downloading and sharing .torrents! So there are plenty of misconceptions about. For example, on Cubby's forums, when SyncApp was mentioned as an alternative, one user commented "Sorry, I would not allow bit torrent anywhere near my data!" BitTorrent do have a great product here... but I think a lot of education is going to be needed to change some people's perception and understanding of what exactly SyncApp is/does! Anyway, getting back to the original point - maybe if/when sync "scheduling" is introduced to SyncApp, this will be all that is needed to address this issue i.e. if you use your laptop at work during the day time, set up a sync schedule so that SyncApp only syncs data in the evenings when you're back home?

You won't be disappointed, SyncApp is awesome!

Yep, I'm also an ex-Mesh, then ex-Cubby user too, and I agree that even though SyncApp is only in "Alpha" phase right now, it's very impressive and highly efficient already!! I know a lot of disgruntled Cubby users are leaving (or have left) Cubby in their masses, and they're all currently opting for AeroFS (Cubby's site is full of users requesting AeorFS invites!)... but just wait until they see how great SyncApp is! ...it literally blows the competition out of the water!! Anyway, I second the idea of having a global filter to opt-out specific file types from syncing. I suspect this will eventualy come to SyncApp, once they've got all the current sync issues resolved (for example, right now zero length files, or those starting with a "." etc aren't being correctly synced)

Keep up the great work guys!

Ourouk, as Kos's second post indicated, these invites have now all "gone" You can, however, still sign up for when more invites become available at: http://labs.bittorrent.com/experiments/sync.html

Yes, I've asked the same question too! Especially given that the "secret" is always the same length, and only made up of alpha-numeric characters, it would not be beyond the realms of possibility for a computer to "crack" a secret with relative ease. I think "Secrets" need to A ) be much longer, B ) be of "variable length", rather than a fixed-length, and C ) permit symbols as well as alpha-numeric characters (i.e. + - = / \ _ : , etc)