[tahoe-dev] Google Summer of Code 2010 -- Ideas Needed!

Jeremy Fitzhardinge jeremy at goop.org
Fri Mar 12 14:44:35 PST 2010


On 03/12/2010 02:29 PM, Zooko Wilcox-O'Hearn wrote:
> On Friday, 2010-03-12, at 15:20 , Jeremy Fitzhardinge wrote:
>    
>> Not sure how they'd find out about each other; perhaps the
>> introducer could do it, but it might be interesting to build a DLM-
>> like thing on top of  a general chordish DHT.
>>      
> That might be related to #68 (implement distributed introduction,
> remove Introducer as a single point of failure) and #295 (distributed
> control of access to nodes).
>    

Yes, and yes.

>> Adding a DHT to Tahoe would be a worthy GSOC project in itself; has
>> it been mentioned?
>>      
> Well there is #869 (Allow Tahoe filesystem to be run over a different
> key-value-store / DHT implementation), but I guess that's not what
> you mean. What do you mean?
>    

I'm thinking in handwavy terms that a DHT would be a useful piece of 
infrastructure to operate in parallel with Tahoe, and as a something 
future Tahoe-related features could be built on.  I'm thinking that the 
DHT would be for ephemeral information which may be updated 
moment-to-moment, vs data stored on nodes with proper caps (but perhaps 
I'm making a distinction without a difference).

Off the top of my head:

    * distributed introducer is an excellent first step, which is
      probably justification on its own
    * automatic discovery of helpers
    * real-time grid-wide stats
    * facilitate node-to-node communication (for write coordination,
      messaging, etc)

Look at my hands go!

Would there be any value in (or even possible to) make use of an 
existing DHT (like the BT distributed trackers) to get more strength in 
numbers?

     J


More information about the tahoe-dev mailing list