Frothing remailers - an immodest proposal

Now, the question of implementing remailer advertising. If there is an
existing internet protocol for advertising entities with sufficiently
low latency, I am not aware of it (my background is in Novell and OS/2,
so I'll happily be corrected!) DNS is the closest model to what I want,
but is excessively tied up in bureaucracy and has horrific propagation
times. Thus, we will have to roll our own.
I can think of two reasonable solutions to this problem. The first is a
central authority model: there exist well known servers that each
remailer has to report into when starting up and shutting down. This
model has obvious benefits (ease of use and implementation, minimal
bandwidth usage) and obvious drawbacks (a single point of failure, or at
best very few, distinctly against the cypherpunk philosophy, requires
high-bandwidth, stable servers (read expensive)).
The second solution involves a broadcast model; each remailer
periodically broadcasts its presence to the entire net (say every T
minutes). Any process wanting a full list of all remailers simply has to
monitor the broadcast channel for T minutes to get at least a good
approximation. The problem here is one of delay (to locate a remailer, I
might have to wait T minutes) and bandwidth choking. Obviously, spamming
the entire internet with UDP packets advertising remailers would earn us
no friends (I'm not even sure that it's technically feasible). What we
need is a net of machines to carry the broadcast messages with numerous
well known access points.
By happy coincidence, there exists just such a network (actually,
several of them) that we can subvert for our twisted purposes. It's
called IRC. We can create a dedicated channel that carries the remailer
broadcast messages (to be honest, I have no real idea how to do this, but
one of the wonderHackers out there surely does? otherwise I might
actually be forced to read the RFCs (oh horror!)). I doubt that any
remailer operator will have trouble finding an IRC host to attach to in
order to monitor the broadcasts.

This is obviously a stopgap solution, but provides a method for
jumpstarting the froth without requiring a froth to advertise the froth.
With regard to the bandwidth concerns, I can't imagine that less
than a hundred remailers generating <1K messages every few minutes
(about ten minutes feels like a good value for T) can bring IRC to its
knees. When we get more than a hundred or so remailers up, we'll worry
about bandwidth!

And to the inherent latency problem of the broadcast model, the easiest
solution is to have well known servers cache the advertising information
for immediate access. Not too coincidentally, these caching servers look
a lot like the central point of authority servers in the first solution.
Thus, we can have both the convenience of a central authority model with
the dependable broadcast model to fall back on if it becomes necessary.
Unsolved problem, by the way: it would obviously be nice to have
human-readable names for remailers (the PGP key becomes the true unique
identifier, but I'd much rather pick "Soda remailer" from a list than
four lines of armored ASCII). How can we guarantee unique names and/or
prevent problems resulting from collisions?
Obviously, this process hasn't reached more than the pipe-dream stage
yet. I am very interested in comments and proposals before I start
trying to create some trial implementations. Be gentle, though - it's my
first time.
--
Kevin

: From kevin@elvis.wicat.com

Without quoting the entire message, I think I better solution, in terms of
ease to implement as well as conserving bandwidth would be to have a
sophisticated remailer script-language.

For instance, the script language could tell the remailer to check if a
site is on-line (perhaps within certain GMT hours or dates) and use the
next site if not available, or to randomly choose from a list of sites
the active ones, etc.

Maybe even have it work with a data haven? Mail the message to a data haven
and send another message to a remailer chain to pull the message from the
data haven and post the data (not flaws in this: don't want remailers getting
files from people's accounts and posting them to usenet etc.).

Seems like this is a "safer" solution that is more flexible then broadcasting
which remailers are active. Also allows for future add-ons like delays,
file-splitting, etc.