I'm not sure that PrivateStorage actually adds anything to the equation?
EDIT> The Tahoe LAFS  model is more that you spread your data over multiple providers. NAS at home, several VPS providers, or what have you. It feels like RAID in the network, and it allows very precise setting of redundancy policies.
So syncthing actually only runs on trusted machines, whereas PrivateStorage will be able to run on both trusted (tightly managed) and untrusted machines (like a VPS in the USA).
- ec2 instance (light burstable, always on)
- desktop (debian)
- laptop (manjaro)
- desktop (windows)
- phone (one-way sync to get photos off the phone)
- tablet (kindle fire)
It has been great. Solid and trustworthy. It picks up changes made before the service was running, handles deletes and renames just fine, and updates are simple. The web-based UI is good.
I like that calmh and the team are not adding lots of features. There are lots of things they could add to make syncthing "better", but they want to make sure syncthing does one thing well.
One nit - the UI shows the "latest change" for each folder. The common understanding of this phrase would be "the file in that folder that most recently changed" but what syncthing actually shows here is "the most recent change that syncthing made to this folder". That means that if I change a file on the current device and syncthing picks it up and replicates it out to the other devices, that change will not be shown as the "latest change". If some other device changes the file and syncthing replicates that change back to the current device, then it will be shown as the "latest change". This is confusing. "latest change" should just show the file that most recently changed for any reason.
That includes a synchting-share for my automatic backups and my "dropbox" replacement (a simple directory for syncing between phone, and computers).
It works great. I haven't had any issues with it. The current release of syncthing is very stable. Earlier versios were a bit error prone. But they seem to have fleshed out most, if not all bugs i encountered in earlier versions.
* Camera: 1.8 GB, 243 files
* Documents: 10.8 GB, 4604 files
* Music: 61.5 GB, 25077 files
* Passwords: 660 KB, 726 files
* Pictures: 16.5 GB, 6450 files
The passwords are managed by 'pass' , which is viewable on my phone using Password Store . Cold-launching Syncthing takes ~10 seconds on my phone, but it does it automatically on boot and thereafter runs in the background. Battery impact seems to be negligible.
: https://f-droid.org/en/packages/com.zeapo.pwdstore/ and https://play.google.com/store/apps/details?id=com.zeapo.pwds...
Now I use Tresorit (which I only became aware of because of... and online ad!?) It doesn't seem to have sync issues for me. Dropbox didn't have issues either, but it wasn't as secure.
I wanted so badly for Nextcloud to work.
The ability to have untrusted nodes is the one feature that has kept me using Resilio Sync.
 - https://github.com/syncthing/syncthing/issues/109
