[tahoe-dev] what's the difference between Tahoe-LAFS and Freenet?

[Zooko O'Whielacronx]

Folks:

The topic has come up on the IRC channel and trac about "What's the
difference between Tahoe-LAFS and Freenet?". I will try to answer that
question here, but there are probably other important differences than
the ones I'm thinking of, so this answer shouldn't be treated as
definitive. If you have insight into this topic, please reply!

Also, of course, I know way more about Tahoe-LAFS than I do about
Freenet, and I'm biasing towards thinking that Tahoe-LAFS is the
greatest thing in the universe, so those are other reasons why this
answer shouldn't be taken as definitive.

First a bit of history-and-culture stuff. I was working on Mojo
Nation, in its secret pre-launch mode in early 2000, with Jim McCoy,
Doug Barnes, Greg Smith, and Bram Cohen, when I heard about the
announcement of this new thing called Freenet. The description I read
of it (I think it might have been Ian Clarke's master's thesis) was
surprisingly similar to what we had already designed and were
currently implementing for Mojo Nation. There were differences, too,
but on that day I realized that what we had in mind at Mojo Nation was
not solely a novel invention of our own, but was also a product of
"ideas being in the air" and of the economic and cultural context of
the time. I think we got the idea of secure distributed mutable files
mostly from Freenet (which is why the URI format for Tahoe-LAFS's
secure distributed mutable files has the string "SSK" in it, which is
what Freenet called their secure distributed mutable files).

Mojo Nation was the great+-grand-father of Tahoe-LAFS, so in a sense
Freenet and Tahoe-LAFS grew up together—we shared similar technical
and social values, and we occasionally met on IRC channels or at
conferences in real life to exchange design review and ideas. Over the
ensuing eleven years the Freenet hackers worked continuously on
improving Freenet while making the occasional major shift in design
strategy, most notably the addition of the so-called "Darknet"
strategy in roughly 2009 or so. Over the same time period the Mojo
Nation lineage went through a series of restarts and a changing lineup
of performers. Err, I mean of programmers. During this time, Bram
Cohen left Mojo Nation and invented BitTorrent. The goals of
BitTorrent can be seen as a subset of the goals of Mojo Nation. I
learned from the success of BitTorrent that it can help to limit the
scope of features you are trying to combine into one software project.

Tahoe-LAFS itself was born on the 4th restart (Mojo Nation, Mnet,
Allmydata "Mountain View", Tahoe-LAFS), with the addition of Brian
Warner as chief engineer, in, let's see...

http://tahoe-lafs.org/trac/tahoe-lafs/changeset/1/trunk

In October of 2006. Hey! We should have a 5th Birthday Party for
Tahoe-LAFS this October. :-)

Now for the technical part. The biggest architectural difference
between Tahoe-LAFS and Freenet is that Tahoe-LAFS makes no attempt to
let you discover and use random strangers as storage servers. This was
also the big difference between Tahoe-LAFS and its predecessors. When
we started the Tahoe-LAFS project, we decided to make a simplifying
assumption that you would use some mechanism outside of Tahoe-LAFS
itself to find a somewhat stable set of moderately reliable servers
that would agree to give you storage service.

Such mechanisms include paying a company to run those servers for you
(which was what allmydata.com offered), getting a few of your friends
to run storage servers for you, joining a club of people who share
Tahoe-LAFS storage service (such as our Volunteer Grids), etc.. In the
future we would like to add to the possible mechanisms—maybe you could
pay people in Bitcoin to run storage servers for you (#1408).

In any case, the thing that we rejected at that point was having your
Tahoe-LAFS client meet some previously unknown Tahoe-LAFS server over
some automated protocol and decide to entrust some of your ciphertext
to that server. We concluded that while we could use math in your
client to provide confidentiality, integrity, and access control
without requiring the server to provide those things, we could *not*
use math in your client to provide availability or longevity without
relying on the server to provide those things. (This was after we
tried repeatedly to do just that from about 1999 to about 2006,
without success.) Therefore, you have to do the legwork yourself of
finding highly available, long-lived servers.

That's the biggest architectural point of departure between Freenet
and Tahoe-LAFS. There are more.

Another big one is, as Gwern pointed out on the #1427, is that
Tahoe-LAFS makes no attempt to obscure the source or destination of
requests, but Freenet does attempt to do that. Again, this was a
deliberate decision on our part not to include this feature. Brian and
I both had some knowledge about anonymity systems like Chaumian mixes,
private information retrieval, and Dining Cryptographers, and we knew
that it would be very hard, if not impossible, to guarantee anonymity
against sophisticated attackers, and that trying to do that within the
scope of our storage protocol would greatly complicate it. This
architectural departure from Freenet has subsequently proved less
consequential than the first one, because people have subsequently
wrapped Tahoe-LAFS's storage protocol inside Tor and I2P, thus letting
those systems provide their anonymity/privacy protections while
Tahoe-LAFS provides its confidentiality, integrity, and access control
protections.

Another big architectural difference is that Tahoe-LAFS embraced the
Web from the beginning, with the webapi [1] as the standard
programmable interface and the WUI ("Web User Interface") one of the
supported user interfaces. This has paid off to some degree, since
other projects and local hacks can use the webapi to integrate with
Tahoe-LAFS, and it becomes very easy to use Tahoe-LAFS to host files
for public distribution, either by making the WUI itself publicly
visible or by putting a proxy such as nginx in front of it. On the
other hand, web browsers and web technologies like JavaScript have
historically been rife with security problems. One of the three
security problems that people have uncovered in Tahoe-LAFS over the
years [2] was due to the existence of the webapi. When I spoke with a
Freenet hacker at the Google Summer of Code Mentor Summit last year,
he was adamant that they would not endanger their users' safety by
helping them use web browsers to view and edit the data stored and
communicated through Freenet. I can't exactly disagree with him about
that—web technology is often insecure. But on the other hand it is
improving rapidly by necessity, and on the gripping hand, the Web is
what most people use. If we didn't integrate directly with the Web it
would make Tahoe-LAFS's secure storage properties less accessible to
the majority of users.

(Sometimes security experts reject Tahoe-LAFS as inherently insecure
when they learn about the Web integration. If I notice them doing that
then I try to point out that you can use Tahoe-LAFS without using a
web browser, thus avoiding most of the vulnerabilities. You can use
the CLI—the Tahoe-LAFS command line tool—or FUSE integration instead
of the WUI.)

There are many other differences, of course! They let old and unloved
content die to make room for fresher and more popular content; we stop
accepting new writes if the storage servers run out of space. They use
Java; we use Python. They have an awesome name; we have a terrible
name. And so on. We could probably learn even more from each other
than we already have.

Regards,

Zooko

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1408 # accounting using bitcoins
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1427 # Differences
between Freenet and Tahoe

[1] http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/frontends/webapi.rst
[2] http://tahoe-lafs.org/hacktahoelafs/