Eric:

Enough of this. I'd rather discuss lowering transaction costs. rjc comments on my list:

...

...

-- Finding out that remailers exist and what they do. build a remailer "who" server into each remailer

I point out this doesn't help if you don't know where the first remailer is. What I was specifically referring to was public education. Were remailers ubiquitous, there would be a chapter on them in each of the latest rage of 'how to use the internet' books. They could be a well-used service, like archie.

But this has nothing to do with writing code. There are plenty of people on this list who aren't writing code, who most likely have better writing skills than CS/Engineering majors, and who have the time to write remailer faqs and evangelize remailer use. This type of project can be done in parallel with remailer development. I don't see why any priority scheme is needed. Cypherpunks, as often repeated, are not a monolithic group governed from the top-down who obey directions to focus all their efforts on one priority.

In fact, they are not. There are numerous reasons for this, some of which are self-referential (as in, there aren't a lot of remailers yet) and some of which are not. For example, there's no FAQ for comp.mail.remailer, because there's no such group. Why shouldn't there be?

Maybe because it would get voted down or maybe because no one has RFD'd it yet. Nothing is stopping anyone from going ahead and doing this. An alt group would be better.

...

...

-- Finding a remailer to use. ditto

I specifically made this a separate item because it has a different solution. Let's assume the potential user has some beginner's document about remailers. How do they go about finding out what remailers exist?

Well, the document could have a list of them, but that doesn't exactly work well in the face of rapid changes. Some centrality in the initial query seems called for. That could be a stable machine, or some stable name, even. What the query actually looks like is less important.

This is already included in my new remailer, but I proposed a "remailer server" for keeping an up to date automatically generated list of working remailers almost a year ago (I even hacked up some partially working code for it) when it became obvious that Karl's list of remailers weren't good enough (although it was a good effort) The biggest problem is getting a stable machine or a stable network of 'DNS'-like machines. There is already a similar mechanism for MUDs. Besides the static list of running muds there is a MUD "mudwhod" server which maintains a list of running muds and who is logged into them.

There is, also, the question of trustworthiness. That mythical beast the reputation system might be applicable, but I know of none to judge for suitability. More generally, there are questions of policy. What, for example, is the policy of the remailer in case of administrative request for mappings? Are there liquidated damages available to someone whose privacy is breached? These legal issues are not so easily made into syntax.

This type of standardization is only likely to spontaneously evolve after a remailer network is already up and running and these policy issues come up. I don't think we can centrally draft some kind of Constitution/Bylaws for remailers which covers all possible future problems. Remailer politics and legal systems are an unexplored area. I think we should leave it up to the remailer operators for now since they will have to deal with these issues first hand.

...

...

-- Figuring out how to use a particular remailer. standardize remailer help system, standard remailer command format (but not neccessaily the commands themselves) Sorta like an SGML for remailers

I think the commands ought to be standardized, just like RFC-822 standardized on the To: field. I realize this is going to create a little havoc for the half-dozen or so remailer developers who have all chosen not to talk to each other during their developments.

All someone needs to do is write up an RFC and submit it.

...

...

-- Formatting a message for a remailer. see above Personally, I don't think we need multiple algorithms for this. Is there any compelling reason, other than to avoid wasting existing but not yet deployed code?

It could be that the best encapsulation method for remailer messages hasn't been developed yet. I certainly think the recursive-pasting token method needs a lot of work. A method should be general enough to work with any RSA/Pkey system and not rely on PGP's standard format. Cut lines definately needed to be standardized abstracted away from the underlying cryptosystem.

...

...

-- Receiving mail through a remailer. Get/Creating a nice client.

There's a transaction cost to switching clients which is huge. It's completely unrealistic to expect everyone to use a particular client for remailers. It just won't happen. Far better is to rework existing clients to support remailers and to get those changes into the main distributions.

Either way works, and the actual method used will probably be a combination of both. However, getting cypherpunk software installed in existing distributions will require some politics and lobbying on behalf of cypherpunks. (e.g. getting remailer mods into something like Eudora might be really hard)

...

Reducing complexity cost: All of this could be lowered by creating an easy-to-use remailer client which is compiled (or perl/tcl interpreted) and installed with every unix out there so it becomes ubiquitous.

The dream of universal software. When I can unpack some software and type 'make', and do nothing else except read the man pages that 'make' caused to be formatted, I'll call that universal software. And not before.

Already exists. Almost every Unix system I have encounted comes with atleast Perl4, and many come with TCL. Perl is a standard environment and any correctly installed Perl should run a correctly written Perl script. I'd say that one can create a remailer/client in Perl that can be installed by almost anyone. (as long as you don't rely on "absolute" paths which change, or non-standard environment variables)

I'm glad lowering these transaction costs garnered a response. But what I really want to see is, what did I forget about transaction costs to use remailers?

The biggest thing you're missing is the fact that many users can't even understand how to use LISTSERVs or run mail(1) To many people, typing "::\n request-remailing-to: xxxx" and encrypting it, then adding "Encrypted: PGP" is a huge transaction cost. I don't use remailers for similar reasons. A simple mod to the elm script, "mailpgp" which detects a remailer in the To: address, prompts you for "mail anonymously to? " and then does all the underlying remailer commands and chaining stuff automatically would be a huge benefit. Even better would be a script which asks you "Mail anonymously?" and if answered yes, it would automatically pick a remailer and do the nasty stuff. Emacs and Elm are pretty standard, plug in elisp/perl scripts would work fairly well to encourage remailer use but some evangelization would be required also to encourage use and educate. I once suggested that someone set up a porno-server on the remailer network as the ultimate carrot-and-stick method for getting people to use remailers. I still think this is a good idea. (after all, the two biggest uses of Julf's system I see are in the sex newsgroups and in IRC phreak/warez trading) -Ray -- Ray Cromwell | Engineering is the implementation of science; -- -- rjc@gnu.ai.mit.edu | politics is the implementation of faith. --