Cool. I'd love to see a section detailing the most important trade-offs that differentiate upspin from other projects, compare the approach to the alternatives and explain why upspin's approach is superior (for $TARGET_USE_CASE)

That's the plan! :-)

What problem does this solve for the end-user that isn't already or better solved by Google Drive, Dropbox, or sharing in chat apps like Hangouts or WhatApp?

Or is it like, "Here is some cool technology!" without identifying a clear user need this solves, like Google Wave?

Dropbox uses one key for all content...

Google drive means google can see all of your stuff...

Sharing in hangouts is just like drive...

WhatsApp isn't close to this robust...

Wave was just really far ahead of its time but you see the modern incarnation in google docs and paper. This is like the infra to build spideroak on your own hardware.

It's not the same as a service where you have to trust the operator.

Seems niche. Most people trust at least one of the above operators.

How about MEGA? It's sort of like multi-key Dropbox.

Centralized, but not inherently so; you could stand up clones using its same API, and then create a discovery service mapping bucket names (users, whatever) to servers using that API.

SpiderOak is a Zero-Knowledge service. You don't have to trust them.

And you shouldn't.

I wanted to link to various people who have experienced data loss in SpiderOak (me included) due to bugs in the client which have gone unsolved for at least three years.

But....they seem to have redesigned their homepage and the forums that used to be available seem to have gone.

Here is one example though: https://spekxvision.wordpress.com/2015/10/13/more-spideroak-...

So I can only talk from a personal perspective and my experience with their CTO and support team. I've lost data on multiple occasions due to bugs in the client. This data was not recoverable. I've since switched to Crashplan and am much happier.

Agree, SpiderOak is far from good. Haven't yet experienced data loss, but their sync is very slow and, with custom synced folder (not the 'Hive' one) pretty unreliable.

From Crashplan's web page I don't see if they do file sync, what do you recommend for this domain? I'd use OneDrive, but supported Linux client is a must.

You're right. I use Crashplan for backup. Haven't really found a solution for sync that I like. Missing Linux client is a problem for me as well.

> google docs and paper

Paper?

Dropbox Paper. It's multiplayer Wordpad -- a reversion to the "big white space that (ironically) doesn't pretend to simulate sheets of printer paper," now with emojis.

Does upspin have a known "set of tradeoffs [that are] somewhat unique" or does the community need to flesh them out? High-level bullets would be nice.

We haven't written the docs. That's what the issue I linked in the parent post is about.

Are there going to be docs aimed at developers of Upspin-compatible & -interoperable implementations?

Don't know if you are allowed to comment but:

Is this an early sign of Google going back to its "not evil" roots or do I read too much into this?

Edit: for context, I used to be a google fanboy and I still to sone degree recommend some of their products. I just got a bit fed up with the butchering of xmpp and possibly a few things I can't remember right now.

It's not a Google product. So no. (not that I'd agree with it not adhering to those roots currently. Just that this project has nothing to do with company policy)

"This is the official list of people who can contribute (and typically have contributed) code to the Upspin repository. The AUTHORS file lists the copyright holders; this file lists people. For example, Google employees are listed here but not in AUTHORS, because Google holds the copyright."

There is a difference between "a Google Product" and "Code to which Google holds copyright". Most importantly, the latter may include all code written by any Google Employee during their employment.

There is a difference but it is only interesting once you get really close like in a lawsuit IMO.

Google has copyright on the code and runs the infrastructure?

Very much a Google product to me. Paid or not. Official or not.

But it makes a philosophical difference to the involvement of the company, of the people working on it and also a practical difference, because products and non-products have very different launch-requirements. You are perceiving Google as far more monolithic, than it really is; the difference between a product and a non-product is how different employees of the company interact. To the outside world, that might or might not have any meaning. But I feel for the original comment that I replied to, it does.

From the docs:

> Terms of Service

> The Upspin website (the “Website”) is hosted by Google. By using and/or visiting the Website, you consent to be bound by Google’s general Terms of Service and Google’s general Privacy Policy.

Really a shame.

We are aware of kbfs, ipfs, and several other systems. There are many trade-offs one can make in this space, and I think Upspin's set of tradeoffs is somewhat unique. One reason we started this project instead of contributing to others is that it's not clear that the trade-offs made by extant systems are really working for users, at a fundamental level. Maybe Upspin's will, maybe they won't. We'll see. We wrote a bit about this in https://upspin.io/doc/overview.md but there is still more to say. I filed an issue a while back to write a substantial document that compares Upspin to other systems. Hopefully the community can help us flesh it out in time: https://github.com/upspin/upspin/issues/177