Re: Frothing remailers - an immodest proposal
At 6:55 PM 01/31/95, Robert Rothenberg wrote:
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.
Yeah, this is really an excellent idea, that I don't see happening any time soon. Although of course if anyone wants to write code for such a beast, that would be really excellent. If someone gets around to writing it, it'll happen, but it would be a fairly big project, so I wouldn't hold my break. Safe TCL, anyone?
At 6:55 PM 01/31/95, Robert Rothenberg wrote:
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.
Yeah, this is really an excellent idea, that I don't see happening any time soon. Although of course if anyone wants to write code for such a beast, that would be really excellent. If someone gets around to writing it, it'll happen, but it would be a fairly big project, so I wouldn't hold my break. Safe TCL, anyone?
Hmmm... this could be combined with the "subway" remailer idea too. Have a message format that can contain multiple destinations and a script lang also can pick up and drop off messages, and messages can specify if they are to be picked up or dropped off, etc.... endless possibilities... I don't have the C/Unix skills to even attempt this though.
Jonathan Rochkind wrote:
At 6:55 PM 01/31/95, Robert Rothenberg wrote:
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.
Yeah, this is really an excellent idea, that I don't see happening any time soon. Although of course if anyone wants to write code for such a beast, that would be really excellent. If someone gets around to writing it, it'll happen, but it would be a fairly big project, so I wouldn't hold my break. Safe TCL, anyone?
I certainly support this kind of idea, and have for a long time. Crypto is well-suited for the "small languages" point of view (and the competing points of view for object-oriented systems, production systems, etc.). Anything to abstract away the grungy details and hide them. TCL and Perl are steps, and Strick (Henry Strickland) has of course been working on his Skronk system, which does some of this. Python is another possibility. Some of the graphical-oriented languages like Prograph might be useful. And I still think Smalltalk has promise, as many financial institutions are using it to model and automate financial transactions, which have obvious similarities to our crypto projects. The real obstacles are time and money. Corporations and banks doing this work can put several people on these projects for several years, while most Cypherpunks projects have to be fit in between "Data Structures 202" and "Ren and Stimpy." --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. Cypherpunks list: majordomo@toad.com with body message of only: subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay
participants (3)
-
jrochkin@cs.oberlin.edu -
Robert Rothenburg Walking-Owl -
tcmay@netcom.com