From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <2A42D5A6-C7C1-4E40-A9B0-4E8F6591E079@bitblocks.com> References: <2A42D5A6-C7C1-4E40-A9B0-4E8F6591E079@bitblocks.com> From: Ryan Gonzalez Date: Thu, 23 Feb 2017 09:59:13 -0600 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11404842d27365054934b120 Subject: Re: [9fans] Upspin - a respin of 9p? Topicbox-Message-UUID: b51d1da6-ead9-11e9-9d60-3106f5b1d025 --001a11404842d27365054934b120 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable https://upspin.googlesource.com/upspin/ *looks at mascot* Eh, Glenda's cuter. This looks like a sleep-deprived crack-addicted mobster chick. -- Ryan (=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3) Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else http://refi64.com On Feb 23, 2017 2:30 AM, "Bakul Shah" 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 > =E2=80=9Cdownload=E2=80=9D and =E2=80=9Cupload=E2=80=9D, and accessed fro= m 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 globa= l > user id (user@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 t= he > 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 als= o > checks if the requester is allowed access and presumably gives her a publ= ic > 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 famil= y > (ala Dropbox?) but the only thing I see that would be hard to scale is th= e > fact a dir tree has an ACL. A dir server may also end up being a bottlene= ck. > > 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). O= r > 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. > --001a11404842d27365054934b120 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
https://upspin.googlesource.com/upspin/

*looks at mascot*

Eh, Glenda's cuter. This looks like a sleep-deprived crack-ad= dicted mobster chick.

--
Ryan (=E3=83=A9=E3=82=A4=E3=82=A2=E3=83=B3)<= br>Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >>= everyone else
http://refi64.com
=

On Feb 23, 2017 2:30 AM, "Bakul Shah" <bakul@bitblocks.com> wrote:
<= div>https:/= /upspin.io/doc/overview.md

Upspin provides a global name s= pace to name all your files. Given an Upspin name, a file can be shared sec= urely, copied efficiently without =E2=80=9Cdownload=E2=80=9D and =E2=80=9Cu= pload=E2=80=9D, 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 o= f things. A path has a global user id (user@foo.com) as a root, which is looked up in (what I wo= uld 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 wh= ere 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 publi= c 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 s= um -- presumably the directory server doesn't care.

The overview talks about the design being geared toward friends and f= amily (ala Dropbox?) but the only thing I see that would be hard to scale i= s the fact a dir tree has an ACL. A dir server may also end up being a bott= leneck.

User data can be protected by the ow= ner but the dir server needs to be able to read metadata such as ACL, data = location etc.

Not sure if the design allows for dy= namic 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 wo= ndering if something the CPU command can be implemented. May be there is a = protocol to attach your own dir server.

Renames ar= e probably not handled to avoid atomicity (just speculating). Or may depend= on a dir server.=C2=A0

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 pref= erred a capability scheme instead of ACLs -- need to think more about this.=
--001a11404842d27365054934b120--