Summary: A "C-list + blob" feature is a useful stepping-stone for both "live objects" and "arbitrary dag structures".
Note: As I write this, I haven't read all of the comments yet...
Responding to warner:
suppose we stored three things in a Tahoe file
- a numerically-indexed list of childcaps (the "C-list")
- an arbitrary chunk of serialized state
- a chunk of code written in some confineable language (E or secure javascript), or perhaps an immutable reference to some external code file, share between lots of objects
With only the first two of these bullets, the storage model becomes "arbitrary DAGs (Directed Acyclic Graphs)" instead of only "files or directories". This is an interesting direction, even outside of a "live object code" feature.
The C-list would have the same confidentiality properties as current directory references, except they are unassociated with a filename, but they have a unique index for a given version of the cap contents. (Thus verification and repair would work in a similar fashion, although I'm less certain about how updates are implemented.)
Simple "monolithic" directories (similar to SDMF directories) could be implemented on top of this "C-list + blob" format to promote "our own dog food" cuisine, which would help work out bugs and usage issues. This implementation would have a blob which links file names and other link metadata to the C-list.
It's easy to imagine other data structures: sets, queues, trees whose edge labels are not filenames, etc... (In fact, a queue could have an empty blob, if we trust the writer to maintain the C-list order "correctly". A set is even simpler and has an empty blob and the C-list order is ignored.)
Of course, those data structure examples don't address distributed consistency issues, so I don't mean to imply desirable properties such as append-only or "eventually consistent ordering" or the like. See #796 for a discussion of some of those features.
Consider also, these proposed distinct (abstract) webapi calls:
- get_raw(readcap) → C_list_and_blob_bytes
- get_blob(readcap) → blob_bytes
- get_clist(readcap) → C_list
Now, the blob could be html and javascript, so that a GET to the get_blob api will load that into a browser, and the javascript can then use the get_clist api to access references. Some pros/cons of this particular example:
- Pros:
- This is approaching a "live capabilities objects" feature.
- It keeps the layering fairly distinct - lafs doesn't know about "live object code" very much, outside of standard http+browser tech.
- Because the "C-list + blob" feature is a separate layer, this does not preclude other approaches to live objects, and it does not complicate other uses of "C-list + blob".
- Cons:
- This example is inefficient compared to a more direct implementation of "live objects".
- Example: a webapi which knows the blob is javascript with a special interface could inject the C-list into the script in a well defined convention prior to responding to an http request. Thus, there'd only be one http request/response. (This would not use the proposed API above.)
I haven't figured out yet how to quarantine the javascript to have object-capabilities-like access control, in this scheme. However that problem seems similar to object-capabilities-restriction for javascript in current lafs.
