[Mnet-devel] report from PET 2004: GNUnet, economics, and federated Mnets

[Zooko]

I'm at PET 2004.  I just met Christian Grothoff, inventor of GNUnet.  
He says that he estimates that GNUnet has approximately 100 nodes at 
most times!  Ooh!  And he just pointed me to libextractor [1].  It 
looks good!  I want to know what Myers (or nejucomo) thinks.  Also, he 
showed me GNUnet hostlists via HTTP, e.g. [2].  I tried to show him the 
Mnet v0.6 GUI, but it looks like my Mnet node here can't find any 
MetaTracker.  Fortunately, Christian got distracted by the conference 
and didn't notice.  (Ah -- Christian just read this paragraph over my 
shoulder and stated that he did notice.)

Christian currently exports the GNUnet API as a linkable C library, and 
he isn't interested in XML-RPC.  In the past someone ported GNUnet from 
C to Java, and the xnap team wrote a plugin to use the Java version of 
GNUnet.  However, that Java version is not as well-maintained and 
current as the C version of GNUnet.


Ross Anderson gave the opening talk, on the economics of the computer 
industry, of security, and of privacy.  It was an excellent talk.  
Prof. Anderson's research group includes George Danezis, whose recent 
paper on "Red vs. Blue" censorship resistance has been discussed on 
this list.

I'm increasingly interested in the notions that George Danezis has 
explored -- those of "private clubs" or of "federated clubs".  A 
"private club" Mnet would be one in which all nodes belong to the same 
club, e.g. the Grateful Dead Fan Club.  A "federated" Mnet would be one 
in which there are overlapping clubs.  For example, there may be the 
Grateful Dead Fan Club, the Creative Commons Licensed Music Fan Club, 
the Phish Fan Club, and the Creative Commons Licensed Content Fan Club, 
and a given node may belong to one or more of these.  So, the clubs 
overlap.

This is qualitatively the same as a "friendnet", which we have thought 
about a lot in the context of Mnet, but it is quantitatively different 
in that we assume that the network is clumpy.

This clumpiness makes a big difference to Mnet v0.7.  Consider if we 
used Mnet v0.7 in the "single global public network" way.  Okay, that's 
what we designed it for.  It will hopefully work in that context, as 
long as it can deal with node churn.  (And as long as we have a good 
solution for content tracking, and The Incentive Problem, and so on...)

Okay, now consider if we use Mnet in the "private club" way.  This 
should work even better.  There should be much lower churn, and the 
incentive problem is in some sense solved automatically -- the people 
are motivated to run servers because doing so is a contribution to 
their club.

Okay, now consider if we use Mnet in the "friendnet" a.k.a. FOAF way.  
This probably doesn't work, because when a publisher publishes a file, 
some of the blocks go to peers which are unknown to the downloader.  
How could we make sure that the downloader knows enough of the nodes 
that the publisher knew?  That question has stumped me until now.

Okay, now consider if we use Mnet in the "federated clubs" way.  This 
is just like the friendnet way, but maybe we can make some assumptions 
about the network topology.  For example, if Alice publishes a file, 
and Bob tries to download that file, then this means the mnet URI must 
have been transmitted from Alice to Bob (perhaps indirectly), and Bob 
and Alice must share some common interest.  If we also assume that the 
network topology is sufficiently clumpy, then we may feel confident 
that Bob will know enough of Alice's peers that he can download the 
file.

The part of this that is exciting to me is that it requires no deep 
changes to Mnet.  I think that the current Mnet v0.7 source code would 
already work fine for federated Mnets, by making MetaTrackers be 
specific to a given club.  Each MetaTracker would serve only a single 
club, and then a non-MetaTracker node could join multiple clubs by 
using multiple MetaTrackers.  (Note that a single club could be served 
by multiple MetaTrackers, while a single MetaTracker would serve only a 
single club.)

Regards,

Zooko

[1] http://www.ovmj.org/libextractor/
[2] http://www.ovmj.org/GNUnet/hosts/
     Note: this hostlist is the perspective of a single GNUnet node -- 
this list is limited to a maximum number of hosts which is bounded by 
its bandwidth.  Christian estimates that the total nodes in the GNUnet 
network is sometimes around 100.