Live data from Hacker News

Upspin – Another option for file sharing

security.googleblog.com

31–40 of 170 posts

Re: Upspin – Another option for file sharing

#31
post #29

I think it is a brilliant idea to merge file paths with email addresses. In hindsight it feels like a logical next step from services such as Dropbox, where everything is about sharing files. You share a file and the other person gets sent an email notification that you've shared that file with them. It's great to see that they try to think outside the box and actually innovate on something that the Dropbox engineers…

Now when I think about it, Dropbox could still beat them to market by implementing and marketing this type of file addressing with their existing userbase.

Re: Upspin – Another option for file sharing

#32

Does anyone have more context to compare this to Camlistore, which is made by another member of the Go team?

Hi, Camlistore author here.

Andrew Gerrand worked with me on Camlistore too and is one of the Upspin authors.

The main difference I see is that Camlistore can model POSIX filesystems for backup and FUSE, but that's not its preferred view of the world. It is perfectly happy modeling a tweet or a "like" on its own, without any name in the world.

Upspin's data model is very much a traditional filesystem.

Also, upspin cared about the interop between different users from day 1 with keyservers etc, whereas for Camlistore that was not the primary design criteria. (We're only starting to work on that now in Camlistore).

But there is some similarity for sure, and Andrew knows both.

Re: Upspin – Another option for file sharing

#33
post #8

Sounds a little like IPFS: a global file system based on end-to-end cryptographically verified files distributed through untrusted nodes. Anyone want to compare the two?

From my early reading, this isn't quite as distributed as it relies on a directory server and email for identification.

Re: Upspin – Another option for file sharing

#35

> Our target audience is personal users, families, or groups of friends. Although Upspin might have application in enterprise environments, we think that focusing on the consumer case enables easy-to-understand and easy-to-use sharing. This definitely does not look "easy to use" unless the target audience of families only includes families where all have technical backgrounds. If I gave anyone in my family that list…

> There is a reason Dropbox does so well, its simple and doesn't require you do any manual fiddling

Cue someone linking to that that HN chain of messages about how Dropbox just won't work.

Re: Upspin – Another option for file sharing

#36

> Our target audience is personal users, families, or groups of friends. Although Upspin might have application in enterprise environments, we think that focusing on the consumer case enables easy-to-understand and easy-to-use sharing. This definitely does not look "easy to use" unless the target audience of families only includes families where all have technical backgrounds. If I gave anyone in my family that list…

In case it's not clear, this project is in its very early stage of development. There's a ton of work to do to get it into the hands of non-technical users.

From the readme: "Upspin has rough edges, and is not yet suitable for non-technical users."

Re: Upspin – Another option for file sharing

#37

I noted the disclaimer: "Upspin is not an official Google product". Yet it is announced on the Google Blog? Is it a separate "skunk works" team effort? Also, I note that they can set access levels based on email addresses, but I am unsure how that would work? Would those emails have to be linked to a Google account so that Upspin could check the currently logged in Google account to allow/disallow access to the files…

Kudos to you for asking this question. I was under the same impression that it was an official Google product but the repos didn't show any sign of this.

Re: Upspin – Another option for file sharing

#38

Does anyone have more context to compare this to Camlistore, which is made by another member of the Go team?

Hi, Camlistore author here. Andrew Gerrand worked with me on Camlistore too and is one of the Upspin authors. The main difference I see is that Camlistore can model POSIX filesystems for backup and FUSE, but that's not its preferred view of the world. It is perfectly happy modeling a tweet or a "like" on its own, without any name in the world. Upspin's data model is very much a traditional filesystem. Also, upspin ca…

This is pretty much correct. Upspin is way more filesystem-like than Camlistore, but I would emphasize Upspin's single global name space, rather than the filesystem-ness.

I think both Camlistore and Upspin have promising models.

Re: Upspin – Another option for file sharing

#39
post #21

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 . . .

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…

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)

Re: Upspin – Another option for file sharing

#40
post #21

Earlier quoted context omitted.

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…

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! :-)
Post reply on HN