[tahoe-dev] CodeCon proposal (proposal: tahoe-lafs)

[zooko]

Folks:

Here is the proposal I sent to present Tahoe at CodeCon.  I hope we  
get in!  CodeCon is great fun.

You might be especially interested in the "Future Plans" section at  
the end.

Regards,

Zooko

Begin forwarded message:

> From: zooko <zooko at zooko.com>
> Date: February 15, 2009 23:25:47 PM MST
> To: submissions-2009 at codecon.org
> Cc: Brian Warner <warner at lothar.com>
> Subject: proposal: tahoe-lafs
>
> Project name: Tahoe, the Least-Authority Filesystem
> Track: code
> url of home page: http://allmydata.org
> tagline: a secure, decentralized, fault-tolerant storage network
> presenter: Zooko Wilcox-O'Hearn, http://zooko.com
> alternate/backup/co- presenter: Brian Warner, http://lothar.com
>
> project history: In 2006 I got to start fresh on inventing a  
> secure, decentralized storage network, after the failure of Mojo  
> Nation (for which I was partially responsible), the failure of Mnet  
> (for which I was primarily responsible), the observed failures of  
> Freenet, and the ongoing failure of a proprietary commercial backup  
> system written by allmydata.com (for which I was partially  
> responsible), not to mention a few other failures that I also tried  
> to learn from.  I tried to learn from the success of BitTorrent by  
> starting fresh and limiting the scope.  Also, I was blessed with a  
> supportive company and the kick-ass engineering skills of Brian  
> Warner, and I finally got a secure, decentralized storage network  
> that didn't fail!  allmydata.com deployed Tahoe a year ago and  
> copied all of their customer data over to Tahoe from the old  
> proprietary system.  Open source hackers are building on it.  It  
> works!
>
> novelty: Tahoe is comparable to Freenet, OceanStore, and Mojo  
> Nation.  It avoids some of the trickier problems in this space by  
> limiting the scope: Tahoe assumes that the set of storage servers  
> is not too large or dynamic, and that there are enough servers that  
> are at least moderately reliable.  This means it doesn't even *try*  
> to solve the Very Hard Problem of sharing storage with millions of  
> anonymous strangers, but on the other hand it does a fine job of  
> sharing storage among a couple hundred moderately reliable servers,  
> such as a "friendnet" (home computers operated by your friends and  
> family) or the allmydata.com commercial grid.  On top of this pool  
> of moderately-reliable servers, Tahoe adds encryption for  
> confidentiality and integrity, erasure-coding for high reliability,  
> and capabilities for file-sharing.  The "Principle of Least  
> Authority" design means that the system relies on each component as  
> little as possible -- security properties such as confidentiality,  
> integrity, and access control are all guaranteed by the client on  
> its own behalf using cryptography instead of relying on the servers  
> to cooperate in providing those properties.  To get the reliability  
> properties that it wants the client *does* require the help of the  
> servers, but by the power of erasure coding, only a subset of the  
> servers need to perform only moderately well for the reliability  
> properties to hold.  Tahoe is the only open source project that I  
> know of which offers these sorts of properties in a practical  
> system that many people use every day.
>
> demo: I haven't thought this through all the way, but at several  
> hacker parties in the past we've had partiers install Tahoe on  
> their laptops and form a "temporary autonomous zone" storage system  
> on which to share music and movies.  When the laptops close up and  
> go home, the temporary autonomous zone is destroyed and all of the  
> files become unrecoverable (unless a quorum of the partiers were to  
> later reconvene and reconnect their laptops).  Maybe we could  
> figure out a way to have some such live audience participation in  
> the demo.  It has worked at parties with dozens of attendees, but  
> I'm not sure if it would fit into a CodeCon demo.  Failing that, I  
> can always demo the user-facing applications that run from Tahoe,  
> such as streaming movies and "gridapps", which are JavaScript  
> applets that are stored in Tahoe and executed in your web browser.   
> Maybe I could cook up some sort of demo involving suddenly and  
> violently destroying one of the storage servers and then  
> demonstrating that all the content is still available because of  
> the survival of the other ones.  Hey, that sounds like fun!  As you  
> can see, I don't have a precise plan yet.  Nor money to spend on a  
> sacrificial removable hard drive or two.  :-)
>
> slides: I have none prepared specifically for CodeCon yet.  Here is  
> the peer-reviewed short paper that I presented at the Storage  
> Security and Survivability Workshop -- http://allmydata.org/~zooko/ 
> lafs.pdf .  Here are the slides that I used at that presentation:  
> http://zooko.com/lafs/presentation/index.html .  At that  
> presentation I did actually load each of the slides on demand from  
> a live Tahoe grid so it was a demo as well as a presentation.
>
> future plans: 1.  Support more and more people building on top of  
> Tahoe, such as allmydata.com's backup business, and several open  
> source projects that are currently building on top of Tahoe.  I'm  
> especially interested in "gridapps", which might evolve into a  
> distributed computation platform that can be built with the world's  
> vast supply of web app development expertise.  "Gridapps" look  
> exactly like web apps, but all of their storage is in the  
> decentralized, secure tahoe grid, and they have access to the  
> convenient capability-based file-sharing API (over HTTP), so they  
> could do some interesting things.
>
> Future plan #2: fix the glaring deficiencies that we already know  
> about, plus all the new ones that will be revealed in the process  
> of Future plan #1.
>
> Future plan #3: document the file formats and protocols in  
> sufficient precision that others could write a compatible  
> implementation from the spec.
>
> Future plan #4: design better-performing and safer cryptographic  
> mechanisms and better-performing and more versatile filesystem  
> semantics.
>
>
> Thank you for organizing CodeCon!
>
> Regards,
>
> Zooko Wilcox-O'Hearn