id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
959	tahoe-lafs objects	warner	nobody	"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..
"	enhancement	new	major		unknown	1.6.0		objects validation backward-compatibility forward-compatibility revocation	jeremy@… zooko