Live data from Hacker News

Upspin – Another option for file sharing

security.googleblog.com

101–110 of 170 posts

Re: Upspin – Another option for file sharing

#101
post #78

If enneff is still listening... How many files per directory has this been tested on? I work on a very similar system with similar goals (global file namespace which will return a list of physical file locations and a collection of software based on that), but for scientific data and we've been trying to scale to millions of files per directory. It'd be great to have a baseline.

> How many files per directory has this been tested on?

Not a massive number. The current DirServer implementation will likely run into problems once the corpus reaches a certain size. But there can be more than one DirServer implementation, as long as it satisfies the interface. (https://godoc.org/upspin.io/upspin/#DirServer)

Re: Upspin – Another option for file sharing

#103
post #60

> If one wants to post a Facebook picture on one’s Twitter feed, one does that by downloading the data from Facebook and then uploading it to Twitter. Shouldn’t it be possible to have the image flow directly from Facebook to Twitter? How does my upspin file "ann@example.com/pub/hello.jpg" solve the problem here? I would have a single source for my image to share but still no way to describe an image hosted by FB as a…

I remember when OAuth was first announced, and the use case was basically this - although this was before social networks became unanimous so it was more like sharing your Flickr photos with a photo printing site. It was a nice idea 10 years ago before everyone built their walls. To describe the content, the idea was everyone would use microformats: http://microformats.org/wiki/hmedia

There's another interesting use-case: OAuth is in its extensions (OpenID Connect & XACML) can be used to create an attributes-based access control system (ABAC) (as distinct from an identity-based or roles-based one). The benefits of such a system are:

- It can be privacy preserving. Say you want to buy booze from an online bottle shop. In real life, you'd usually flash your ID to meet the over 18/21 legal requirement. But by doing this you're leaking a tonne of unnecessary information (your name, your address, even your date of birth). One implementation of an ABAC might be that you prove your identity to a mutually trusted third-party, who than asserts to the bottle shop that your attribute of 'over18' == True (this is a rough description of OpenID Connect). So the only thing the bottle shop learns about you is the only thing it needs to legally know.

- Flexibility. Say you're unemployed and receive welfare from the government. Under a roles-based system, they'd attach a role to your identity along the lines of 'is entitled to receive welfare'. However, if any aspect of government policy changes (e.g. an additional requirement that you have to be over 6 feet tall), they would have to audit each account and update the roles. Under an ABAC, they'd simply update the ABAC policy, and access control decisions would be made according to the new policy (assessed against your asserted attributes). It also means that access to new types of resources don't necessarily require new roles to be added to the system: it might already be covered by existing attributes within the system (i.e. attributes can be recombined in different ways to allow very finely grained access control without the overhead of maintaining an ever-growing list of roles).

Re: Upspin – Another option for file sharing

#104
Hmm. Most are focusing (understandably) on the mechanics of using Upspin for different use-cases.

To me, the more interesting aspect is that the server has zero knowledge of the contents of the file, which makes it more comparable to SpiderOak One: https://spideroak.com/manual/send-files-to-others

Re: Upspin – Another option for file sharing

#105
> The full path might be ann+camera@example.com/video.jpg, with the idea that every read of the file retrieves the most recent frame.

Curious how this would work implementation-wise. Since the DirServer knows the file size (or at least has block descriptors), how would a custom StoreServer for the camera send back a dynamic-sized block? Would you define one block in the DirServer with a max size and allow the StoreServer to respond with a frame of any size below that max? Does the client validate the block sizes equate between the DirServer and StoreServer? Would the DirServer have to be "in on" the camera implementation alongside StoreServer for any of this to work?

Re: Upspin – Another option for file sharing

#106
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…

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?

Re: Upspin – Another option for file sharing

#107

> The full path might be ann+camera@example.com/video.jpg, with the idea that every read of the file retrieves the most recent frame. Curious how this would work implementation-wise. Since the DirServer knows the file size (or at least has block descriptors), how would a custom StoreServer for the camera send back a dynamic-sized block? Would you define one block in the DirServer with a max size and allow the StoreSe…

Yes, I think it would require a custom directory server as well (as do other proposed features in the intro document), but at least for special addresses like this that shouldn't be much of an issue

Re: Upspin – Another option for file sharing

#108
post #97
post #94

> Other than occasional workarounds using a URL, information given to these services becomes accessible only through those services. If one wants to post a Facebook picture on one’s Twitter feed, one does that by downloading the data from Facebook and then uploading it to Twitter. Shouldn’t it be possible to have the image flow directly from Facebook to Twitter? I'm not sure I understand the problem with URLs. "Copy…

The share link is usually an HTML page, rather than an image. Either the user needs to figure out the image URL or the service needs to implement individual decoder for every type of share link.

Exactly. Upspin seems like the absolute golden ideal of file sharing, at least to me. Even as a kid I remember wishing I could do something as easy as share a link to "C:\picture.jpg" and just have the person I sent it to be able to view it. Right now, I can get close with Dropbox's "copy sharable link", but I am definitely looking forward to an even better user experience, either via IPFS or Upspin.

Re: Upspin – Another option for file sharing

#109

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

It seems like they're currently designing the APIs which, once solidified, can be used to make a user friendly service. The foundation, as described, isn't easy for customers. But it is easy for developers and engineers!

And once this framework/API work is complete, people will be able to use this to create customer-friendly solutions.

Re: Upspin – Another option for file sharing

#110
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…

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.

Post reply on HN