https://upspin.googlesource.com/upspin/
*looks at mascot* Eh, Glenda's cuter. This looks like a sleep-deprived crack-addicted mobster chick. -- Ryan (ライアン) Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else http://refi64.com On Feb 23, 2017 2:30 AM, "Bakul Shah" <ba...@bitblocks.com> wrote: > https://upspin.io/doc/overview.md > > Upspin provides a global name space to name all your files. Given an > Upspin name, a file can be shared securely, copied efficiently without > “download” and “upload”, and accessed from anywhere that has a network > connection. > .... > Upspin can name information from any data service, not just traditional > files. > ---- > Initial impression: > > IMHO, its usefulness is integrating a bunch of things. A path has a global > user id (u...@foo.com) as a root, which is looked up in (what I would > call) a root server. From it you find the directory server which stores the > metadata for the remaining path. From this you find the data server where > the file or data source is actually located and an ID meaningful to the > server (like qid but can be a content sha1 sum). The directory server also > checks if the requester is allowed access and presumably gives her a public > key of the root user to be able to decrypt the data. > > Clearly, if the source is not an ordinary file, there can be no sha1 sum > -- presumably the directory server doesn't care. > > The overview talks about the design being geared toward friends and family > (ala Dropbox?) but the only thing I see that would be hard to scale is the > fact a dir tree has an ACL. A dir server may also end up being a bottleneck. > > User data can be protected by the owner but the dir server needs to be > able to read metadata such as ACL, data location etc. > > Not sure if the design allows for dynamic bind/mount. This would require a > more flexible dir server structure... (I haven't read the code so this is > pure speculation). But I'm wondering if something the CPU command can be > implemented. May be there is a protocol to attach your own dir server. > > Renames are probably not handled to avoid atomicity (just speculating). Or > may depend on a dir server. > > ACLs are for dir trees. From the syntax it looks like you can add more > access in a sub tree but not remove it. > > I'd have preferred a capability scheme instead of ACLs -- need to think > more about this. >
