"tahoe objects" concept

[warner]

When Zooko and I did a run-through of our upcoming RSA talk at the "friam" captalk meeting (12-feb-2010), Carl Hewitt asked the question "what would it take to turn this Tahoe file/directory graph into a graph of objects?". We generally understood "objects" to mean "bundle of state and behavior", like in object-oriented programming, whereas Tahoe's current file/directory objects are just inert state (with any behavior coming from the Tahoe client node that's processing it)..

This question prompted a lot of deep thinking around the table. There is a very juicy idea lurking in this, but we all metaphorically went off to separate corners to meditate on it.

Norm Hardy expressed his subsequent thoughts here: ​http://cap-lore.com/BigStore/Tahoe.html .

Zooko, when asked a day later on IRC, mentioned these:

1. we should make tahoe dirs extensible as suggested by someone
2. we should have a meeting of the minds with friam especially Norm to understand how "opaque object" stuff can be implemented just by making the gateway be the security (and availability ?) domain for your opaque object.

The idea that came to me (Brian) was:

• 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
• Some subset of these three things might be mutable, or maybe they'd all be immutable. Some filecap points to this collection.
• when a Tahoe client node loads this object, it runs the code and gives it access to:
  • the serialized state
  • the objects referenced by the childcaps (but not the caps themselves)
• the object receives any webapi request messages aimed at its filecap, processes those requests itself, then can update its state and/or return a response

Much of the post-Carl's-question discussion was about how to implement an "opaque boundary", which I interpreted to mean hiding the childcaps from the confined code that gets run. The code would be able to reference childcap[0] and send it messages, but it wouldn't be allowed to know the actual childcap string (thus helping the child maintain its own privacy).

I'm not sure where to go with these ideas, but they smell powerful. One direction is a forwards-compatibility thing: with a sufficiently general runtime environment for the bundled code, it could be used to implement dirnodes, add-only collections, revocable forwarders, all sorts of stuff that we haven't invented yet. Those fancy things could work on Tahoe clients that were written before the fancy thing was invented because they'd be implemented by portable code that would come along with the object being stored.

Our current dirnode actions (get child, add child, rename, list, delete) could probably be implemented this way (with some additional layer to hide new childcaps from the embedded code, maybe an extra webapi service which adds childcaps to the C-list and only informs the code about the new index).

This whole thing falls into the category of "mobile code", except that instead of a behavior-laden object moving directly from one machine to another, it's being stored in the grid and waking up again later (in one or many places). These objects would have control over their internal state (subject to the behavior of any client node that was allowed to host one of them). Isolation between these objects would be provided by the client nodes.

Something to brainstorm about, at any rate..