[freehaven-dev] (FWD) [Mojonation-devel] Gossip system.

[Roger Dingledine <arma@mit.edu>]

An interesting post from the mojonation-devel list.

A lot of the notions in here sound familiar based on the discussions we
had about trust and metatrust servers.

Once we get this whole chapter thing out of the way (ha ha), I'm going
to give some thought to how we can improve the anonymity of mojonation
and maybe do away with the need for free haven.

Ten second summary of Roger's thinking: mojonation and freenet are the two
'best done' in their categories, and the rest of the systems out there
suck too much for various reasons. I hope to scrap free haven down the
road in favor of something else, if only i could figure out a way to work
the content-neutral policy into it ( <-- this means freenet won't cut it,
because i think it's quite fragile as it is).

Mojonation is a beautiful design. Once I get a free moment (probably
sometime in December), I plan to sit down and try to analyze it more
thoroughly.

--Roger

----- Forwarded message from Nefarious Junior Code Monkey <nathan@mad-scientist.com> -----

To: mojonation-devel@lists.sourceforge.net
From: Nefarious Junior Code Monkey <nathan@mad-scientist.com>
Subject: [Mojonation-devel] Gossip system.
Date: Thu, 12 Oct 2000 15:44:21 -0700

Hello.

I think we're discussing the gossip system today via voice/phone,
but I just thought I'd e-mail this to have it down on harddisk.

Yesterday Raph and someone named Harik (Dan somebody who submitted
a couple patches to fix bugs) were discussing name spaces and block
tracking distribution.

The idea they discuss for block tracking can also be applied to
meta tracking (and with anything that works with bit-maskeable
addressing/ID schemes) and supposedly scales well.

I'll try to describe it here, but I might miss some vital points
(or I might remember certain things wrong).

The idea is this: Broker A has a meta-tracking mask that is N bits
long.  It is in a class of other Brokers who also have meta-tracking
masks the same length.  (Some competing Brokers might have the exact
same mask.)  Every broker needs a list of all the meta-tracking
Broker's with a meta-tracking mask that is N bits long.  N is the 
smallest length of any Meta-Tracking Broker's ID mask.

We would run a boot-strapping server that could give new Broker's
this list, but they could also ask *any* other Broker for this list,
since all Broker's need and have them.  Also, people's lists may
vary to support competing MT's.  (How a given Broker's list changes
over time isn't clear to me.)

Here's how Broker B finds Broker C:
A) B checks her local top-level list (which she got from our boot
   strapping server or any other Broker) to find that Broker C's ID
   falls within Broker A's ID mask.  B sends a query to A, "What is
   C's contact info?"
B) Broker A either know's C's contact info, or knows another MT Broker 
   with a more specific ID mask (longer than N) which C's ID falls under.
B-1) In the first case A returns C's contact info.
     "Here's C's contact info: ..."
     Broker B is done.
B-2) In the second case, Broker D has an ID mask of length M where 
     M > N, and Broker A know's Broker D's contact info.  Also, C's
     ID falls under D's ID mask.  Broker A returns D's contact info.
     "D know's where C is.  D's contact info is: ..."
C) As you can see, we have a recursive situation where B repeats the
   query using D instead of A.  This repeats until B finds C.

Depending on the length of N, and the difference in length between M 
and N, and the difference between the even longer (more specific)
bitmasks under M, Metatrackers will have to store various amounts of
data.  N is more important than the more specific mask lengths because
every Broker needs a list that is 2^N long of contact info.

For some reason Raph estimated an N of 9, but maybe I misunderstood him.
That would be a billion contact info entries!  N of 3 sounds more reasonable
to me.

I don't see how this solves the "find Broker's who perform service Foo"
query though...

Whelp, just some ideas.  Thee who are interested should either ask Raph
for better details, or assign me the job of doing better research and
giving a more accurate report.  ;)

Nathan
_______________________________________________
Mojonation-devel mailing list
Mojonation-devel@lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/mojonation-devel

----- End forwarded message -----