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

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

I think KBFS is a sort of an add-on to Keybase, which is really quite different from this. Keybase's whole schtick is identity and key management. How do share a file with a stranger without exchanging emails? What happens when you lose the email you signed up with? How do you share keys between your devices without trusting a for-profit company's keystore? Keybase solves those for you, and IMHO is quite novel and useful.

Upspin is a separate thing that focuses entirely on how files should be stored and identified, and (AFAICT) does nothing new regarding identity management. Which is unfortunate, because that seems like the more urgent problem right now.

The comparison to kbfs and IPFS seems relatively straightforward based on a cursory reading of the three web sites...

kbfs still stores files, and I still depend on them to keep their service running. kbfs adds key management via keybase, but the file sharing model doesn't seem significantly, or at all, different than Dropbox.

IPFS on the other hand is completely peer-to-peer, meaning I have little control over content I publish. I can publish new versions, but my old content is still on the network, and forever out of my control.

Upspin provides a middle ground by providing a protocol for key management and server lookup. Unlike kbfs, the files live on servers that I maintain control of. Unlike IPFS, I can delete or update content after it is published, as needed.

Seems to be very much in the space of kbfs and IPFS. For the folks who are building this: can you compare and contrast this to both kbfs and IPFS? Why have you chosen to start another project in an already crowded space instead of contributing to either of those projects? They are both open source and much further along in development . . .