To me, one of the problems Upspin tries to solve is how to establish authorization (a.k.a ACL, entitlement, etc.) in a decentralized way, once authentication is established. As far as I can tell the only use of "key" server is to verify the user's identity; but perhaps it's also used to decrypt "directory" server content.

Regarding 9P, I've not studied Upspin source code yet, but conceptually it would be like separating the hierarchy traversal parts of the protocol (e.g. clone, walk, etc) from the content access part (open/read/write) and replacing them with RPC with directory and store servers. Conventionally, the content on store server is encrypted, so the user doesn't have to trust the store server.

The problem I see is the user needs publicly accessible directory and store servers if he/she wants to share content. I think having a way of providing a namespace to a trusted server without having to figure out how to setup secure servers is required for average users.

By contrast, 9PCloud's approach is to be the namespace multiplexer and allow namespace sharing with authenticated users. Because all connections are initiated from the user end, 9P exporter and importer are behind firewalls and the content resides on the user's device.

On Thu, Feb 23, 2017 at 12:27 AM Bakul Shah <bakul@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 (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 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.