[tahoe-dev] Tahoe-LAFS Weekly #3.0.1

[Zooko O'Whielacronx]

Hi folks. I took the liberty of repairing a cut-and-paste error in
Patrick's TWN issue 3 and I updated the formatting a bit, improved the
targets of a couple of hyperlinks, and added a footer saying where to
subscribe and where to find it on the web. Also, for reasons unknown
Patrick's emails to tahoe-dev have silently disappeared rather than
being sent to all tahoe-dev subscribers, so I am resending this newly
updated TWN issue 3.0.1 to tahoe-lafs-weekly-news and to tahoe-dev.

Regards,

Zooko

============================================
 Tahoe-LAFS Weekly News, issue number 3.0.1
============================================

*June 17, 2011*

Welcome to the Tahoe-LAFS Weekly News (TWN) brought to you by Patrick
McDonald, scribe and Zooko Wilcox-O'Hearn.  Tahoe-LAFS_ is a secure,
distributed storage system.

.. _Tahoe-LAFS: http://tahoe-lafs.org
.. _here: http://tahoe-lafs.org/~zooko/TWN3.html
.. _`mailing list`:
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news

Announcements and News
======================

The First International Tahoe Summit is coming up soon.  It starts the
27th of June.  Below is the schedule for the Summit:

* Monday meet the developers, etc. ask questions, invite Noisebridgers
* Tuesday for all day deep dive on design with Brian
* Wed, Thu work on what we got excited about on Tuesday
* Brian either cancel Movie Night or we all go to Movie Night

Nathan announced the Summit Grid Creation Party will be held at
Noisebridge during the Summit.  More details regarding the party can be
found on the `Summit wiki page`_.

Kevan made continued progress with MDMF.  In particular, he made progess
exposing MDMF dirs in the web API.  The web user interface (WUI) and
the CLI are next.

.. _Summit wiki page: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/Summit


Interview with the Developers
=============================

This is quickly becoming my favorite section to write for the TWN.
While lurking in #tahoe-lafs is a great way to learn a good deal
about all assortments of topics, these interviews with the devs
have taught me all kinds of things about the code which is Tahoe, but
also about the people, ideas and the motivations behind it.  I hope
these interviews help make you as passionate about the project as it
has made me.

This week it was my pleasure to interview Peter Secor.  Peter is the
fomer President and CEO of Allmydata, Inc. and is the volunteer director
for Tahoe-LAFS.  Peter is currently working repairing the old prodcution
grid from allmydata.com and later moving the grid to S3.  If you are
interested in helping to repair the grid, please contact Peter.

*Patrick: Give me a little introduction about yourself, tell me a bit
about who you are.*

Peter: UC Berkeley undergraduate degree in applied mathematics with
lots of computer science classes, worked for a bit in hardware/software
integration, grad school at NYU in applied math, dropped out to help
start up a network management software company, sold that, helped
start Allmydata to provide secure storage to consumers and enterprises.
I've lived in California, New York, Paris, Brussels.

*Patrick: Wow, that's pretty impressive.  So how did you come to
develop for Tahoe-LAFS?*

Peter: I was at Allmydata and we made the decision to develop the core
software as an open source project.  We went to Lake Tahoe for an
off-site to design the next generation distributed, encrypted storage
system.  Thus Tahoe was born.  Zooko and Warner were there along with a
few other people.

*Patrick: Being one of the founders of Tahoe, what is your favorite
memory of the project?*

Peter: My favorite memory so far, hmm … thinking.  Ah, I know, my
favorite memories are of the hack-parties we threw at the Allmydata
offices.  We used to throw hack parties every time Zooko came out
to the Bay Area.  Allmydata would buy food and drinks, and we'd invite
people over for a small presentation on something interesting, and
then try to solve some problems.

*Patrick: Sounds like a good deal of fun.*

Peter: Yes, and we also fixed a lot of bugs or found a
vulnerability.

*Patrick: So the next big feature is MDMF due in 1.9.0. What feature
or features would you like to see in upcoming versions?*

Peter: I would like to see the newly open-sourced javascript UI
cleaned up so that it can work by being served up by a grid.  It would
be a great example of an unhosted app, and very useful for managing
files on the grid.  I had it mostly working that way a couple years ago,
but there has been bit-rot.

*Patrick: That is webdrive, correct?*

Peter: Correct.

*Patrick: Any words of wisdom for developers looking to join the Tahoe team?*

Peter: It's a good way to learn about Python, crypto, capability
models, or all of them at the same time!

*Patrick: Where do you see Tahoe headed in the future?  One year from
now, what is new in Tahoe?*

Peter: There are a couple operational things and a couple
functional things.  I'm looking forward to the MDMF on the functional
side, and a year from now I'd like to see some sort of accounting
built-in.  On the operational side, I'd like to have the website and
build master no longer dependent upon a single box in my garage and
migrated to virtual infrastructure.  I'd also like to see the foundation
get more funding support from outside sources, so that's something I'll
take on.

*Patrick: As the volunteer director, what efforts can you talk which
looking to raise funds for Tahoe?*

Peter: So, in order to raise funds, I'm talking to a few larger
companies (like Google, Adobe, etc) and also to a few other smaller,
niche companies that are interested in this area.  We've been
sponsored by Google Summer of Code a couple times, but I'd like to get
something more permanent.

*Patrick: How do you like working the "suit" side of the project as
opposed to the coder portion?*

Peter: I'm not a great coder, more of an integrator/prototyper,
so working the funding side is fine for me if it's a good cause.  I
think Tahoe-LAFS is important in a few ways, one of which is being able
to provide a solution that allows you to store files across corporate
infrastructures without having to divulge the content.  That gives a lot
of power to the end user as they can continue to own their data and
privacy.

*Patrick: Thank you very much for your time.  This has been a
fantastic interview.*

Peter: Adios

Bug of the week
===============

In a bit of shameless self promotion, the bug of the week is 1416_.
This bug covers the TWN template.  Please do not just think of it as
template bug.  Please provide information on things you would like to
see, things you would like to see go.  Use it as a forum to provide us
with much needed feedback.  Help me, help you.

In all seriousness, the ticket of the week is 796_, write-only backup
caps.  Below is a direct quote from Zooko on why this ticket received
his nomination.

    The reason that I'm thinking of this is Bitcoin. I'm pretty
    excited about Bitcoin, and I read the sad story of a Bitcoin user
    whose value was stored on his computer in his wallet.dat file, and
    someone stole that file and transferred all of his Bitcoins to
    themselves. At current market rates, that was USD 500,000 worth!
    http://forum.bitcoin.org/index.php?topic=16457.0

    Now if you use symmetric encryption on your wallet.dat file then
    this does *not* protect you from malware which is running on your
    computer. Such malware can do whatever you can do, so if you can
    symmetrically encrypt and decrypt your wallet (in order to, for
    example, store more money in a symmetrically encrypted wallet)
    then that allows the attacker to do the same and steal all your
    money. It is like a lockbox that you have to open to put more cash
    in. But if you open it, the attacker can steal everything from
    inside it. On the other hand, public key encryption does not have
    the same property. You can encrypt your ⓑ without having, on that
    same computer, the ability to decrypt it, because your private key
    which is necessary for decryption is stored somewhere else and you
    access it rarely and carefully. This is more like a "piggy
    bank". A very strong piggy bank. How about: it is like a
    piggy-bank-shaped safe that has a little slot on top into which
    you can drop coins, but which cannot be opened without the
    key/combination.

    Some people currently protect their Bitcoin wallet by encrypting
    it with gpg and then backing up the encrypted copy to a remote
    site. This accomplishes the "piggy bank safe" scenario. Perfect!
    Except that most people don't do it, because they don't know how
    to use gpg.

    The Bitcoin developers are apparently working on adding symmetric
    encryption to the official client. That would be the lockbox
    scenario.  In my opinion this is near-useless and may actually
    harm people by giving them a false sense of security.

    So, it would be cool, not only for Bitcoin wallets but also for
    all other sorts of backups, if you had a "write-only capability",
    which implements public key encryption just like the GPG scenario
    above, but integrated into your Tahoe-LAFS filesystem and your
    automated Tahoe-LAFS-based backups. This is the subject of 796_."

.. _1416: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1416
.. _796: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/796

----

*The Tahoe-LAFS Weekly News is published once a week by The Tahoe-LAFS
Foundation. Scribe: Patrick Marlowe McDonald, Editor: Zooko
Wilcox-O'Hearn. To view on the web: the* `wiki page`_ *. To subscribe
via email: the* `mailing list`_ *.*

.. _`wiki page`: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/TahoeLAFSWeeklyNews
.. _`mailing list`:
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news