1993-11-04 - message depots, packet routing?

Header Data

From: henry strickland <strick@osc.versant.com>
To: tcmay@netcom.com (Timothy C. May)
Message Hash: 610a79c926d06eef83ec803cc9531896ca34a014d4db4570bb4f40fa4c417b97
Message ID: <9311040605.AA00344@osc.versant.com>
Reply To: <9311040418.AA21327@netcom5.netcom.com>
UTC Datetime: 1993-11-04 06:07:34 UTC
Raw Date: Wed, 3 Nov 93 22:07:34 PST

Raw message

From: henry strickland <strick@osc.versant.com>
Date: Wed, 3 Nov 93 22:07:34 PST
To: tcmay@netcom.com (Timothy C. May)
Subject: message depots, packet routing?
In-Reply-To: <9311040418.AA21327@netcom5.netcom.com>
Message-ID: <9311040605.AA00344@osc.versant.com>
MIME-Version: 1.0
Content-Type: text/plain


# Jim goes on to describe his ideas for a "message depot" system, which
# bears close resemblance to Chaum's mixes, the basis for our existing
# encrypted remailers, and Myron Cuperman's "pool" idea, first deployed
# about a year ago. 

If these papers address how to do naming/routing services in DCNets,
I'd like to get references/copies.

The idea of using well known names and well known hierarchies and
fairly static connectivity with long TTLs (like DNS does) in order to
get addressing and routing information does not seem as desirable in a
DCNet.

Sometimes it seems better to have static topology: if a couple of nodes
I trust are in my dining ring and each ring connected to mine, I feel
fairly confident doing business.  I can take the time to get the right
people around me.  But static topologies allow more time for third
parties to form alliances and collude.

So perhaps every few seconds we should all get up, run around the room,
grab hands with different partners, and start new rings.  But then you
don't have time to check out the reputations of your new neighbors.

I can imagine a world of dining cryptographers in which 95% of the
participants all work for the same highly-funded branch of the
government and are in collusion ...

					paranoid, strick






Thread