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

[tahoe-lafs]

#959: tahoe-lafs objects
-------------------------+--------------------------------------------------
 Reporter:  warner       |           Owner:  nobody
     Type:  enhancement  |          Status:  new   
 Priority:  major        |       Milestone:  2.0.0 
Component:  unknown      |         Version:  1.6.0 
 Keywords:               |   Launchpad_bug:        
-------------------------+--------------------------------------------------

Comment(by jsgf):

 I was thinking of a simpler scheme to distribute code around a grid:
 validation of writes/updates to enforce the syntax of files (such as
 directories).  The code would be stateless, and have the only side-effect
 of either accepting or rejecting an update.

 At present this would be useful for: 1) enforcing the syntax of an
 immutable file, and 2) enforcing correctness updates to immutable files.
 It would be even more useful with append-only files, since you could
 enforce new updates to be consistent with what's already present.

 Ideally it would be run on each storage server as part of the decision to
 accept/reject an incoming share, but this has a couple of obvious
 problems: a) the server doesn't gave keys, so can't decrypt incoming
 content; b) even if it did, erasure encoding means that a given share
 can't be decrypted in isolation anyway; c) and even then, the validator
 could only be sure of inspecting a single segment.  (But if you're
 fetching other shares of a given segment, then fetching other segments may
 not be a problem.)

 It could also be run on a local gateway, to validate outgoing and incoming
 changes, which simplifies the problem.  But this wouldn't prevent illegal
 updates from ill-behaved clients to immutable files.



 A thought on how these validation functions might be implemented.  The
 obvious would be to have something like:

     if (valid(file)) then accept() else reject();

 but perhaps it might be more interesting to do something like include the
 output of the validator in the file hash, so the validity is more deeply
 baked in:

      H = hash(file + validity(file))

 And a merkle tree would allow you to validate/express validity for parts
 of the file rather than the whole thing (which is especially interesting
 if the leaves of the tree correlate to synatactic boundaries of the file
 rather than just splitting at particular byte boundaries).

 But I don't know if that would let you express all the interesting things
 one would want to express.

 There's some overlap with Schneier's idea of Clueless Agents:
 http://www.schneier.com/paper-clueless-agents.html

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