plain <-> syncthing <-> phone
encfs <-> syncthing <-> dropbox
Some syncthing nodes could host only the encrypted data, without the keys to decrypt them. This adds the benefit of having some nodes host the data, without being able to access it. Think: VPS, etc. that have very good availability track record, but some doubts about whether your hosting company can spy/might be coerced into spying.
Unfortunately there doesn't seem to have been much movement towards making it a feature.
Do storage providers have an incentive to provide the service reliably à la filecoin? 
For other kinds of Tahoe deployments, no there's nothing built-in to incentivize storage-server operators. That part is up to whomever is organizing and running the Grid (what Tahoe calls a group of storage-servers). For example, friends could agree to host storage-servers for each other and create redundancy + trust that way.
The difference between Tahoe and things like Storj / FileCoin is that those services intend to be "a single, global service" whereas Tahoe is software that can be deployed in several different ways -- one of which is a professionally managed Grid such as PrivateStorage.
If you are interested in these topics I'd encourage you to join #tahoe-lafs on Freenode or one of the Tahoe development meetings. These are definitely things I've seen discussed but I think Tahoe-LAFS is far more likely to introduce a concept of "federated Grids" rather than "a single global Tahoe service".
We are working to make doing even this as user friendly as possible.
Yes, via a currency called Dollars.
Making user owned storage user friendly for people with non sys admin skills is a challenge, but something we are working towards.
because our gaia hubs are associated with user's ids, we are also working on automating SSL as much as possible for individual users as well. This is another technical challenge that makes it difficult for the average person to set up their own trusted environment where they control their own data.
So if you happened to "not completely trust" the availability of those you could also configure one of your own and configure your client(s) to use that and the PrivateStorage servers. That is, hedging against PrivateStorage going away so suddenly you can't retrieve your data.
But, I agree: if you're doing that you're likely able to run your own Tahoe grid on VPSes or similar.
I also like this when you give them your email:
>> This is not a mailing list, and your email will be permanently removed after we send a one‑time notification when PrivateStorage is available to the general public.
Tahoe-LAFS makes some impressive claims like maintaining confidentiality while running on untrusted machines. I think a lot of folks now would assert that really any machine running x86 due to Intel ME and the AMD equivalent should in fact be untrusted.
I'm not in a position to criticize though, this is just from a cursory glance at the summary page, and frankly I used PIA as my own VPN provider for a number of years and had only positive experiences.
> Tahoe-LAFS makes some impressive claims like maintaining confidentiality while running on untrusted machines. I think a lot of folks now would assert that really any machine running x86 due to Intel ME and the AMD equivalent should in fact be untrusted.
To be precise, our claim is that you can use untrusted servers, since the client encrypts the data before it leaves your machine. You are, of course, entirely reliant on your own client being trustworthy. Nothing can save you if your client is compromised, whether via ME, a BIOS infection, an OS rootkit, or a boring old userspace compromise.
The Tahoe-LAFS client runs pretty well on ARM and Raspberry PIs, in case that feels better.
It feels to me like 'borg' is becoming the de facto standard for this use-case. There were a number of similar tools (like duplicity) for years but borg seems to have buttoned up all of the issues.
Some call it the "holy grail of backups".
> the system runs on Tahoe-LAFS
that got me very interested.
You have to trust the client code, for sure, but that's something that you're at least nominally in a position to inspect and verify. https://github.com/tahoe-lafs/tahoe-lafs
We have an Amazon EC2 AMI, and are working on others, but the idea is you could bootstrap the docker-compose on any VM you like, or a rasberry pi if you want even: https://github.com/blockstack/gaia/blob/master/hub/README.md
There are IPFS driver requests and now requests for drivers to support privatestorage by Least Authority as well, if you also want to replicate your data temporarily across some nodal network.
While gaia fundamentally does not require using the comprehensive Blockstack API, we are working on tutorials to abstract the use of only gaia without Blockstack. They are designed to be functional independent of each other, in the same way people can use Blockstack authentication without gaia, the reverse can be true: https://docs.blockstack.org/storage/overview.html
Currently, I want it to be even easier than just bootstrapping a docker-compose in gaia for users to host on their own machine, or rasberry pi or what have you. We are working on that as well as cloud hosted solutions.
I would like for people to be able to launch a vm with a preinstalled image locally on their own machine, not just google cloud, amazon, Digital Ocean etc. The groundwork for a secure and minimal VM is mostly in place. We need to set up more instructions for this but feel free to launch the docker-compose and give it a whirl in your environment of choice if you don't want any of the cloud AMI's we currently offer.
If you are using redundancy of any kind, it will inflate the size of the ciphertext versus the plaintext thus affecting sync speed.
Tahoe-LAFS does split everything up into fixed-size chunks, though, so the total size of the file doesn't really matter -- it will still be uploaded in 128kb (default) chunks to the storage servers.
So, it's not the encryption that has an impact but the erasure-coding (which gives the "RAID-like" features) and you can configure it to have zero redundancy and thus only some slight increase in the total amount of data to send.
Tahoe does use "convergent encryption" (basically, the key is based on the contents) so that the same file encrypted by the same client results in the same ciphertext (and thus, doesn't need to be re-uploaded).
I believe that only happens at the "capability" (i.e. file) level, though, not each chunk. So, if you had a directory of 10 files each 100MB and changed one, you'd only have to upload the new directory-descriptor and the one changed file -- but if you change a few bytes of a 1GB file, you'd have to upload all the ciphertext for that file again.
I understand that there could be reasonable arguments behind, but I feel very uneasy about it.
Also, I'm not sure how you can use tarsnap at good cost for p2p sync.
I love the tech behind tarnsap, I love that the client is open source, I love the whole philosophy of it but I really struggle with the pricing.
No, it's source available.
It's also not very creative. Says a lot about the maturity of their their thinking when there's such obvious naming similarity.