Heavensrevenge

It is a shame they haven't prioritized it, I'll be hopeful but won't hold my breath. I just hope I reminded these people instead of think we'll forget about it and just ignore their lack of documentation with our ignorance be their bliss.

I really do apologize for that and I hope I'm not banned but this really needs to be said again. The dev team really needs to stop being assholes and ignoring the need to release the specifics about this protocol and documentation regarding the protocol for this and now, eventually, BT-chat to show it is solid and really is a wonder of engineering. Yes your solutions work pretty darn good, but you are preventing your own growth by withholding such critical documentation and specifics about how this operates and if we can actually trust anything to these protocols. Until the documentation is published I can not vouch for BT-Sync anymore, you've waited too long for no reason, and IF your solution really is secure, well then prove it, and you'll have nothing more to prove than by showing your technical capability is as much as it seems to be. Being closed source doesn't help, without it you will never see it grow regardless of how well it works, sort of like driving down the road in a 1/2 built dune-buggy. Sure it works, but it feels HORRIBLE and is horrible to drive. So if your keeping it closed to keep everyone out of the secret of how bad your implementation is then fine, that's reasonable, but it still wont gain anyone's confidence to rely on you for real tasks. Until anything is published I will have to actively warn but also discourage the use of this and BT-Chat until you actually pull your act together and do the right thing. I will be hoping for it, and I will be eagerly awaiting the good news IF it ever comes. Sincerely, Eric

BT-Sync NEVER updates for me automatically... I always need to download the new version manually. Why? Which option may be preventing the auto-update feature when I have auto-updating enabled? While trying to update to 1.1.69, or 1.1.70.

Yea I do prefer one string too, and the reason on why I sugested that SHA-3 hash function is because it's authors designed a special MAC mode for it to be used specifically for encrypted authentication. But I'm thinking that the string itself may not be good enough, hard code some magic value into the client's internal data to get a resultant broadcast or something, so we never truly know what the string is AND it'll be like some massive bitstream damn near impossible to crack or guess even though brute-force methods. https://blogs.rsa.com/keccak-effect/ has a bit of info, but they made a presentation and a paper about using Keccak for encrypted authentication.

This is what I mean by constant usage, this is even after I just removed Sync and re-installed it fresh, and I have ZERO shared folders, and I disabled all features, even auto-updates. The top graph is CPU usage, always over 0.05% and the bottom blue graph is network usage without ANY shares or secret configured at all. And Sync will ALWAYS stay above these values and constantly use resources. Ahem, even though I'm running Sync on Win8 and not a Mac, at least you can see what I mean.

Not meaning to revive a dead thread but if security seems paramount, Sync should just use the new SHA-3 Checksums of any length anyone wants. The Algorithm is named Keccak and is the new SHA checksum blessed by the NIST So yea you should completely rock Keccak for checkcums or secret creation in some future build to really be ahead of the curve in terms of security.

For me, BTSync uses 0.05% CPU usage nonstop AND it uses 2.5KB of network bandwidth every second, which is wasteful and it accumulates since I really want to run it nonstop in the background without it using up resources needlessly... Please do something about the constant 2.5Kbps usage.

Also regarding those secrets, of course they aren't a .torrent file per-se, more of a concept mapping to what a container .torrent file could be like & encoded via that string since an encoding + reversible compression is possible if the description can be small enough to encode inside of that secret. Similar to like a small and tidy magnet link URL which could be coded into the secret, but it's just a guess for how the secret is actually implemented.

Thank you for the welcome I have looked around and the Sync team mention this "However implementing rsync like diff in distributed environment without dedicated server, is kind of complex task." so the sync of a diff which the client can manage/apply to the pre-transferred file could work within their current infrastructure as long as the diff creation/application process can be done without too much problem. But if versioning becomes a future feature, that makes diffing the versions a piece of cake as I mentioned it. They also mention the "files whose size does not change" aspect, which is almost exclusively VM images and database files with a fixed size that never change which may be practical for corporate environments but I hope this product is for end-users/consumers. So diffing shouldn't be that bad of an idea for files smaller than 100MB either since I imagine thats the majority of us using it. I just hope the complexity tradeoff can be worth their time to implement diffs since it's always a time & space win. Honestly though, each end-user client running this program IS a server, each instance of us running it is. BTSync is even closer to being a true BT server/tracker since each of us knows each client connected to our secret which we can see in the GUI on the Devices tab. Personally though, I don't think rsync is good enough in a distributed setting like this since its too dependant on only one destination to sync to; completely unscalable in torrent terms. So having our clients handling diff application per secret/file should be workable for this.

