[tahoe-dev] [tahoe-lafs] #959: "tahoe objects" concept

[tahoe-lafs]

#959: "tahoe objects" concept
-------------------------+--------------------------------------------------
 Reporter:  warner       |           Owner:  nobody   
     Type:  enhancement  |          Status:  new      
 Priority:  major        |       Milestone:  undecided
Component:  unknown      |         Version:  1.6.0    
 Keywords:               |   Launchpad_bug:           
-------------------------+--------------------------------------------------
 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..

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/959>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid