BitTorrent’s Secure Dropbox Alternative Goes Public
torrentfreak.com
torrentfreak.com
One example: I used to use Flickr for photo sharing, but cameras got better, images got bigger, and I have a lot of photos. I moved from Flickr to Picasa as it could cope with the directories full of photos and I didn't have to manually upload them and Google's storage space was cheaper. Then I ran out of space... over 100GB of photos, where next?
Hello Dropbox: https://www.dropbox.com/sc/um5zf95urdk3zmg/2SaSCUIQd8
And I've told a few photographers about this, and a few weeks later a friend of a friend of a friend excitedly told me on a forum how you can photo share in Dropbox.
And what I'm basically seeing is that the problem of "file sync" is being considered as solved by lay consumers, who really aren't prioritising encryption, and the problems that they now have is "share this directory of photos", and "share that directory of videos", and "sync this music privately, but let me play it back".
Dropbox isn't just file sync anymore.
What it is, is a serious threat to Flickr, Picasa, YouTube, Amazon MP3 Locker, Google Play Music, iTunes, etc.
And consumers are not thinking in terms of encrypted sync, they're just thinking in terms of "I just want to do X, why is it so hard", and so I can't see this (very nice) solution really solving the problems that consumers have, that will make them prioritise security.
I guess the marketing is to provide them with a nice level of deniability. It's not a Dropbox competitor, it's just encrypted folder sharing.
This service would mostly be used by us who are wary about trusting Google/Microsoft/Dropbox and the judgement of their automated decision systems with our life . Yesterday there was a HN story about a guy who got kicked off Google Docs because an automated program was trolling/mining through their users files and its judgement was not to be questioned by mere mortals.
What if I put a picture of me and my kid playing in the swimming pool -- what is to prevent Dropbox/Google/Skydrive from tagging it as offensive and setting an overzealous DA or social-worker upon my family ? People have been arrested/detained at border crossings for perfectly innocuous pictures like these.
Therefore if you think privacy is only important for people stealing stuff, your are being naive.
[1] http://tonyonsecurity.com/2012/08/05/securing-your-data-on-d...
> Yesterday there was a HN story about a guy who got
> kicked off Google Docs because an automated program was
> trolling/mining through their users files and its
> judgement was not to be questioned by mere mortals.
Wasn't that the user who was using a Docs form/spreadsheet to collect passwords from his customers? Google has stated that such forms are reviewed manually after being reported (for example, http://productforums.google.com/forum/#!topic/docs/7pKj6aXBK...), which means there must have been at least two humans involved.IMO the risk with cloud storage isn't in getting suspended by some daemon run amok, it's in data being too easy to leak. Files stored in Google Drive or Dropbox are just one accidental "share" click away from becoming public.
The link you submitted was a genuine scammer issue which was reported by users and dealt with correctly by Google.
The link in my post is just a citation as evidence that account suspension is a manual process.
I created the file.. added a few forum links with user/pass combos.. and within about 48 hours, the file was nuked and I had an email from google stating a document I had put on google docs broke their terms of service.
I went through the terms of service and couldn't find anything regarding passwords, but it did say that anything I put in google docs was owned by google and publishable by google, so I guessed that was the reason (they can't publish passwords?)
edit: I didn't get kicked off of google docs altogether though, just the one file got nuked
http://wmpoweruser.com/watch-what-you-store-on-skydriveyou-m...
a) I use my picassa photo albums for big dumps of regular photos I take when out and about, the storage is big enough I don't have to pay anything (yet) and I have thousands upon thousands of photos there
b) I use my flickr account (paid so unlimited) to put up photos I've curated and cleaned up and processed and stuck on a map someplace and given a detailed description of...basically I use it as a detailed travelog of places I've been. I'm about 4 years behind on it to be honest, but the flickr uploadr let's me bulk upload and getting things into the account currently isn't the bottleneck in my proces
On the other side of the argument, I bet BitTorrent Sync will become as friendly as Dropbox, and perhaps third-party backup services will offer what Dropbox does. At that point, rsync's only advantage would be an open-source license.
It seems to overcome NAT and dynamic addressing very well. All you need is to distribute the small shared secret once (for example, offline via USB, paper, or via the first letter of every headline in consecutive college newspaper publications), and you have the ability to transfer files (and do anything that can be boiled down to that; ex: chat, perform backups, publish videos of cats among your friends, distribute mostly static data between front-facing servers, etc...) without further coordination (for example, constantly renewing a DNS record, overcoming NAT, and keeping SSH or FTP permissions in order). Sure it may not be the best experience for all use-cases from a UX standpoint, but it is very general and, being serverless, it is better from other perspectives. I'm not boxing with you, only responding to your "?" and advocating for more such software.
I agree with you that this is a very important consideration: Sync services (even Dropbox) are not backup services and shouldn't be treated like they are. You are in an even worse predicament if you are using it to sync everything locally.
I particularly like BT Sync that it doesn't require "account" to use.
That'd cost you $9.50/month just for the storage, bandwidth and transfer costs are a bit hard to predict - storing your mostly-write-only archives are different from your mostly-read-only mp3 collection or your pirate-bay-sourced movie collection collection.
I'm quite excited by this - I've been planning-but-not-doing-anything-about a cluster of inexpensive processors (probably RaspberryPi's or TPLink WR703-Ns) running Tahoe/LAFS. If this busts through NATed internet connections like I suspect it will, I'll probably give up on that plan and just install a bunch of copies of this in various places.
The bike is made by a gent named Robin Mather who lives in the South West of England. His website is unfortunately a poor one, but he's got coverage elsewhere: http://apracticalguide.wordpress.com/ http://www.bespoked2012.co.uk/BespokedBristol/Robin_Mather.h... http://www.headsetpress.co.uk/features/robin-mather-building...
The stem is a fully bespoke (the whole bike is) ahead stem. It uses a barrel with a 6mm allen bolt through it. The barrel is split in two and the bolt squeezes the two halves to give a large contact area with the stem. It's worked well, no complaints.
One of the goals of that bike was to design it such that it looked aesthetically clean of bolts, fixings and braze-ons.
An example of that is the rear rack... remove the rack and mudguard and there is clearance for cyclocross tyres, and there are no braze-ons that give even a hint that the frame can take racks.
I was going for a single multi-purpose frame (touring, cyclocross, urban-fixed) by simply changing wheelsets and basic things... any change should be a 10 minute job. But yet, even with multiple uses I did not want to compromise the looks to achieve it.
The photos show the bike in the most complex configuration, the Rohloff hub, the dynamo front hub, the racks, the mudguards, the flat handlebars with Rohloff shifter. But basically you can strip it to a fixed gear bike with belt drive and just a front brake in 10 minutes, and then shove it in a suitcase (S&S couplers) and go travelling with it.
And even with all of that... the bike may be custom, but I kept everything compatible with standard parts so it's easy to get a long life from the bike as parts will be available. That stem... well, any stem can go on there.
Robin's a cool guy too. Which helps when you go this crazy on spec'ing a bike.
Good to know Dropbox can host some of the steamiest bike porn I've ever seen.
I am a musician and want to sync my tracks with a few producers. Bt sync is a good solution.
I am a political activist and want to ensure my data will be available to my affinity group even if Dropbox is threatened with a state security letter. Bt sync is an excellent solution.
I think it will need more cute cats before you can make that call.
http://en.wikipedia.org/wiki/Cute_cat_theory_of_digital_acti...
If they gained access to the sync group with full permissions they could destroy it and get IP addresses, etc. And the format itself might not lend itself to all the needs of a political activist group. But I don't see how the cute cat theory holds any water here.
Many ISPs, schools, cafes and corporate networks do this today already. They only allow HTTP (which goes through monitoring) and HTTPS which is decrypted by a MITM proxy (you have to allow their CA cert on your machine, uncompromised HTTPS is blocked).
In many countries this type of shenanigans are forbidden by law (friendly governments exist too).
I wasn't trying to argue that it was technically infeasible for an Orwellian government to stop it, just that it would be near impossible to stop where this type of traffic isn't already blocked.
It has to work before it can work well. Thus, while PGP technically works great, I haven't heard a lot of Egyptions, Syrians, etc, lauding Phil Zimmerman. Instead, they seem happier with Facebook.
If one member of your affinity group gets arrested, the police would have access to all of your files plus all of the IP addresses of everyone in your affinity group
IP addresses = VPN
Files = Truecrypted
Business scenarios make this good for us, but for consumers this isn't a Dropbox alternative.
Cloud sync leads to storage limits (which don't make sense as a consumer for file sync, but are necessary for large scale cloud sync) and centralisation (desirable for vast access, not so much for some situations).
BT sync isn't a Dropbox replacement, it's a file sync replacement that's superior in some ways, but lacks the benefits of being combined with cloud sync.
BT sync sounds like a complete replacement for dropbox for people with the skills and willingness to set it up.
Personally, I use cloud sync for a lot of backup stuff. Granted, it's mostly Git to BitBucket, but in school I used to push documents to Dropbox or Box just to have a backup. I wasn't interested in having my essays synced to my phone, just that if my other versions died I could download my work again to another device.
If you're referring to companies though, no I doubt they'd want a seamless and perfect system in somebody else's data center. That said, a data center and a perfect seamless cloud backup solution is a considerable cost, especially for a startup.
But yep, I agree, BT sync would be perfect if you didn't want/need Dropbox remote backups or web services.
Also, I often share individual files by using the "Get a public link" feature in Dropbox, and it's comforting to know they can just access those files whenever they want no matter what devices are attached and syncing.
Additionally, I wouldn't be able to get access to my files when I was at my parents without my laptop - which I can do with Dropbox.
Google+ does that too now, but this is in fact a killer feature which has been adopted well by the average folks out there. So yes, Dropbox is not just about file sharing anymore.
Though, I believe the use case GP is describing might be a bit different, depending on whether or not a dedicated camera is being used and how large the image files are...
What is a much bigger opportunity is a way that easily lets groups share music and movies. This cannot be solved by a centralized service like Dropbox for legal reasons. This is what would concern me if I was Dropbox; BTSync's killer feature is off limits to Dropbox without a complete change in architecture (and some soul searching about if they want to risk ending up like Kim Dotcom).
Automation of Google's algorithm thought he was a hacker, they fixed it and he got his account back.
You should have read the whole story ;-)
Where's the relevance? I asked why is Google, the entity, looking inside of private files?
> a probability of breaking the TOS
And my question was, if the files are private, why should their content be against the TOS?
Also, locking somebody out of their account because of a probability generated by a script, without manual confirmation by a human?
OMG. Some people can lose their jobs or money because of such flukes.
They probably don't want to allow the services to be used to aid illegal activity. Say what you want about how technology should be completely agnostic to matters of culture and legality, but that isn't at all the case.
They only fixed it because he pulled teeth, tapped friends on staff at google and generally had to scream and shout.
In no way was the trek he had to go through to fix an automation problem a good example of "Don't worry about it"
Plus the fact that if it happens to you and you don't have the inside contacts you have no guarantee of getting it fixed.
Just like many people have had their hotmail, paypal, facebook, itunes developer account etc. suspended for automatic detection of breach of TOS, and they've appealed and had their access returned.
This is not so much a google problem, as a reliance on 3rd parties to store your important documents, when everyone is warned (in tiny print) as to what may happen when they sign up.
I'm not excusing google's behavior, it's as bad as the rest of them, but they are playing by the rules we all agree to when we use their services.
Rubbish. Dropbox already has people's photos. It's easier and better to tap the screen a few times and share them there.
It's nice to be able to rollback/undelete files. Plus everyone is forgetting that Dropbox snagged Audiogalaxy a while back, so I'm expecting to be able to stream music back to myself from my Dropbox at some point as a service.
I just moved a bunch of stuff to btsync to mess with it but I still need to find a place offsite to keep it in addition if I want it to replace Dropbox. I'll likely use both tools in combination.
I have a use case that is pretty common among my peer group and BT Sync has been the best solution I've been able to find. In a nutshell, I need to sync large datasets across multiple computers.
Dropbox: expensive
AeroFS: buggy, used too much bandwidth, and slow
Sparkleshare: uses git which chokes on large files
Git Annex Assistant: didn't work reliably on mac
rsync/duplicity/unison: needs extra logic for detecting file changes
I also think the "Dropbox replacement" idea is a strawman created by the TorrentFreak article. I've never had the impression that BT Sync is trying to replace Dropbox. It is just trying to do p2p sync with a great interface and some nice features such as read-only and one-time secrets.
The biggest problem I personally have with Dropbbox et. al, is that none of the commercial solutions sync symbolic links opaquely. ("Opaque" syncing of symlinks means to sync the links themselves and not what the symlinks link to.) I use symlinks heavily and so I absolutely require this feature. Most of the commercial solutions just ignore symlinks, but Dropbox does the worst thing possible and treats symlinks transparently. This is utterly wrong and, in fact, downright dangerous!
Another feature that I need for telecommuting software development is to be able to exclude artifacts from what is synced. Eclipse, for instance, constantly churns out artifacts, and I certainly don't want or need those artifacts to be synced.
Two problems with my roll-your-own little syncing system remain: (1) The large file issue that you mentioned. (Sparkleshare is much worse in this regard than my system, last I tried.) (2) I know of no way to have the Git instance that I use for syncing not pay attention to the .gitignore files that are used by the Git instance that I use for version control. Annoying!
In any case, I'm very glad to hear that BitTorrent seems to be coming up with a solution that will address all my issues, and I won't have to roll my own anymore.
I was curious about this myself, but I never tried it, as I feared that this was precisely the badness that would occur.
Dropbox is so good in so many respects, I just can't understand how they could have made such an utterly terrible and wrong decision on this particular issue.
It is kinda lame that other services, e.g. Google Drive, just skip symlinks, but that isn't as dangerous. The hierarchical structure of a directory tree is often effectively part of an application's data, and Dropbox silently corrupts that data. This can cause crashes, or multiple conflicting copies of not-easily-merged data to be strewn about in different places.
It's also hard to initially notice how broken it is, since symlinks work on the first machine where Dropbox encounters them, but then on all subsequent client devices that Dropbox sees are replaced with some version of whatever data they point to.
What's even worse, is that no matter how hard I try, I am not able to convince most people of how wrong this is--even those who claim to be and should be computer savy. E.g., on support forums for other sync services, users are typically clamoring for Dropbox-style syncing of symlinks, and they will not be convinced otherwise, in spite of all reason. And despite 30 years of hard-earned experience with symlinks that irrefutably demonstrates that transparent syncing of symlinks is nothing but badness.
But thank goodness that BitTorrent got it right!
http://help.cubby.com/forums/169907-general/suggestions/3529...
This correct solution is precisely what BitTorrent Sync provides. So that's all the more reason to be thankful that a seemingly excellent sync solution has finally arrived.
What if you treat DropBox as a raw, strict hierarchical store and never use it directly, but only link into it from elsewhere? Move all the links outside of it.
ln ~/Dropbox/photos ~/Photos
ln ~/Dropbox/family/baby/cute-movies ~/Photos/baby-cute-movies
etc.(2) Your suggestion is extremely difficult or impossible to do in the general case.
(3) I have better things to do with my life than rearrange my entire filesystem to suit the ill-conceived whims of a product that does the wrong thing.
(4) I would like to sync parts of my filesystem as they currently are.
(5) I have my own syncing solution that works better for my needs, and it only took me a couple of hours to throw together.
(6) I'm going to use BitTorrent Sync in the future for most of my syncing needs (as long as it turns out to be reliable) since it does syncing properly in the face of symlinks.
(7) I'll still use Dropbox for simple sharing of files with friends and getting files onto my iPad. Apparently, Dropbox just doesn't care about the needs of more sophisticated users, as that isn't a very large market.
The tradeoff is to have all your stuff in one place, with is not a good thing most of the time IMO. A frequent problem I stumble on: there is a work folder where everything is already on svn/git, but I'd want to temporarily sync a few folders to dropbox only when needed, and get them out of dropbox when finished. As dropbox works now, to do this without using symlinks would be a PITA (I'd have to put all my files in the dropbox folder by default, and then play with the selective sync ? I am not even sure there is a way to do it without moving files around).
If dropbox had support for arbitrary multiple folder selection (but the the complexity would go way up?) I'd agree with your stance on symlink, but now this is more of a necessary evil.
I think you already answered your own objection on the right way to handle this need. Other syncing services, including BitTorrent Sync handle your need in precisely this manner. I.e., the right way. Dangerous, frustrating, and incorrect abuse of symlinks is NOT the right way to do this.
Is it so difficult to add a one line configuration item to your inotify cron daemon (incrond) ?
/home/my/directory IN_CLOSE_WRITE,IN_CREATE,IN_DELETE /my/unison/sync/script.sh
It works.
Why is this a problem with Flickr? I am generally shooting high res full frame, and post to Flickr. I have about a terabyte of images. There's no 100GB storage limit, just an annual flat fee.
Family can download full resolution images for printing. My grandmother can have my Flickr Photo Stream as a screensaver in her TV. I also enjoy fantastic two way integration with photo management tools, with tagging syncing back.
I can't see why I'd pay Dropbox considerably more for less features.
(What's more, if Flickr doesn't like a public photo's content, the worst that will happen is getting marked "not in public search areas", with an easy redress to get reinstated. It's unclear to me what Dropbox will do. Meanwhile, if Google doesn't like a public photo, I can lose my Google Account, as photogs have found to their chagrin.)
http://ipont.jubilo.ca/ip/flickstackr/
http://connectedflow.com/flickrexport/
I like Everpix too, fun to see what it comes up with for its "moments". Cool idea.
Which photo management tools do you use? I currently have around 45k photos (~200GB) and Picasa is sometimes just too slow. I am planning to get a DSLR soon, so total size is going to be expanding rapidly. What kind of tools would you suggest? I am on Windows mainly, so Mac-only is not an option. Thanks!
Some detail for you:
I use Aperture for most photos. I use Lightroom for slides. On the PC side, you should use Lightroom. It's just gone into beta for version 5, try it now for free.
I strongly prefer the Aperture workflow, but for slides Aperture won't recognize my 64 bit .DNG files with infrared channel as being part of a JPEG/RAW pair, while Lightroom will.
I manage photos on the latest Mac Mini with the Fusion Drive, but the photo libraries are actually stored on Western Digital MyBook Velociraptor Duo Thunderbolt drives[1] which are insanely fast in RAID0 mode. With Thunderbolt I can attach that to a laptop or the Mac Mini and Aperture is licensed for 5 computers. I had been using the built in Fusion drive for my latest project triage, but the Velociraptor drives in RAID0 are so fast it's not worth the hassle of splitting that out.
I use a nightly rsync to replicate the libraries onto a LaCie 4big via Firewire 800. I never have less than two copies of photos on two devices, because I use a Nexto DI[2] to import the photos from flash while on the go, then I import from that into my libraries, leaving copies on it until I need space. Or, for things like iPhone imports, I import to the LaCie RAID, then import into Aperture's RAID0 library for speed, and again, only delete from the RAIDs when I need space and after I know Aperture's backed up. I also have a Backblaze[5] job backing up everything offsite for their flat fee.
I have three libraries, one for 2000-2010, one for the current decade, and one for international travel. While travel is less frequent, a trip generates more photos, so my domestic and international libraries tend to be similar in size. Each is 50K to 150K photos, and in the 350GB - 750GB range.
I use Aperture's library in the fully imported mode, where photos are stored in the library. This way I'll never accidentally move or delete a photo I want to keep. Of course, the library is just a package folder, you can CTRL-Click it to open it up and get at any of your import sessions original or raw files. Even if the DB is completely destroyed, the photos are safe.
I use the incredible Nik Collection of plugins. They were worth it at $750, and so much more worth it at Google's new price of $149[3]. These plugins work with Lightroom or Photoshop as well.
With over a decade of DSLR photos under management, I recommend you use a folder and image naming scheme like this:
yyyy
yyyy-mm-dd event descriptor
Event Descriptor (nnn).ext
If I'm using generic file system tools rather than a true photo management app, I name the file in a way that lets me search, sort, and reconstruct the original file, regardless of file system capabilities: yyyy-mm-dd hh.mm.ss event descriptor nnn (ORIGINAL-FILENAME).ext
Moving images around across file systems will likely eventually lose the date, with this you can use a simple shell script to put back the create time. Or use ExifTool to get the data back from inside the file[4].---
Links referenced:
1. http://www.storagereview.com/western_digital_my_book_velocir...
2. http://www.amazon.com/Nexto-Digital-Photo-Storage-ND2730/dp/...
3. http://www.niksoftware.com/
It still looks like an interesting product, mind you...
Dropbox for privacy minded people if you will.
I need a solution for on the order of 40,000... for which Flickr is perfect, since there is no storage limit, just a very small flat fee.
I have approx' 40k photos (not including the .raw files) over about 180GB (including the .raw files).
Uhm... how about the 200 GB plan? Or the 400 GB plan. Or 1 TB for $49.99/month? Or you could contact sales about Google Cloud Storage: https://cloud.google.com/pricing/cloud-storage Or you could just buy S3 storage.
Actually, there are literally dozens (to maybe even hundreds) of alternatives for hosting static content for less money for more bandwidth.
For example, a micro instance, with 500GB of EBS storage, with allowance for 1% data growth per daily snapshot (S3 backed), and 50GB of transfer per month will apparently cost $175.68.
The 500GB plan from Dropbox will cost you $499 .
I'm thinking, with enough data, Bittorrent Sync wins the pricing war, and I've been doing some testing on the client and it seems really resilient to data changing while syncing etc.
It distributes the files intelligently and makes optimal use of everyone's bandwidth. Dropbox, for example, slowly uploads all files to the cloud before distributing them, plus there's the space issue. AeroFS allows unlimited space, but is far slower than my Internet and LAN speeds allow, and does things like trying to upload the same file, linearly, to every peer at once. Cubby has limited space and has the same slow syncing problems.
I'm running BitTorrent Sync on my 6 year old Windows 7 Thinkpad, a newer Windows 8 desktop, a Digital Ocean Ubuntu VPS, and a Synology DS110j NAS. It runs perfectly on all of the above, and provides a useful web interface for the VPS and NAS.
http://www.retrologic.com/jargon/W/wheel-of-reincarnation.ht...
The wheel of reincarnation I'm referring to in this case is the cycling between a mainframe/thin-client architecture and a PC-based distributed architecture.
In ye olde days it was mainframes and dumb terminals. Then it was PCs and LANs/the Internet. Then it was web browsers and tablets (dumb terminal 2.0) and The Cloud (mainframe 2.0). Now the wheel is turning once again...
The cloud is great as long as I don't care who owns my data, want to pay constantly for hosting it (or put up with arbitrary and changeable limits), have no privacy, lose my data when a startup goes out of business, etc.
Get a "dumb" laptop with plenty of horsepower/space, sign in to something and sync everything over (chef/puppet/btsync/dropbox), do a bunch of work locally, then wipe the laptop.
I'd love to have my whole laptop identity work that way. It's sort of possible now but it takes forever to convert all your data and apps over to that approach.
People will dismiss this as 'a toy that geeks use', but as Chris Dixon has noted, 'what the smartest people do on the weekend is what everyone else will do during the week in ten years' [1]
[1] http://cdixon.org/2013/03/02/what-the-smartest-people-do-on-...
With just a tiny bit of crypto code you could add a repudiation feature (keys signed by the secret vs the secret itself) and control access to both individual groups and individual users.
>BitTorrent Sync’s functionality is comparable to services such as Dropbox and Skydrive, except for the fact that there’s no cloud involved. Users sync the files between their own computers and no third-party has access to it.
> It is an ideal tool for people who want to share large amounts of data between computers without going through third-party services.
>The Sync application is available for Windows, OSX, Linux and has the ability run on NAS devices through a web-interface. Readers who are interested in giving it a spin can head over to BitTorrent labs [1], where the Sync app can be downloaded.
Another way would be to do TCP or UDP hole punching, but that involves a third party for initial setup. Probably possible and probably safe, but I'd like to see a security review of that.
You have to have a source always online, there's no third party service sitting in the cloud syncing all of your computers, it passes that responsibilty onto the user. That said, I'm surprised they aren't trying to "consumerize" this into a hardware product.
Space Monkey has seen a ton of success recently and are well beyond their funding goal on Kickstarter(http://www.kickstarter.com/projects/clintgc/space-monkey-tak...). The thing that immediately came to mind for me is that this is really a job for Bittorrent.
A NAS device makes complete sense and if they could build a better experience around that, similar to what Space Monkey is doing, seems like a huge opportunity.
Up until now BitTorrent aficionados have tended to be forced back to the "I use it for Linux distros" when defending the protocol against ISPs and businesses looking to shape or block BT traffic.
If this takes off, then the "its only used for nefarious purposes" argument will be much harder to make.
I suspect that this is the real reason it's being launched - not that that's a bad thing.
If they are not using BitTorrent then Sync would provide a new, plausible way to stop ISPs from blocking that specific protocol.
Well, apparently Blizzard does. :) Quoting http://www.wowpedia.org/Blizzard_Downloader
There's also http://debtorrent.alioth.debian.org/
Apparently CCP is planning to use bittorrent for the next generation launcher for EVE online:
* Ability to handle large files (300MB incompressible Photoshop) and able to handle large complete data stores. (1 TB, which is impossible with Dropbox)
* Selectability for certain folders on certain users (no need for all data to be on all machines)
* The ability to 'archive' files to only the host.
* Good LAN networking with host so that the portable machines (iPads, Retina Macbook Pros with puny 128GB HDD) can use it fine.
Maybe both BT and AeroFS should help customers mitigate that risk by committing to open source their code if they shut down. AeroFS has a revenue model, though, so I'd be less concerned about them shutting down this product.
It seems like the next step is for someone to attach a NAS to a RasPi and make a "syncbox" -- a NAS which auto-syncs to the other NASes you've configured across the internet.
For end users, they would get 2 and share a secret between them, then install one at 2 separate offices (or home and office), and any files dumped onto one NAS are replicated to the other. Basically Dropbox without file limits.
I wonder how replication between 2 devices would work...
But it doesn't store your data, so yes, one device must always be on in order to sync with a new device. However, if you have a device that needs changes made on another one, it will just wait around and sync whenever the device with changes comes back online.
For me to consider switching to this service from Dropbox, it would have to be able to temporarily store some of my files from my work computer so that they could be transferred to my home computer later on when that computer was started up (for example). That is the feature that needs to be implemented for this to truly become a Dropbox-killer.
If I have to devise some system to zip my important stuff and keep that up to date, then I may as well just use BTSync for free.
I see two key use cases that could cause trouble:
1)a co-worker turned his computer off and went home from work, the syncing couldn't complete even if only a single doc was left
2)Because there is no central server if all of my coworkers in a distributed team sync with my new shared folder at the same time, it is required that I own a connection capable of supporting that kind of traffic, because it would be almost the same as streaming a video to multiple users, not to mention that I would probably have to avoid to browse the web for pretty much anything else in the meanwhile.
As far as 2 is concerned though, that is not the case. Don't forget, it's built on top of BT. As each piece of the file gets transferred to other clients by the original machine, the other clients will be able to send those pieces out too. In theory it will be faster than a transfer from a central server.
"We also provide such additional methods of ensuring connectivity as relay and tracker servers."
If I want to share files with the general public I could just give them a read-only key and then they'll have a folder that syncs with whatever files I put into it. It's a new way of content distribution.
Will this be how people distribute music and TV shows?
Will this be the way people subscribe to content in the future?
I could be a game developer, and I could give my users a read-only key to download my game and at the same time they'll receive any updates I make to the game when I update the files in the folder.
Still reading the analysis of the system. Have to read through the spec.
It would seem to me that read-only peers would have to have the ability to propagate writes across the network. Why would they have to identify the origin of the change if they obviously have cryptographically secure evidence that the change is valid?
For example you can use TrueCrypt and create/mount a drive volume that is fully encrypted while synced across a file share storage/sync service like DropBox.
The only downside is that you have to install the TrueCrypt application on your client device, which does limit is platform offering (currently, no mobile).
A better solution is to use .sparsebundles (Mac only) or something like BoxCryptor/encfs that encrypts files in the volume individually
I use encfs though, good suggestion.
BoxCryptor does look like a great alternative; however, it's not open source and does come w/ a price (literally and figuratively - file names exposed if using free version or drop $50 USD).
Have you used BoxCryptor? Curious what your experience has been. I'll give it a try.
The real problem with using a Truecrypt volume on Dropbox is concurrent changes to the same volume. It happens if you mount the Truecrypt volume on 2 machines at the same time. It will mess up badly.
Long story short, I setup BS on both machines with an absolute minimum of fuss, copied the password over, and the folder synced. Definitely does one thing and does it well.
There are lots of hard problems to be solved in such a system (mostly dealing with the lack of trust), but I think it would be totally badass.
The config file is versatile enough to allow you to turn off the relay servers / dht / upnp, etc and simply declare static peers, which is cool.
1) has a fully supported client on Windows, OS X and Linux
2) has that capability to sync with mobile devices
3) uses the native file system apis available on each platform to avoid doing scans on large numbers of files looking for changes by the last modified timestamp (so I don't have to disable the TrueCrypt feature that avoids updating the timestamp on containers)
4) transmits only the changed content of the file instead of the entire file (so I don't have to transmit the entire TrueCrypt container when only some blocks in the container have been modified)
Has anyone ran across a service that would allow me to utilize TrueCrypt volumes as easily as DropBox does across the major desktop operating systems?
[1] http://forum.bittorrent.com/topic/8816-will-syncapp-be-open-...
Umm, how do they know this if the sync is secure and only peer-to-peer?
Not sure if this has anything to do with it but by default, "Use relay server when required" is checked for each folder you share. But I would hope that it doesn't go through a relay server all the time.
My idea would be to lump together all the files in a huge torrent. That would inevitably attract many peers, so the problem would be solved if users did selective downloading, as the whole would be too large for any one of them.
The system would need to use some disk space and bandwidth from each peer to host some shards of the whole. Not all the data in the mega-torrent would be downloaded, just some sensible section of it, like, say, 5GB. Between 1000 users, we could have 1TB of files. With a million, we could have a huge library. This way we could have enough seeds for any part of the whole. Of course, it would need a way to add new stuff on the fly and balance the replicas.
tl;dr - I'd rather have a solution for rare torrents. I'm worried for all the content that is not "hot enough". We could amass a huge library of rare stuff, in time.
BitTorrent clients now have distributed hash tables accessible; it would be nice if magnet URLs could just point to a hash of the file, instead of to a specific torrent.
Bonus: Even ED2K links point to a tree of hashes, so you can verify the data while it is being downloaded.
In one sense, that is not an accurate comparison at all. And yet, it has enormous potential to fill a similar role.
The secret/passphrase amounts simply to a globally-addressable identifier to a set of folders that just happen to sync.
It will be trivial to script a loop to watch a control file in a folder to enable automatic FTP-like transfers between my friends. Even without keeping the "secret" secret, instead simply treating it as public but discardable, you have something that can rival (and is a faster-moving target than) file lockers like Mega and Rapidshare (300 TB do not need to be re-uploaded in order to change the secret/address).
The sad thing is that NAT and firewalls have starved the Internet to the point that that simple property (global addressing) seems almost miraculous. (And that is why IPv6 - or something permitting global addressability, instead of carrier-grade NAT - is so important going forward.)
BitTorrent Sync synchronizes your files using a peer-to-peer (P2P) protocol. This protocol is very effective for transferring large files across multiple devices, and is very similar to the powerful protocol used by applications like µTorrent and BitTorrent. The data is transferred in pieces from each of the syncing devices, and BitTorrent Sync chooses the optimal algorithm to make sure you have a maximum download and upload speed during the process.
The devices you setup to sync are connected directly using UDP, NAT traversal and UPnP port mapping. We also provide such additional methods of ensuring connectivity as relay and tracker servers. If your devices are on the same local network, BitTorrent Sync will use your LAN for faster synchronization.
Or does this simply make direct connections between PCs you own and people you have authorized to share your files?
> While Sync uses BitTorrent technology, people’s files are not accessible to outsiders. Only those who have the unique private key can access the shared folder.
>
> “All the traffic is encrypted using a private key derived from the shared secret. Your files can be viewed and received only by the people with whom you share your private secret,” BitTorrent explains.
There are relays if you need them due to firewalls:
"We also provide such additional methods of ensuring connectivity as relay and tracker servers."
But you can opt out of this config.
Anyone here already using BitTorrent for deployment?
Anecdotally, it worked great! Didn't need to do it again though, so I never cleaned up or documented the process.
Sidenote, but, if Dropbox people happen to be reading this, maybe this will be a hint: PLEASE ADD MULTIFOLDER SUPPORT. (As in, multiple roots). I know you're trying to go for a simple aesthetic etc. etc., so you only have "one" dropbox, but BTSync makes doing that trivially easy. You have no excuse.
When the source is closed, and the protocol is closed + encrypted? I think you may be a little optimistic... (Though I do hope that either the source or the protocol get opened)
There are a few advanced configurations where BTSync trumps Aero (at least last time I used it - someone, please correct me if these have been implemented).
- One way sync
- Selective device LAN sync (so you can tell it to only sync over LAN)
- Self destructing one-time share keys
- Less-friction on sharing - using a key based copy and paste system
- Powered by BT (this may not be an advantage though since BT is throttled on quite a number of providers through DPI worldwide
Additionally, AeroFS relies on Java, which is pretty big dependency (read: pain) to have on resource-restricted environments like a tiny NAS box. The daemon process of AeroFS consumes about 110MB of memory (I guess due to JRE), but my NAS unit has only 256MB memory in total with less than 100MB free, which means even if AeroFS supports PowerPC, there is still no way I could run it smoothly on my NAS without killing its performance.
Bittorrent Sync supports all of x86/x64/ARM/PowerPC, and the download is just a single 3.7MB binary without dependency other than glibc. Running it on my NAS shows it consumes less than 10MB memory. This is just so much nicer for deployment on a wider selection of devices.
I'm definitely going for BTSync now.
I agree that the main gripe with AeroFS that people have voiced in this thread is certainly valid. AeroFS _did_ slow down in performance for some users recently. We actually just released a version today that addresses this bug (0.4.181 - see http://ae.ro/Ln2YJJ for the release notes, but it specifically had to do with the way we were initializing our jingle library), and in our own internal tests the performance has improved dramatically.
The best thing about BTSync is it's basically zero configuration. I have it running on 10 of my boxes so far, and it's working amazingly. Far better than dropbox -- however, I only need it to sync files between hardware, not for anything else, like photo sharing, or advanced configuration based sharing. I just want file A, to be on all configured servers.
TL;DR: Don't compare BTSync to Dropbox, it's not a dropbox alternative. It's something completely different, entirely.
This is just far too likely for me to remain an unaddressed issue. I don't know if it's been improved since then.
I tested it out like this, on two machines (Mac Pro No. 5 and MacBook Pro No. 5, sorry for the confusingly similar names):
[mason@MacBook-Pro-No-5 ~]$ cd BTSync/
[mason@MacBook-Pro-No-5 BTSync]$ echo 'Hey man, this is draft one. ' > my_awesome_file.txt
Here I waited for it to sync and confirmed the same file was on both machines.Then, in two terminal windows:
[mason@Mac-Pro-No-5 BTSync]$ echo 'hello from Mac Pro at remote office' >> my_awesome_file.txt
[mason@MacBook-Pro-No-5 BTSync]$ echo 'hello again from local office' >> my_awesome_file.txt
I pressed Return as close to simultaneously as I could in each window, with the MacBook Pro No. 5 machine being second.While it sync'd, I just had time to visually confirm that the contents of the two files were as expected, and different from each other.
MacBook Pro No. 5's file:
Hey man, this is draft one.
hello again from local office
Mac Pro No. 5's file: Hey man, this is draft one.
hello from Mac Pro at remote office
A second later, the sync was complete. The file from Mac Pro No. 5 was completely gone, and both machines's my_awesome_file.txt now contained: Hey man, this is draft one.
hello again from local office
I then looked in the .SyncTrash dir on both machines, to see if the nuked file made it in there, but it did not.Conclusion: Modifying a file on two machines will cause one of the conflicting versions to be annihilated permanently. Furthermore, this can happen nearly instantaneously, making it unlikely that any backup mechanism would be able to preserve the 'losing' version of the file.
Thoughts: I think this is a potentially serious problem and I hope they fix it. Still, to me personally, this is probably preferable to my main problems with Dropbox (slow speeds and utterly broken symlink behavior, as discussed elsewhere in this thread). Overall I am still pretty excited about this product.
I got caught out with the pre-defined host config because I didn't realise I needed to allow both tcp AND udp through the firewall, so my work machine was unable to access my privately shared folder on the home machine (tracker server/relay server/dht options all disabled)
Once that was sorted, I have a perfectly good replication system working amonst all my machines, just like dropbox, without the centralised control, this is awesome
Imagine a private p2p site that you and your friends use. You choose who to share with and what files you can see.
Then add links to give to friends so attaching files in emails would be a sinch.
It'd be nice to do that without an escrow, but I'm not sure that's really possible (without steep obligations on members as to hosting capacity and uptime).
We already do this with git-annex.
I'm building a backup service for sql server, and wonder if this route could be better than rsync?
edit: The UX needs a bit of polishing. I don't think my Mom is going to be able to figure this out.
Yes, I believe that, because that's a completely solid business model for them.
How can BS connect to ownCloud to push the updated files to avoid an emergency where, you're not a Dropbox member, and your device was stolen and turned off?
AeroFS does something similar and it apparently doesn't require keeping two of your machines On at the same time, though it didn't work for me as advertised, so I gave up on AeroFS.
Using Dropbox in the title with this, is misleading.
I don't want a central service like Dropbox to host my files.
This design decision means that I must keep one or two of my machines on for my files to be available.