Hello, I'm new here so hello everyone And just to start off before I get into my actual issue is to say say I LOVE BTSync, I use it at home now and it's a VERY good step in the right direction! And I'm not intending to flame the project but raise a technical concern as I'm understand it at this time. I'll start off saying this is related to delta synchronization because this is where BTSync just... dies and can't do. They can't do it I believe quite fundamentally in it's current implementation and the whole internal structure/architecture needs to be re-thought about and re-implemented if im not completely incorrect in my thinking here about how BTSync currently works and behaves. This is sad because I wish it could have started off as a perfect sync option instead of have such a flaw like this, this means we need a v2 or a new product to get around this, hopefully a v2 is all that's needed but I don't have such a say. All of what I'm saying may be off and if so... I apologise lol but I believe I need to at least mention this. As I understand it the "secret" is basically like a .torrent repository file which is a non-static repository torrent that is specific to this product/project that holds static sub-torrents inside of it as individual torrents themselves. This is what allows the files to be sent and received so perfectly and in a distributed manner. THIS I LOVE; to me the file distribution mechanism as torrents are themselves perfect. The problem we're all facing is when a file in the folder is changed, it's like a completely new .torrent file is created for the new file and is 100% separate from the original file, and this is what causes the re-transfer of the entire file to the destination sync points. Unless the BitTorrent team has some way to diff/delta a .torrent file then this point exactly is why the current implementation of modifying a changed file is flawed/bad/unacceptable and just can't do delta transfers. In theory since all torrents are chunked into blocks make it seem this delta is simple and trivial. But that .torrent file is just a hash of all blocks and has tracker info, even I think its almost impossible to diff from a .torrent files contents since their all 1 way checksums to verify the file contents. What I'm proposing is for the team to implement diff/delta functionality into the client similar to this: Use an open source implementation of a GOOD diff program like xdelta3 (http://xdelta.org/ or https://code.google.com/p/xdelta/) since it is VERY fast and open source and doen't require much memory at all, or make your own if you really want to... And WHEN A FILE IS ADDED OR CHANGED, delta it right away so both the source AND the final file can be compared ad-hoc or make a way where both files can co-exist upon update to get the diff and not require the disk space of source + destination file, and just do the .diff in-memory on import or do it however you want really. After that problem is solved in however way they think they can get source + destination files compared to create the delta. Now instead of forcing clients to actually re-sync the ENTIRE file as BTSync does now from the fundamental reason of using static .torrent files for each file, just sync the diff file as its own static .torrent file. So that way on the endpoints all the clients need to do is use the old file and the diff to create the final updated/modified file. Since the client/protocol already uses or detects the most recent file, they just care about the most recent diff + the full file, so even after a file has been initially sync'ed, it can just pull in the delta files and apply it and have the updated file ready to go after an arbitrary amount of time in between the last sync done and most recent file available. So this is how I propose they should go about the delta syncing of files especially LARGE files that the torrent protocol is truly the best available to transfer such large files. If they want to be the actual solution to this problem then awesome, this should work, if they don't then a new replacement WILL come from some other place and replace BTSync as the superior alternative anyway. I honestly hope the official team at BitTorrent Labs will just do this for a v2 instead of have some random 3-rd party make it even though I don't care who makes it so long as it's open source/free of charge. It is quite a technical problem in multiple ways to merge BitTorrent + Delta's working in hormony if how I think sync works now, and will merit a v2 or some replacement to do exactly this type of functionality. Well thats it for me right now, I hope i didn't seem to offensive or was completely technically wrong. Thanks for reading and I hope the official team considers this or a similar solution for delta syncing as it IS VERY IMPORTANT, important enough for people to stop using BTSync when an alternative that does do it crops up.