From infobot-dev@metronomicon.com Fri Jan 14 07:48:23 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id HAA07034 for infobot-dev-list; Fri, 14 Jan 2000 07:47:51 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from ux1.sp.cs.cmu.edu (UX1.SP.CS.CMU.EDU [128.2.198.101]) by token.metronomicon.com (8.9.3/8.8.7) with SMTP id HAA07031 for ; Fri, 14 Jan 2000 07:47:50 -0500 Received: from ip26.pittsburgh5.pa.pub-ip.psi.net by ux1.sp.cs.cmu.edu id aa18788; 14 Jan 2000 7:50 EST Message-ID: <387F1B87.49CC5B6A@cs.cmu.edu> Date: Fri, 14 Jan 2000 07:50:15 -0500 From: Kevin Lenzo Organization: School of Computer Science, Carnegie Mellon University X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: infobot-dev@infobot.org Subject: should be ok? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O I think the list should be back up; i've noticed some bounces, but i think i've got it fixed. kevin From infobot-dev@metronomicon.com Sat Jan 15 19:58:03 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id TAA18581 for infobot-dev-list; Sat, 15 Jan 2000 19:57:09 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from verdi.siteprotect.com (verdi.siteprotect.com [209.100.98.18]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id TAA18578 for ; Sat, 15 Jan 2000 19:57:09 -0500 Received: from LucidX.com (adsl-63-199-105-209.dsl.lsan03.pacbell.net [63.199.105.209]) by verdi.siteprotect.com (8.8.5/8.8.5) with ESMTP id SAA29917 for ; Sat, 15 Jan 2000 18:59:14 -0600 Message-ID: <3881180F.4671DE30@LucidX.com> Date: Sat, 15 Jan 2000 16:59:59 -0800 From: "Samy Kamkar (CommPort5)" Organization: LucidX X-Mailer: Mozilla 4.08 [en] (X11; I; FreeBSD 3.1-RELEASE i386) MIME-Version: 1.0 To: infobot-dev@infobot.org Subject: New Version of the OS version getting addition Content-Type: multipart/mixed; boundary="------------D793833AF91EC9DCE1BC1A11" Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O This is a multi-part message in MIME format. --------------D793833AF91EC9DCE1BC1A11 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here is the updated CGI which fixed the way it parses the HTML on Linux Mandrake's site, although you really don't need this CGI to get the addon working it's good if you want to develop it or use it locally or something. The default CGI that osvers.pl, the actual addon you put on Infobot, is at http://www.LucidX.com/cgi-bin/unix.pl ... osvers.pl is still the same so if you already have it you won't need to get this version but for you who don't have it yet you can get it now. Over and out. -Sam (CommPort5) --------------D793833AF91EC9DCE1BC1A11 Content-Type: text/plain; charset=us-ascii; name="unix.cgi" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="unix.cgi" #!/usr/bin/perl use CGI qw(:standard); use LWP::UserAgent; my ($x, $ua, $url, $html, $response, $res, $name, $num); $num = "0"; sub add { $x .= "$name $1/"; } do { if ($num eq "0") { &con("FreeBSD", "http://www.freebsd.org/releases/"); } if ($num eq "1") { &con("Red Hat", "http://www.redhat.com/"); } if ($num eq "2") { &con("Slackware", "http://www.slackware.com/"); } if ($num eq "3") { &con("Caldera", "http://www.caldera.com/"); } if ($num eq "4") { &con("Mandrake", "http://www.linux-mandrake.com/en/"); } if ($num eq "5") { &con("OpenBSD", "http://www.openbsd.org/"); } if ($num eq "6") { &con("NetBSD", "http://www.netbsd.org/"); } if ($num eq "7") { &con("SuSE", "http://www.suse.com/"); } sub con { $name = $_[0]; $ua = new LWP::UserAgent; $ua->timeout(12); $url = $_[1]; $html = new HTTP::Request('GET',$url); $response = $ua->request($html); if($response->is_success) { $res = $response->content; $res =~ s/\n/ /g; ##### FreeBSD ##### if($name eq "FreeBSD") { $res =~ /Release (.*?)<\/B>/; &add; } ##### Red Hat ##### if($name eq "Red Hat") { $res =~ /Red Hat Linux (.*?)<\/A>/; &add; } ##### Slackware ##### if($name eq "Slackware") { $res =~ /
Get (.*?)!<\/A>/; &add; } ##### Caldera ##### if($name eq "Caldera") { $res =~ /OpenLinux (.*?)<\/a>
/; &add; } ##### Mandrake old ##### # if($name eq "Mandrake") { # $res =~ /Linux Mandrake (\d\.\d)/; # &add; # } ##### Mandrake ##### if($name eq "Mandrake") { $res =~ /<\/b> - Mandrake (\d\.\d) /; &add; } ##### OpenBSD ##### if($name eq "OpenBSD") { $res =~ /The current release is OpenBSD (.*?)<\/a>/; &add; } ##### NetBSD ##### if($name eq "NetBSD") { $res =~ /Latest release - (.*?)<\/a>/; &add; } ##### SuSE ##### if($name eq "SuSE") { $res =~ /SuSE Linux (.*?) Imagetimeout(60); my $url = "http://www.LucidX.com/cgi-bin/unix.pl"; my $html = new HTTP::Request('GET',$url); my $response = $ua->request($html); if($response->is_success) { my $res = $response->content; $res =~ s/\n//g; $res =~ /

(.*?)<\/P>/; return "$1"; } else { return "Can't get versions"; } } 1; --------------D793833AF91EC9DCE1BC1A11-- From infobot-dev@metronomicon.com Sun Jan 16 21:42:39 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id VAA27728 for infobot-dev-list; Sun, 16 Jan 2000 21:41:45 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from verdi.siteprotect.com (verdi.siteprotect.com [209.100.98.18]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id VAA27725 for ; Sun, 16 Jan 2000 21:41:44 -0500 Received: from LucidX.com (adsl-63-199-105-209.dsl.lsan03.pacbell.net [63.199.105.209]) by verdi.siteprotect.com (8.8.5/8.8.5) with ESMTP id UAA30010 for ; Sun, 16 Jan 2000 20:43:50 -0600 Message-ID: <3882820F.713D6470@LucidX.com> Date: Sun, 16 Jan 2000 18:44:32 -0800 From: "Samy Kamkar (CommPort5)" Organization: LucidX X-Mailer: Mozilla 4.08 [en] (X11; I; FreeBSD 3.1-RELEASE i386) MIME-Version: 1.0 To: infobot-dev@infobot.org Subject: Rev it up Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O Hello there, here are just some code snippits to add to your infobot's source programs. Nothing too big but just add a little features that can help you and some people like. Make sure to make backups of all the source programs you change before changing them if for some reason they don't work right. First off, cycling the log file to the day it was made instead of one huge log file. This code will make new logs daily by date looking something like: 16Jan2000-infobot.log You just add this code but change the directory from /usr/infobot/logs/$date to /wherever/you/store/logs/$date You will need to change this in src/Misc.pl so here it is: (line 5 after use Socket;): use POSIX qw(strftime); Remove lines 124-146 ( sub log_line --- }) and put this in instead: ############ sub log_line { my($line) = @_; my($logwrite) = 0; my $s = time(); if ($param{'logfile'} ne '') { $line =~ s/\n*$/\n/; open(TRACK, ">>$param{logfile}"); $loglines++; $total_loglines++; print TRACK "$s $line"; close(TRACK); # if (TRACK); } } ################ Next is to get your infobot connecting to random servers instead of just one. This is good if a server dies while you're not around so your bot would automaticly connect to a different server instead of the same one, although it will only connect if you have more than one server specified in your files/infobot.config which you shouldn't have by default. Once you add this code in your files/infobot.config just seperate the servers with commas (and a space after each one) like so: servers irc.infobot.org, irc.cs.cmu.edu You will need to change src/Irc.pl so here it is: Remove lines 344-352 (while ($connected) { --- rawout("USER, blah, blah ,blah) and put this in instead: #################### while ($connected) { @serv = split(/, /,$param{server}); $servr = "$serv[int(rand(@serv))]"; srvConnect($servr, $param{port}); if ($param{server_pass}) { # ksiero++ rawout("PASS $param{server_pass}"); } rawout("NICK $param{wantNick}"); rawout("USER $param{ircuser} $param{ident} $servr :$param{realname}"); #################### Next off, random quit messages (only for you people who's infobots like to quit a lot for some reason), this will just quit with a different quit message (of course you specify them) every time unless you just want one, you leave your configuration alone just like the random servers but if you want random quits just add commas (and a space after each one) again like so: quitMsg Infobot - Smarter than the average Eggdrop, I was told to die So open up your src/IrcExtras.pl and change like so: Remove lines 32-37 (sub killed { --- }) and put this in: ##################### sub killed { @qt = split(/, /,$param{'quitMsg'}); $quit = "$qt[int(rand(@qt))]"; &quit($quit); &closeDBM("is", "are"); exit(1); } ###################### That is all for now. Please return to your IRC client. -Sam (CommPort5) From infobot-dev@metronomicon.com Mon Jan 17 05:01:47 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id FAA29441 for infobot-dev-list; Mon, 17 Jan 2000 05:01:43 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from othersideofthe.earth.li (IDENT:qmailr@othersideofthe.earth.li [210.145.136.209]) by token.metronomicon.com (8.9.3/8.8.7) with SMTP id FAA29438 for ; Mon, 17 Jan 2000 05:01:41 -0500 Received: (qmail 10121 invoked by uid 500); 17 Jan 2000 10:03:59 -0000 Date: Mon, 17 Jan 2000 19:03:59 +0900 From: Simon Cozens To: infobot-dev@infobot.org Subject: Re: Rev it up Message-ID: <20000117190359.A10095@othersideofthe.earth.li> Reply-To: Simon Cozens References: <3882820F.713D6470@LucidX.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <3882820F.713D6470@LucidX.com>; from Samy Kamkar (CommPort5) on Sun, Jan 16, 2000 at 06:44:32PM -0800 X-Operating-System: Linux othersideofthe.earth.li 2.2.13 Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O On Sun, Jan 16, 2000 at 06:44:32PM -0800, Samy Kamkar (CommPort5) wrote: > Hello there, here are just some code snippits to add to your infobot's > source programs. Woo! Sam++ I'm afraid I'm taking unilateral action here, not in a nasty way, but I want these things to be accessible. Any further cool patches and extension files, including these last three patches, posted to the list will be archived on my infobot patches site at http://othersideofthe.earth.li/infobot/ -- If a word in the dictionary were misspelled, how would we know? -- Steven Wright From infobot-dev@metronomicon.com Mon Jan 17 22:47:46 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id WAA02352 for infobot-dev-list; Mon, 17 Jan 2000 22:47:12 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id WAA02349 for ; Mon, 17 Jan 2000 22:47:11 -0500 Received: from [10.1.0.2] ([24.28.72.78]) by Mail.austin.rr.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 17 Jan 2000 21:40:21 -0600 User-Agent: Microsoft Outlook Express Macintosh Edition - 5.0 (1513) Date: Mon, 17 Jan 2000 21:49:35 -0600 Subject: Term::ANSIColor.pm From: David Blache To: Infobot development list Message-ID: In-Reply-To: <3860DCB6.1446CC6E@cs.cmu.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O on 12/22/1999 8:14 AM, Kevin Lenzo wrote: > Note: It will be much prettier if you have Term::ANSIColor.pm. Where can I get this? Also is 0.49_03 irc-capable yet? From infobot-dev@metronomicon.com Wed Jan 19 08:25:45 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id IAA09759 for infobot-dev-list; Wed, 19 Jan 2000 08:25:00 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from fwnau040.usco.com (fwnau040.usco.com [207.92.15.79]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id IAA09756 for ; Wed, 19 Jan 2000 08:25:00 -0500 Received: from ntnau210.usco.com (ntnau210.usco.com [172.16.66.43]) by fwnau040.usco.com (8.9.1/8.8.5) with ESMTP id IAA11228 for ; Wed, 19 Jan 2000 08:27:26 -0500 (EST) Received: by ntnau210.usco.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jan 2000 08:27:26 -0500 Message-ID: From: "Meltzer, Kevin" To: infobot-dev@infobot.org Subject: Anyone doing these yet? Date: Wed, 19 Jan 2000 08:27:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O Has anyone worked on a web-to-bot interface or an 'answering machine' system as of yet? Cheers, KM From infobot-dev@metronomicon.com Wed Jan 19 08:32:44 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id IAA09903 for infobot-dev-list; Wed, 19 Jan 2000 08:32:43 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from othersideofthe.earth.li (IDENT:qmailr@othersideofthe.earth.li [210.145.136.209]) by token.metronomicon.com (8.9.3/8.8.7) with SMTP id IAA09900 for ; Wed, 19 Jan 2000 08:32:42 -0500 Received: (qmail 3692 invoked by uid 500); 19 Jan 2000 13:35:07 -0000 Date: Wed, 19 Jan 2000 22:35:07 +0900 From: Simon Cozens To: infobot-dev@infobot.org Subject: Nick Regaining Message-ID: <20000119223507.A3682@othersideofthe.earth.li> Reply-To: Simon Cozens Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i X-Operating-System: Linux othersideofthe.earth.li 2.2.13 Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O purl doesn't have her nick back. :( http://othersideofthe.earth.li/infobot/regain.patch --- Irc.old Mon Jan 17 18:55:44 2000 +++ Irc.pl Wed Jan 19 22:32:07 2000 @@ -165,6 +165,9 @@ } } } elsif ($type=~/NICK/) { + if ($chan eq $ident and $nick eq $param{wantNick}) { # That's me! + $ident=$param{nick}=$param{wantNick}; $regain_nick == undef ; + } if ($param{ansi_control}) { &status(">>> ".c($nick,'bold green'). " materializes into ".c($chan,'bold green')); @@ -255,6 +258,7 @@ &status(">>> set by $1 at $2"); } } elsif ($msg=~/^433/) { + $regain_nick=1; ++$nicktries; if (length($param{wantNick}) > 9) { $ident = chop $param{wantNick}; --- Process.old Wed Jan 19 22:18:25 2000 +++ Process.pl Wed Jan 19 22:32:12 2000 @@ -3,11 +3,18 @@ # process the incoming message $SIG{'ALRM'} = 'TimerAlarm'; +my $regain_counter=0; sub process { ($who, $msgType, $message) = @_; $origMessage = $message; $message =~ s/[\cA-\c_]//ig; # strip control characters + + if (defined $regain_nick ) { # and ! ++$regain_counter%20) { + &status("Trying to get my nick back"); + $regain_nick=undef; # will be set back to 1 if we fail. + rawout("NICK $param{wantNick}"); + } $addressed = 0; -- I washed a sock. Then I put it in the dryer. When I took it out, it was gone. -- Steven Wright From infobot-dev@metronomicon.com Wed Jan 19 11:15:19 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id LAA10839 for infobot-dev-list; Wed, 19 Jan 2000 11:15:09 -0500 Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id LAA10836 for ; Wed, 19 Jan 2000 11:15:08 -0500 Received: from phydeaux.org (user-38lca7b.dialup.mindspring.com [209.86.40.235]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id LAA23528 for ; Wed, 19 Jan 2000 11:17:33 -0500 (EST) Received: (from fletch@localhost) by phydeaux.org (8.9.3/8.9.3) id LAA25765; Wed, 19 Jan 2000 11:17:31 -0500 X-Authentication-Warning: godzilla.phydeaux.org: fletch set sender to fletch@phydeaux.org using -f To: infobot-dev@infobot.org Subject: Re: Anyone doing these yet? References: From: Mike Fletcher Organization: Very Little Date: 19 Jan 2000 11:17:31 -0500 In-Reply-To: "Meltzer, Kevin"'s message of "Wed, 19 Jan 2000 08:27:24 -0500" Message-ID: Lines: 27 User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/20.4 (Emerald) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O >>>>> "KM" == Meltzer, Kevin writes: KM> Has anyone worked on a web-to-bot interface or an 'answering KM> machine' system as of yet? I'd thought about some sort of module to drive a browser from the server mode (netscape -remote '...' type thing), and then thought that a better solution might be to embed a small http server. You'ld have to either post process results (insert anchors around URLs and the like), and/or extend the Infobot::Message class to have a method analagous to the HTTP Accepts header and let those modules that want return text/html formatted responses when apropriate. Not that I've done anything about it yet. :/ On a somewhat related tangent, is there any way to fire off a request to the bot from within a handler? One idea for implementing the browser-driving I had was to implement a `show urls (in|for)' that somehow obtained the returned stuff from whatever the argument it was given produced and then scaned that for URLs. -- Fletch | "If you find my answers frightening, __`'/| fletch@phydeaux.org | Vincent, you should cease askin' \ o.O' 678 443-6239(w) | scary questions." -- Jules =(___)= | U From infobot-dev@metronomicon.com Wed Jan 19 11:30:18 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id LAA11122 for infobot-dev-list; Wed, 19 Jan 2000 11:30:17 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from othersideofthe.earth.li (IDENT:qmailr@othersideofthe.earth.li [210.145.136.209]) by token.metronomicon.com (8.9.3/8.8.7) with SMTP id LAA11119 for ; Wed, 19 Jan 2000 11:30:15 -0500 Received: (qmail 10381 invoked by uid 500); 19 Jan 2000 16:32:40 -0000 Date: Thu, 20 Jan 2000 01:32:40 +0900 From: Simon Cozens To: infobot-dev@infobot.org Subject: Re: Anyone doing these yet? Message-ID: <20000120013240.A10370@othersideofthe.earth.li> Reply-To: Simon Cozens References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Mike Fletcher on Wed, Jan 19, 2000 at 11:17:31AM -0500 X-Operating-System: Linux othersideofthe.earth.li 2.2.13 Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O On Wed, Jan 19, 2000 at 11:17:31AM -0500, Mike Fletcher wrote: > On a somewhat related tangent, is there any way to fire off a > request to the bot from within a handler? One idea for implementing > the browser-driving I had was to implement a `show urls (in|for)' that > somehow obtained the returned stuff from whatever the argument it was > given produced and then scaned that for URLs. Easy enough; just use LWP's get to get the URL and then HTML::LinkExtor If you want to do it with funny forking and things, have a look at W3Search.pl Simon -- "Linux: the operating system with a CLUE... Command Line User Environment". (seen in a posting in comp.software.testing) From infobot-dev@metronomicon.com Wed Jan 19 11:58:23 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id LAA11507 for infobot-dev-list; Wed, 19 Jan 2000 11:58:23 -0500 Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id LAA11504 for ; Wed, 19 Jan 2000 11:58:22 -0500 Received: from phydeaux.org (user-38lca7b.dialup.mindspring.com [209.86.40.235]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA11360; Wed, 19 Jan 2000 12:00:46 -0500 (EST) Received: (from fletch@localhost) by phydeaux.org (8.9.3/8.9.3) id MAA25913; Wed, 19 Jan 2000 12:00:45 -0500 X-Authentication-Warning: godzilla.phydeaux.org: fletch set sender to fletch@phydeaux.org using -f To: Simon Cozens Cc: infobot-dev@infobot.org Subject: Re: Anyone doing these yet? References: <20000120013240.A10370@othersideofthe.earth.li> From: Mike Fletcher Organization: Very Little Date: 19 Jan 2000 12:00:45 -0500 In-Reply-To: Simon Cozens's message of "Thu, 20 Jan 2000 01:32:40 +0900" Message-ID: Lines: 39 User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/20.4 (Emerald) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O >>>>> "Simon" == Simon Cozens writes: Simon> On Wed, Jan 19, 2000 at 11:17:31AM -0500, Mike Fletcher Simon> wrote: >> On a somewhat related tangent, is there any way to fire off a >> request to the bot from within a handler? One idea for >> implementing the browser-driving I had was to implement a `show >> urls (in|for)' that somehow obtained the returned stuff from >> whatever the argument it was given produced and then scaned >> that for URLs. Simon> Easy enough; just use LWP's get to get the URL and then Simon> HTML::LinkExtor If you want to do it with funny forking and Simon> things, have a look at W3Search.pl No, I don't want the module/bot itself to get the URL. I'm thinking of something sort of like: user says `show url for infobot' to the bot the `show url' handler parses out `infobot' the handler somehow asks itself (the bot) about `infobot' and it (the handler) gets the response back rather than the reply going back to the (user/channel/console) the `show url' handler slurps out URLs from the reply and then does system("netscape", "-remote", ...) for each That third step is what I'm not sure of how to do (make the bot talk to itself internally). -- Fletch | "If you find my answers frightening, __`'/| fletch@phydeaux.org | Vincent, you should cease askin' \ o.O' 678 443-6239(w) | scary questions." -- Jules =(___)= | U From infobot-dev@metronomicon.com Wed Jan 19 15:38:07 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id PAA12564 for infobot-dev-list; Wed, 19 Jan 2000 15:37:54 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from ajax.host4u.net (ajax.host4u.net [216.71.64.15]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id PAA12561 for ; Wed, 19 Jan 2000 15:37:52 -0500 Received: from tony (pm4-18.buckeyeinternet.com [209.41.215.88]) by ajax.host4u.net (8.8.5/8.8.5) with SMTP id OAA13781 for ; Wed, 19 Jan 2000 14:39:59 -0600 Message-ID: <001701bf62bd$5df8f140$0200a8c0@BUCKEYENET.NET> From: "zip" To: Subject: idea. Date: Wed, 19 Jan 2000 15:40:02 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01BF6293.731A9620" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O This is a multi-part message in MIME format. ------=_NextPart_000_0010_01BF6293.731A9620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I dont know if this is possible or already done but itd be cool. If the = bots could ask each other for help and share factoids, but more = importantly if there was some kinda of pub url or someway to list all = the infobots so that an infobot could download the list and to ask = questions. Just an idea. ------=_NextPart_000_0010_01BF6293.731A9620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I dont know if this is possible or = already done but=20 itd be cool. If the bots could ask each other for help and share = factoids, but=20 more importantly if there was some kinda of pub url or someway to list = all the=20 infobots so that an infobot could download the list and to ask = questions. Just=20 an idea.
------=_NextPart_000_0010_01BF6293.731A9620-- From infobot-dev@metronomicon.com Wed Jan 19 15:46:36 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id PAA12818 for infobot-dev-list; Wed, 19 Jan 2000 15:46:35 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from dragon.cbi.tamucc.edu (IDENT:postfix@dragon.cbi.tamucc.edu [165.95.1.149]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id PAA12815 for ; Wed, 19 Jan 2000 15:46:33 -0500 Received: by dragon.cbi.tamucc.edu (Postfix, from userid 101) id CAD14E93F; Wed, 19 Jan 2000 15:11:35 -0600 (CST) Date: Wed, 19 Jan 2000 15:11:35 -0600 From: duff@cbi.tamucc.edu To: zip Cc: infobot-dev@infobot.org Subject: Re: idea. Message-ID: <20000119151135.A6594@cbi.tamucc.edu> References: <001701bf62bd$5df8f140$0200a8c0@BUCKEYENET.NET> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <001701bf62bd$5df8f140$0200a8c0@BUCKEYENET.NET>; from zip@1337.org on Wed, Jan 19, 2000 at 03:40:02PM -0500 Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O On Wed, Jan 19, 2000 at 03:40:02PM -0500, zip wrote: > I dont know if this is possible or already done but itd be cool. If > the bots could ask each other for help and share factoids, but more > importantly if there was some kinda of pub url or someway to list all > the infobots so that an infobot could download the list and to ask > questions. Just an idea. Gee, this sounds remarkably like something I mentioned on channel today :-) -Scott -- Jonathan Scott Duff duff@cbi.tamucc.edu From infobot-dev@metronomicon.com Wed Jan 19 20:25:47 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id UAA19274 for infobot-dev-list; Wed, 19 Jan 2000 20:25:38 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from asec50.pwj.co.jp (IDENT:root@asec50.pwj.co.jp [202.32.76.250]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id UAA19271 for ; Wed, 19 Jan 2000 20:25:36 -0500 From: scozens@pwj.co.jp Received: from asec12.pwj.co.jp (barrier1.pwj.co.jp [202.32.76.1] (may be forged)) by asec50.pwj.co.jp (8.9.3/3.7W) with ESMTP id KAA26713 for ; Thu, 20 Jan 2000 10:33:15 +0900 (JST) Received: from pwj-gw-n001.pwj.co.jp (mailhost [10.159.99.13]) by asec12.pwj.co.jp (8.9.2/3.7W) with SMTP id KAA18452 for ; Thu, 20 Jan 2000 10:32:06 +0900 (JST) Received: by pwj-gw-n001.pwj.co.jp(Lotus SMTP MTA Internal build v1.2 hotfix4 (684.3 7-31-1998)) id 4925686C.0007F994 ; Thu, 20 Jan 2000 10:27:06 +0900 X-Lotus-FromDomain: PRICE WATERHOUSE-JAPAN To: infobot-dev@infobot.org Message-ID: <4925686C.0006B3FA.00@pwj-gw-n001.pwj.co.jp> Date: Thu, 20 Jan 2000 10:25:51 +0900 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O duff@cbi.tamucc.edu wrote: > On Wed, Jan 19, 2000 at 03:40:02PM -0500, zip wrote: > > I dont know if this is possible or already done but itd be cool. If > > the bots could ask each other for help and share factoids, but more > > importantly if there was some kinda of pub url or someway to list all > > the infobots so that an infobot could download the list and to ask > > questions. Just an idea. > Gee, this sounds remarkably like something I mentioned on channel > today :-) Yep; to explain, the bots currently do talk to each other - they message each other using a slightly special syntax. Every so often you may see something like this: purl, wibble? Bugger all, I dunno. url knew: wibble is foo bar baz You register the bots you want your bot to talk to in the config file: I'm pretty sure - but I don't know - that those bots also have to have you in their friendly bots config. However, what we were thinking yesterday was to have the bots connected together aside from IRC, talking TCP/IP connections to each other. I hadn't really considered linking *all* the infobots together, just doing small peer-to-peer networks, but there's a pretty obvious way to get them all talking - every bot links to MetaBot, which would multiplex the query. You'd have a shedload of bot traffic if you wanted to do that, though. I'd rather a more decentralised setup, but I don't really want to write a multi-level peer-to-peer network with message routing and proxying and all that inside infobot; however, don't let me stop you. One thing I do want to work on when I get some decent programming time is to have bots connect to more than one IRC server at once, which is another easy way to achieve massive interconnection: if all the bots sat in #infobot in irc.infobot.org they could talk to each other there. Is anyone else working on this sort of thing in the 0.4x series? Simon From infobot-dev@metronomicon.com Wed Jan 19 23:26:01 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id XAA20104 for infobot-dev-list; Wed, 19 Jan 2000 23:25:49 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from ux1.sp.cs.cmu.edu (UX1.SP.CS.CMU.EDU [128.2.198.101]) by token.metronomicon.com (8.9.3/8.8.7) with SMTP id XAA20101 for ; Wed, 19 Jan 2000 23:25:49 -0500 Received: from ip228.pittsburgh5.pa.pub-ip.psi.net by ux1.sp.cs.cmu.edu id aa11798; 19 Jan 2000 23:27 EST Message-ID: <38868DD5.2CF8CA5A@cs.cmu.edu> Date: Wed, 19 Jan 2000 23:23:49 -0500 From: Kevin Lenzo Organization: School of Computer Science, Carnegie Mellon University X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: infobot-dev@infobot.org CC: scozens@pwj.co.jp, lenzo@cs.cmu.edu, larry@wall.org Subject: a propos of nothing References: <4925686C.0006B3FA.00@pwj-gw-n001.pwj.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O simon++ yes, interbot is an important part of the new infobot platform. i expect i'll be able to produce a lot more activity on the new model, after which you may not have to depend on me [after february]. http:///www.infobot.org and /list/ [fyi]. We need to discuss the whole thing; right now it's a pretty simple forwarding. Addi's repro on alternate networks, and Simon's mods(!) are part of the Field. i've been told at CMU i can work on "anything i want to do", so i will be at least partly on refocussing on the 'bot -- and most importantly YOUR INPUT. I have speech in and out working, and i'm sure that'll need the attention of interested folks like y'all to get it robust. YAPC is a part of that, and other directions; let's look at international venues, also. i apologize for my inattention lately, but i swear to y'all it's only a matter of the moment. we're embarked on the great work -- if you resonate with it, we welcome you :) if you don't, we welcome you -- but we expect a voice from you. kevin lenzo@cs.cmu.edu ps - i hate end notes, but i beg you to read Pike's only recent available work on tagmemics. i got a copy from amazon, and it's well worth reading. I'd type the whole thing in if it weren't for the diagrams, and i'm tempted to scan 'em. i'm on the verge of proposing a long talk at TPC on particle, wave, and field in the world of the bot -- but as a situated talk on perl and "we." I'll make a copy and mail it to you (snail mail) if you can't find it. If i have to, i'll type it them in. kevin scozens@pwj.co.jp wrote: > > duff@cbi.tamucc.edu wrote: > > On Wed, Jan 19, 2000 at 03:40:02PM -0500, zip wrote: > > > I dont know if this is possible or already done but itd be cool. If > > > the bots could ask each other for help and share factoids, but more > > > importantly if there was some kinda of pub url or someway to list all > > > the infobots so that an infobot could download the list and to ask > > > questions. Just an idea. > > > Gee, this sounds remarkably like something I mentioned on channel > > today :-) > > Yep; to explain, the bots currently do talk to each other - they > message each other using a slightly special syntax. Every so often > you may see something like this: > > purl, wibble? > Bugger all, I dunno. > url knew: wibble is foo bar baz > > You register the bots you want your bot to talk to in the config file: > I'm pretty sure - but I don't know - that those bots also have to have > you in their friendly bots config. > > However, what we were thinking yesterday was to have the bots connected > together aside from IRC, talking TCP/IP connections to each other. I > hadn't really considered linking *all* the infobots together, just doing > small peer-to-peer networks, but there's a pretty obvious way to get > them all talking - every bot links to MetaBot, which would multiplex > the query. You'd have a shedload of bot traffic if you wanted to do that, > though. I'd rather a more decentralised setup, but I don't really want > to write a multi-level peer-to-peer network with message routing and > proxying and all that inside infobot; however, don't let me stop you. > > One thing I do want to work on when I get some decent programming time > is to have bots connect to more than one IRC server at once, which is > another easy way to achieve massive interconnection: if all the bots > sat in #infobot in irc.infobot.org they could talk to each other there. > > Is anyone else working on this sort of thing in the 0.4x series? > > Simon From infobot-dev@metronomicon.com Thu Jan 20 00:24:42 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id AAA20581 for infobot-dev-list; Thu, 20 Jan 2000 00:24:37 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from asec50.pwj.co.jp (IDENT:root@asec50.pwj.co.jp [202.32.76.250]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id AAA20578 for ; Thu, 20 Jan 2000 00:24:34 -0500 From: scozens@pwj.co.jp Received: from asec12.pwj.co.jp (barrier1.pwj.co.jp [202.32.76.1] (may be forged)) by asec50.pwj.co.jp (8.9.3/3.7W) with ESMTP id OAA04156; Thu, 20 Jan 2000 14:32:32 +0900 (JST) Received: from pwj-gw-n001.pwj.co.jp (mailhost [10.159.99.13]) by asec12.pwj.co.jp (8.9.2/3.7W) with SMTP id OAA02603; Thu, 20 Jan 2000 14:31:23 +0900 (JST) Received: by pwj-gw-n001.pwj.co.jp(Lotus SMTP MTA Internal build v1.2 hotfix4 (684.3 7-31-1998)) id 4925686C.001DE04B ; Thu, 20 Jan 2000 14:26:19 +0900 X-Lotus-FromDomain: PRICE WATERHOUSE-JAPAN To: infobot-dev@infobot.org cc: lenzo@cs.cmu.edu, larry@wall.org Message-ID: <4925686C.0019F820.00@pwj-gw-n001.pwj.co.jp> Date: Thu, 20 Jan 2000 14:25:04 +0900 Subject: Re: a propos of artificial intelligence, linguistics, and geckos Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O That nice Mr Lenzo wrote: > We need to discuss the whole thing; right now it's a pretty > simple forwarding. Addi's repro on alternate networks, and Simon's > mods(!) are part of the Field. Right. As most of you probably know, I'm Very Busy at the moment, and, although I can find time to work on 0.4x, I don't really have the time or the energy to grok the new architecture, much though I'd like to. I'm happy, if it would be useful, to take over collecting patches on the old stuff for the time being, so that development on the new stuff will go ahead; my current schedule means that I may well be up to helping out with Geckobot in August. At some point, I might start testing out the Highly Dangerous Development patches, but I can't promise. On the other hand, I'm more than happy to bounce ideas around and I'd be especially interested in the linguistic side of it as well, both the parsing and the internationalisation. That said, there are a few things that think would be a good idea at the design level, but they're so obvious you've probably thought of them anyway: The ability to add a filter to any stage of input/output. Complete abstraction of input/output for flexibility. Communication between components: when trying to answer a question, we may need to head off to a web search component to find information about the topic, which may in turn fire off a dictionary component to help with understanding something on the returned web page, and so on. Some state keeping would be nice, too. I recently had to do some very, very crufty code for the infobot to get information out of another IRC bot - it would save the original questioner, channel and message type away (is this going to be a Query object? Can they go on a stack?) and message the other bot, then return to ordinary processing, special-casing replies from the bot to relay onto the original questioner. Yuck. If we can think of a way around that, it would be helpful. We're also seeing the communication aspect coming up, which is an important issue. (Are we starting to model social patterns?) What do *you* do when you need to find something out? You either already know it (it's in your DBM, as it were) or you can ask someone else, you can look it up on the web or in an encyclopaedia. In some situations, you may think you've got the answer, but it doesn't seem to fit the question somehow. A human can tell pretty easily when he's got the wrong reference source for a topic; the query has a series of mental associations. When we're looking up quavers, we can usually work out if the answer's supposed to relate to music or cheesy potato chips. We're about to hit a really nasty knowledge representation issue here. (Should we be talking to the perl-ai list about this too?) > i've been told at CMU i can work on "anything i want to do", > so i will be at least partly on refocussing on the 'bot -- Sounds a pretty good brief. > I have speech in and out working, Genius. That's a huge psychological boost for human-computer interaction. I wonder where the project currently sits, in terms of the chatting-with-machines world. >From a Perl evangelism point of view, I'd really appreciate it if someone could find the time to XS up festival and sphinx. The more Perl this thing is, the bigger a propaganda coup. :) While we're being a propos of nothing, I'd just like to comment on how ironic life is. About a year ago, my rival brought an infobot onto the IRC network of my local hacker community. Of course, I already had a good emotional reason for disliking the bot, and it didn't help that it only knew about twenty or thirty factoids, and answered everything with `bugger all, I dunno.' What a useless piece of software, I thought. Now look what I'm doing. Maybe it's spite. :) (Of course, the real beauty is that the software hasn't changed, just the size of the knowledge base I'm used to working with.) > YAPC is a part of that, and other directions; let's look > at international venues, also. This was recently disgust(sic) on clpm, so I funneled it off to a mailing list: echo | mail european-yapc-subscribe@othersideofthe.earth.li to join. > i'm on the verge of proposing a long talk at TPC on > particle, wave, and field in the world of the bot -- but > as a situated talk on perl and "we." By all means reach for the stars, but never forget to keep your feet on the ground. When it comes down to it, only the code matters. Simon From infobot-dev@metronomicon.com Thu Jan 20 02:07:16 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id CAA21194 for infobot-dev-list; Thu, 20 Jan 2000 02:07:13 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from pixie.securenets.com (what.securetty.org [63.225.132.243]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id CAA21191 for ; Thu, 20 Jan 2000 02:07:12 -0500 Received: from localhost (jjacobs@localhost) by pixie.securenets.com (8.9.1/8.9.1) with SMTP id BAA29354 for ; Thu, 20 Jan 2000 01:09:36 -0600 Date: Thu, 20 Jan 2000 01:09:36 -0600 (CST) From: Jay Jacobs X-Sender: jjacobs@pixie.securenets.com Reply-To: Jay Jacobs To: infobot-dev@infobot.org Subject: Re: a propos of artificial intelligence, linguistics, and geckos In-Reply-To: <4925686C.0019F820.00@pwj-gw-n001.pwj.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O On Thu, 20 Jan 2000 scozens@pwj.co.jp wrote: > Communication between components: when trying to answer > a question, we may need to head off to a web search component > to find information about the topic, which may in turn fire > off a dictionary component to help with understanding something > on the returned web page, and so on. I thought this was sticky, but... > We're also seeing the communication aspect coming up, which is > an important issue. (Are we starting to model social patterns?) > What do *you* do when you need to find something out? You > either already know it (it's in your DBM, as it were) or you > can ask someone else, you can look it up on the web or in an > encyclopaedia. In some situations, you may think you've got the > answer, but it doesn't seem to fit the question somehow. A > human can tell pretty easily when he's got the wrong reference > source for a topic; the query has a series of mental > associations. When we're looking up quavers, we can usually > work out if the answer's supposed to relate to music or cheesy > potato chips. We're about to hit a really nasty knowledge > representation issue here. wow. I'm only going to comment on the first one... I started thinking about information validity. It sounds like the path is being paved to a much smarter AI, and information validity will be a key component. Everyone who's run an infobot knows how much invalid data is scraped from IRC, so I see these main topics: How and where to get and accept information. How to process and reference, and relate information. How to store new information for future refence. How to detect and remove bogus information that's already stored. In addition to those, like Simon said, "The ability to add a filter to any stage of input/output." is essential. I have a feeling I've rehashed something from an AI 101 course... But do we really want to dive this deep into it? Or keep it simple with the absolute need for human interaction with the "forget" ability? Or perhaps give it a hard-coded fact-base, and build "soft" information off of what is determind as fact? (i.e. no on-the-fly dictionary lookups) Perhaps though if it starts to understand individual words, a thesauraus may be of some help to point towards the right song about cheesy potato chips. This is the batter for making a nice cake anyway. ...I think I'm gonna be spending my extra time looking into other batters to see how other chefs cook, since most of my AI and linguistics has been gleemed from cartoons and the discovery channel. Jay From infobot-dev@metronomicon.com Thu Jan 20 02:25:10 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id CAA21531 for infobot-dev-list; Thu, 20 Jan 2000 02:25:09 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from mlx7.unm.edu (qmailr@mlx7.unm.edu [129.24.8.209]) by token.metronomicon.com (8.9.3/8.8.7) with SMTP id CAA21528 for ; Thu, 20 Jan 2000 02:25:09 -0500 Received: (qmail 21014 invoked from network); 20 Jan 2000 07:27:32 -0000 Received: from ppp-227.unm.edu (HELO lachler) (129.24.14.227) by mlx7.unm.edu with SMTP; 20 Jan 2000 07:27:32 -0000 Message-Id: <3.0.6.32.20000120002731.008550c0@stonehenge.netadventure.net> X-Sender: sburke@stonehenge.netadventure.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 20 Jan 2000 00:27:31 -0700 To: infobot-dev@infobot.org From: "Sean M. Burke" Subject: factoid Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O The long arm of coincidence yet again... >Date: Thu, 20 Jan 2000 00:05:03 -0500 >From: Wordsmith >To: linguaphile@wordsmith.org >Subject: A.Word.A.Day--factoid > >factoid (FAK-toid) noun > > Unverified or inaccurate information that is presented in the press as > factual, often as part of a publicity effort, and that is then accepted > as true because of constant repetition. > > "This sort of thing is infuriating to practicing historians who can > tell fact from factoid, without, in a deep way, being able to explain > why." > A New Philosophy of History, The Economist, 11 Nov 1995. > > "Real-life factoid: Estes is married to Bissett, who'll be leaving > Melrose at midseason to have a baby." > Bruce Fretts, et al., Television: The Week, Entertainment Weekly, > 6 Sep 1996. > >This week's theme: words often used in a sense different from their established >definitions. > >............................................................................. >My idea of education is to unsettle the minds of the young and inflame their >intellects. -Robert Maynard Hutchins > >Q: What other services are available at Wordsmith.Org? >A: Have you tried "I, Rearrangement Servant" also known as "Internet Anagram > Server"? You can anagrammatize your name, your friends' names, and even > your pet's name. Find it at: http://wordsmith.org/anagram/index.html > >Pronunciation: >http://www.wordsmith.org/words/factoid.wav >http://www.wordsmith.org/words/factoid.ram > > -- Sean M. Burke sburke@netadventure.net http://www.netadventure.net/~sburke/ From infobot-dev@metronomicon.com Thu Jan 20 11:39:32 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id LAA23610 for infobot-dev-list; Thu, 20 Jan 2000 11:39:02 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id LAA23607 for ; Thu, 20 Jan 2000 11:39:01 -0500 Received: from [10.1.0.2] ([24.28.72.78]) by mail.austin.rr.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 20 Jan 2000 10:41:49 -0600 User-Agent: Microsoft Outlook Express Macintosh Edition - 5.0 (1513) Date: Thu, 20 Jan 2000 10:41:16 -0600 Subject: Re: Term::ANSIColor.pm From: David Blache To: Infobot development list Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O Helloooooooo...are my posts making it to the list?? on 1/17/2000 9:49 PM, David Blache wrote: > on 12/22/1999 8:14 AM, Kevin Lenzo wrote: > >> Note: It will be much prettier if you have Term::ANSIColor.pm. > > Where can I get this? > > Also is 0.49_03 irc-capable yet? > From infobot-dev@metronomicon.com Thu Jan 20 11:42:28 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id LAA23829 for infobot-dev-list; Thu, 20 Jan 2000 11:42:28 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from othersideofthe.earth.li (IDENT:qmailr@othersideofthe.earth.li [210.145.136.209]) by token.metronomicon.com (8.9.3/8.8.7) with SMTP id LAA23815 for ; Thu, 20 Jan 2000 11:42:26 -0500 Received: (qmail 18591 invoked by uid 500); 20 Jan 2000 16:44:49 -0000 Date: Fri, 21 Jan 2000 01:44:49 +0900 From: Simon Cozens To: Infobot development list Subject: Re: Term::ANSIColor.pm Message-ID: <20000121014449.A18580@othersideofthe.earth.li> Reply-To: Simon Cozens References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from David Blache on Thu, Jan 20, 2000 at 10:41:16AM -0600 X-Operating-System: Linux othersideofthe.earth.li 2.2.13 Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O On Thu, Jan 20, 2000 at 10:41:16AM -0600, David Blache wrote: > Helloooooooo...are my posts making it to the list?? That one is. > on 1/17/2000 9:49 PM, David Blache wrote: That one didn't. > > on 12/22/1999 8:14 AM, Kevin Lenzo wrote: > >> Note: It will be much prettier if you have Term::ANSIColor.pm. > > Where can I get this? CPAN, where else? :) Try http://www.cpan.org/modules/by-module/Term/ or your local mirror. -- He's just a politician trying to save both his faces... From infobot-dev@metronomicon.com Thu Jan 20 14:27:20 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id OAA24752 for infobot-dev-list; Thu, 20 Jan 2000 14:27:09 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from kiev.wall.org (kiev.wall.org [205.178.11.135]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id OAA24749 for ; Thu, 20 Jan 2000 14:27:06 -0500 Received: by kiev.wall.org (8.9.3/8.9.3) id LAA08774; Thu, 20 Jan 2000 11:27:54 -0800 (PST) Date: Thu, 20 Jan 2000 11:27:54 -0800 (PST) From: Larry Wall Message-Id: <200001201927.LAA08774@kiev.wall.org> To: scozens@pwj.co.jp Cc: infobot-dev@infobot.org, lenzo@cs.cmu.edu, larry@wall.org Subject: Re: a propos of artificial intelligence, linguistics, and geckos In-Reply-To: <4925686C.0019F820.00@pwj-gw-n001.pwj.co.jp> (from scozens@pwj.co.jp on Thu, 20 Jan 2000 14:25:04 +0900) Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O scozens@pwj.co.jp writes: : By all means reach for the stars, but never forget to keep : your feet on the ground. When it comes down to it, only : the code matters. Hmm, you just contradicted yourself. I agree with the first statement, but not with the second. In fact, the big idea from tagmemics is that the code is useless without a context. Latin is a "dead" language precisely because there's no living culture around it. It has a code, and people can even read the code, but it doesn't much matter. A culture can create a language if it doesn't have one (see pidgin), but even so great a language as Latin cannot create a culture once it is lost. In fact, only one dead language has ever managed to resurrect itself, namely Hebrew. But that's only because the culture survived and chose to resurrect it. And the only way a manufactured language like Esperanto, Lojban, Quenya, or Klingon can ever succeed is if a culture decides to adopt them. Otherwise nobody will ever teach those languages to their children as a first language. In this light, Perl succeeded only because it managed to get itself adopted by Unix culture, and later by Web culture. Larry From infobot-dev@metronomicon.com Thu Jan 20 14:46:43 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id OAA25026 for infobot-dev-list; Thu, 20 Jan 2000 14:46:41 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from mail.netrus.net (mail.netrus.net [206.251.192.232]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id OAA25022 for ; Thu, 20 Jan 2000 14:46:40 -0500 Received: from rocco (abuse@dialin-pm3-miami-FL-2-113.netrus.net [206.251.198.113]) by mail.netrus.net (8.8.8/8.8.8) with SMTP id OAA13495; Thu, 20 Jan 2000 14:48:51 -0500 Message-Id: <200001201948.OAA13495@mail.netrus.net> From: "Rocco Caputo" To: "infobot-dev@infobot.org" , "Jay Jacobs" Date: Thu, 20 Jan 2000 14:48:51 -0500 (EST) Reply-To: "Rocco Caputo" X-Mailer: PMMail 2.10.1999 for OS/2 Warp 4.00 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: a propos of artificial intelligence, linguistics, and geckos Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O On Thu, 20 Jan 2000 01:09:36 -0600 (CST), Jay Jacobs wrote: >On Thu, 20 Jan 2000 scozens@pwj.co.jp wrote: >> We're also seeing the communication aspect coming up, which is >> an important issue. (Are we starting to model social patterns?) >> What do *you* do when you need to find something out? You >> either already know it (it's in your DBM, as it were) or you >> can ask someone else, you can look it up on the web or in an >> encyclopaedia. In some situations, you may think you've got the >> answer, but it doesn't seem to fit the question somehow. A >> human can tell pretty easily when he's got the wrong reference >> source for a topic; the query has a series of mental >> associations. When we're looking up quavers, we can usually >> work out if the answer's supposed to relate to music or cheesy >> potato chips. We're about to hit a really nasty knowledge >> representation issue here. > >wow. > > I'm only going to comment on the first one... I started thinking about >information validity. It sounds like the path is being paved to a much >smarter AI, and information validity will be a key component. Everyone >who's run an infobot knows how much invalid data is scraped from IRC, so >I see these main topics: > > How and where to get and accept information. Accept liberally, and consider the source. Is it some stranger? Is it the producer of quality factoids? What defines quality? Karma? The number of factoids that haven't been erased or overwritten by someone else? Peer review, perhaps with a karma-like system? > How to process and reference, and relate information. I have been cross-referencing ambiguous factoid keys or related values on purl, the EFNet #perl infobot. It's as simple as: intermezzo is (see: inter-mezzo) It would be interesting if infobot could follow the links, pulling out the "inter-mezzo" factoid even when someone asks about "intermezzo". That brings up issues like: Should changes to intermezzo be propagated to inter-mezzo, or should factoids be copy-on-write? Probably the former, but I'm not willing to say always. use Can::Worms; my $can = new Can::Worms; $can->open(); The problem becomes harder if a link accompanies other information; following it should be the reader's job. For example, the referenced "poe slides" factoid may have only a tenuous connection to "inter-mezzo": inter-mezzo is a distributed file system at http://www.inter-mezzo.org/ (see: poe slides) or version 001 is 90% lethal > How to store new information for future refence. > > How to detect and remove bogus information that's already stored. The human brane seems to forget least-used information. How safe would it be for geckobot to quietly prune deadwood? What defines deadwood? Age since last recollection? Relative fetch frequency? Accumulators that increase by different amounts depending on the access method (i.e., directed fetches, like "geckobot: factoid" count more than undirected ones like "factoid?") and decay gradually over time? For the paranoid, decayed factoids could appear in a report instead of die off quietly. They could also be presented in a form-based factoid manager, which, if geckobot's current design works out, may possibly be integrated into the bot as a personal web server. >[... removed by troc@netrus.net] Of course, I'm handwaving a whole helluvalotta details. Grains of salt available upon request. -- Rocco Caputo / troc@netrus.net From infobot-dev@metronomicon.com Thu Jan 20 16:42:46 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id QAA25790 for infobot-dev-list; Thu, 20 Jan 2000 16:42:26 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from ux1.sp.cs.cmu.edu (UX1.SP.CS.CMU.EDU [128.2.198.101]) by token.metronomicon.com (8.9.3/8.8.7) with SMTP id QAA25787 for ; Thu, 20 Jan 2000 16:42:25 -0500 Received: from PROTECTED.SPEECH.CS.CMU.EDU by ux1.sp.cs.cmu.edu id aa26585; 20 Jan 2000 16:44 EST Message-ID: <38878242.F45E11FF@cs.cmu.edu> Date: Thu, 20 Jan 2000 16:46:42 -0500 From: Kevin Lenzo Organization: School of Computer Science, Carnegie Mellon University X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Larry Wall CC: scozens@pwj.co.jp, infobot-dev@infobot.org Subject: Re: a propos of artificial intelligence, linguistics, and geckos References: <200001201927.LAA08774@kiev.wall.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O Hi, For everyone who asked about the Pike reference: Tagmemics Discourse and Verbal Art by Kenneth L Pike $6 from Amazon. they actually got me a copy. I left out the word "most" from "recent" in the prior email, but it's actually from 1981. I ordered Linguistic Concepts : An Introduction to Tagmemics also, but that one they haven't gotten to yet -- it's been a couple of months. In 'discourse' there are three short papers that are easy to read but cover a whole lot of ground. In one of them he discusses the linguistic complexity in the assembly instructions (and carrying them out) for a bbq grill; in the second he outlines tagmemics; and in the third he talks about the time in a narrative or discourse in relation to the actual events. The second paper is particularly nifty, as Pike reflexively puts himself into the analysis. I sat down and read the whole thing without getting up. kevin From infobot-dev@metronomicon.com Thu Jan 20 19:30:26 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id TAA27100 for infobot-dev-list; Thu, 20 Jan 2000 19:30:22 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from ux1.sp.cs.cmu.edu (UX1.SP.CS.CMU.EDU [128.2.198.101]) by token.metronomicon.com (8.9.3/8.8.7) with SMTP id TAA27097 for ; Thu, 20 Jan 2000 19:30:21 -0500 Received: from ip170.pittsburgh6.pa.pub-ip.psi.net by ux1.sp.cs.cmu.edu id aa29484; 20 Jan 2000 19:32 EST Message-ID: <3887A82D.43E1AB67@cs.cmu.edu> Date: Thu, 20 Jan 2000 19:28:29 -0500 From: Kevin Lenzo Organization: School of Computer Science, Carnegie Mellon University X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: David Blache CC: Infobot development list Subject: Re: Term::ANSIColor.pm References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O That's a big negatory on the IRC with the new bot yet. I think maybe end of next week if we're lucky. kevin David Blache wrote: > > Helloooooooo...are my posts making it to the list?? > > on 1/17/2000 9:49 PM, David Blache wrote: > > > on 12/22/1999 8:14 AM, Kevin Lenzo wrote: > > > >> Note: It will be much prettier if you have Term::ANSIColor.pm. > > > > Where can I get this? > > > > Also is 0.49_03 irc-capable yet? > > From infobot-dev@metronomicon.com Thu Jan 20 21:41:00 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id VAA27814 for infobot-dev-list; Thu, 20 Jan 2000 21:40:57 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from asec50.pwj.co.jp (IDENT:root@asec50.pwj.co.jp [202.32.76.250]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id VAA27811 for ; Thu, 20 Jan 2000 21:40:52 -0500 From: scozens@pwj.co.jp Received: from asec12.pwj.co.jp (barrier1.pwj.co.jp [202.32.76.1] (may be forged)) by asec50.pwj.co.jp (8.9.3/3.7W) with ESMTP id LAA13473; Fri, 21 Jan 2000 11:49:08 +0900 (JST) Received: from pwj-gw-n001.pwj.co.jp (mailhost [10.159.99.13]) by asec12.pwj.co.jp (8.9.2/3.7W) with SMTP id LAA25663; Fri, 21 Jan 2000 11:47:58 +0900 (JST) Received: by pwj-gw-n001.pwj.co.jp(Lotus SMTP MTA Internal build v1.2 hotfix4 (684.3 7-31-1998)) id 4925686D.000EE69C ; Fri, 21 Jan 2000 11:42:45 +0900 X-Lotus-FromDomain: PRICE WATERHOUSE-JAPAN To: troc@netrus.net cc: infobot-dev@infobot.org Message-ID: <4925686D.00088672.00@pwj-gw-n001.pwj.co.jp> Date: Fri, 21 Jan 2000 11:41:28 +0900 Subject: Re: (null) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O (This is a reply to an email sent to me privately, but I'm copying the response to the list because I feel it is interesting for infobot development, especially since it refers to the devel series.) Rocco Caputo writes: > If geckobot's using POE, the Filter::Reference will let you pass > around Perl structures. It freezes them on the sender's side and > thaws them on the receiver's. Send syntax is basically: > $wheel->put(\@thing) > On the receiving end, you get an event that says "you got this > thing, \@thing". Eee. Um. That's nice, but... isn't it a little trusting? I mean, is there some negotiation first, or do you indiscriminately receive anything sent to you? Presumably you'll use the received thing as a Perl object, and maybe execute methods on it, and the idea of running arbitrary untrusted subs is rather scary for me. Sure, it's fine if we're just passing around factoids and meta-data, but once you get code coming across, I wouldn't touch it with a big stick. > Artur/Sky has a patch pending that lets it use Compress::Zlib > transparently, so network traffic can be balanced against CPU. Oh, wow. That's special. > On the decentralized side, factoids could be propagated like > Usenet news messages. Factoids won't get lost if there are > redundant paths. OK, let's take this principle and run with it. Here's my complete train of thought on how interbot is going to work if we go with a peer-to-peer network. How you traverse it is up to you, but I've tried to make it a DFA. :) i) Infobots have a set of peers. If we're really lucky, these peers form a k-connected graph. ->ii,iii,v ii) How do you discover how your peers are? Either we hard code in config files, or we automatically discover. If we're going to discover, which I'd prefer because `discovery' is my programming buzzword of the moment, we'll need some sort of central registration scheme for infobots. You choose your peers by who's networkologically close to you. If you're going to go to a central registry, though, you might want to ditch the idea and go with something either massively-connected (all bots connect to all other bots) or maybe a star-based topology where everone connects to a MetaBot which forwards and proxies (and caches, yes!) queries. You also lose the distributed nature of the network to a single point of failure. Or should there be multiple proxy bots? How many levels can you go that way? -> xii iii) Are peerings bi-directional? Usenet feeds are (generally) two-way; I can receive news from my peers, and I post news to them as well. I'm named in their config files, and they're named in mine. -> iv iv) Does an information request from a bot need to be any different from an information request from a human? -> viii v) A request for information goes out to all peers, each of which replies if they know the answer. ->vi,vii vi) We may receive two conflicting answers. Do we simply take the first one? Or can we invent a way of validating which is more appropriate? If so, do we keep both factoids anyway? In short, how are different factoids going to co-exist in a distributed knowledge base? -> xii vii) How do we propagate the search further? We need a sense of a return Path and a way to terminate the search if we've found the information. Usenet provides a `cancel' control message to do this, effectively. But where do we store state data about a query? -> viii, x viii) Ideally we'd have a response look the same at every level, whether initiated by a human, a bot or another bot further down the chain, just to make implementation nice and easy. Why should the bot have to care whether it's talking to me or to another bot? So, we'd have a message ID stored *locally* keying what went to whom and who it's for. -> ix) ix) However, we can't sent the message ID out if we want it to be transparent, since I'm a human and I wouldn't send out a message ID with my queries. So, we have a situation like this: Human: BotA, tell me about hoge BotA - need to tell Human about hoge, add to to-do list. don't know about hoge. ask peers, [and this is the key!] go back to the event loop. BotA: Human, sorry, don't know. I'll see if I can find out. BotA: BotB, tell me about hoge BotA: BotC, tell me about hoge BotA: BotD, tell me about hoge BotB - need to tell BotA about hoge. don't know about hoge. ask peers. .... BotF - need to tell BotC about hoge. BotF: BotC, hoge is the Japanese for foo. BotC - recieved new factoid `hoge'. Checking to-do list. Have to tell BotA about `hoge'. Clear `hoge'->BotA from to-do list. BotC: BotA, hoge is the Japanese for foo. BotA - recieved new factoid `hoge'. Checking to-do list. Have to tell Human about `hoge'. Clear `hoge'->Human from to-do list. BotA: Human, hoge is the Japanese for foo. [Hence, there was no need to keep state data. However... -> x] x) So, we can reliably pass information between bots and humans without keeping any state *in the message* or distinguishing between human queries, bot queries and second (n'th) -level bot queries. BUT... if we have a k-connected graph, which is nice for redundancy, yet we're not keeping track of who's asked who what, how on earth do we exhaust the search? -> xi xi) I guess one solution may be, when receiving the `will try to find out' message, check whether we have this from all peers, and if so report `none of my peers know about this'. This will prune that particular branch of the search. But is that now guaranteed to find-or-fail in all circumstances? (I can't get my head around the topology of this) And how to we code it into an event loop? -> xii xii) Don't know. > I have too many ideas and not enough implementation. You and me both. Simon From infobot-dev@metronomicon.com Thu Jan 20 22:31:15 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id WAA28282 for infobot-dev-list; Thu, 20 Jan 2000 22:31:13 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from pixie.securenets.com (what.securetty.org [63.225.132.243]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id WAA28279 for ; Thu, 20 Jan 2000 22:31:12 -0500 Received: from localhost (jjacobs@localhost) by pixie.securenets.com (8.9.1/8.9.1) with SMTP id VAA01302; Thu, 20 Jan 2000 21:31:16 -0600 Date: Thu, 20 Jan 2000 21:31:15 -0600 (CST) From: Jay Jacobs X-Sender: jjacobs@pixie.securenets.com To: scozens@pwj.co.jp cc: troc@netrus.net, infobot-dev@infobot.org Subject: Re: (null) In-Reply-To: <4925686D.00088672.00@pwj-gw-n001.pwj.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O I see three possibilities: i) really chatty bots ii) really slow bots iii) really smart bots with a mixture somewhere in the middle probably being the outcome. Plus if any joe can run an infobot and be "discovered" and have their factoids shared, bad things are inevitable: "teehee, I made purl say 'poop'". There should not only be weight given to factoids, but weight given to bots. Trust should be gained. Even that is tricky, there are a lot of really bored kids out there. On the flip side, I don't think the solution is 'discovery', instead it should be moderated groups. Look at the IRC structure. There are a series of hoops to jump through to get an IRC server into efnet, the 'buzz' of discovery can happen after it's been configured into one of the hosts in the group, with some sort of security mechanism (public/private keys..?). Jay On Fri, 21 Jan 2000 scozens@pwj.co.jp wrote: > > > (This is a reply to an email sent to me privately, but I'm copying > the response to the list because I feel it is interesting for infobot > development, especially since it refers to the devel series.) > > > Rocco Caputo writes: > > If geckobot's using POE, the Filter::Reference will let you pass > > around Perl structures. It freezes them on the sender's side and > > thaws them on the receiver's. Send syntax is basically: > > $wheel->put(\@thing) > > On the receiving end, you get an event that says "you got this > > thing, \@thing". > > Eee. Um. That's nice, but... isn't it a little trusting? I mean, > is there some negotiation first, or do you indiscriminately receive > anything sent to you? Presumably you'll use the received thing as a > Perl object, and maybe execute methods on it, and the idea of > running arbitrary untrusted subs is rather scary for me. Sure, it's > fine if we're just passing around factoids and meta-data, but once > you get code coming across, I wouldn't touch it with a big stick. > > > Artur/Sky has a patch pending that lets it use Compress::Zlib > > transparently, so network traffic can be balanced against CPU. > > Oh, wow. That's special. > > > On the decentralized side, factoids could be propagated like > > Usenet news messages. Factoids won't get lost if there are > > redundant paths. > > OK, let's take this principle and run with it. Here's my complete > train of thought on how interbot is going to work if we go with a > peer-to-peer network. How you traverse it is up to you, but I've tried > to make it a DFA. :) > > i) Infobots have a set of peers. If we're really lucky, these peers > form a k-connected graph. ->ii,iii,v > > ii) How do you discover how your peers are? Either we hard code in > config files, or we automatically discover. If we're going to discover, > which I'd prefer because `discovery' is my programming buzzword of > the moment, we'll need some sort of central registration scheme > for infobots. You choose your peers by who's networkologically > close to you. If you're going to go to a central registry, though, > you might want to ditch the idea and go with something either > massively-connected (all bots connect to all other bots) or maybe > a star-based topology where everone connects to a MetaBot which > forwards and proxies (and caches, yes!) queries. You also lose > the distributed nature of the network to a single point of failure. > Or should there be multiple proxy bots? How many levels can you go > that way? -> xii > > iii) Are peerings bi-directional? Usenet feeds are (generally) > two-way; I can receive news from my peers, and I post news to > them as well. I'm named in their config files, and they're named > in mine. -> iv > > iv) Does an information request from a bot need to be any different > from an information request from a human? -> viii > > v) A request for information goes out to all peers, each of which > replies if they know the answer. ->vi,vii > > vi) We may receive two conflicting answers. Do we simply take the > first one? Or can we invent a way of validating which is more > appropriate? If so, do we keep both factoids anyway? In short, > how are different factoids going to co-exist in a distributed > knowledge base? -> xii > > vii) How do we propagate the search further? We need a sense of > a return Path and a way to terminate the search if we've found > the information. Usenet provides a `cancel' control message to > do this, effectively. But where do we store state data about a > query? -> viii, x > > viii) Ideally we'd have a response look the same at every level, > whether initiated by a human, a bot or another bot further > down the chain, just to make implementation nice and easy. Why > should the bot have to care whether it's talking to me or to > another bot? So, we'd have a message ID stored *locally* keying > what went to whom and who it's for. -> ix) > > ix) However, we can't sent the message ID out if we want it to > be transparent, since I'm a human and I wouldn't send out a > message ID with my queries. So, we have a situation like this: > > Human: BotA, tell me about hoge > > BotA - need to tell Human about hoge, add to to-do list. > don't know about hoge. ask peers, [and this is the key!] > go back to the event loop. > > BotA: Human, sorry, don't know. I'll see if I can find out. > > BotA: BotB, tell me about hoge > BotA: BotC, tell me about hoge > BotA: BotD, tell me about hoge > > BotB - need to tell BotA about hoge. don't know about hoge. > ask peers. > .... > > BotF - need to tell BotC about hoge. > > BotF: BotC, hoge is the Japanese for foo. > > BotC - recieved new factoid `hoge'. Checking to-do list. > Have to tell BotA about `hoge'. Clear `hoge'->BotA from > to-do list. > > BotC: BotA, hoge is the Japanese for foo. > > BotA - recieved new factoid `hoge'. Checking to-do list. > Have to tell Human about `hoge'. Clear `hoge'->Human from > to-do list. > > BotA: Human, hoge is the Japanese for foo. > > [Hence, there was no need to keep state data. However... -> x] > > x) So, we can reliably pass information between bots and humans > without keeping any state *in the message* or distinguishing between > human queries, bot queries and second (n'th) -level bot queries. > BUT... if we have a k-connected graph, which is nice for redundancy, > yet we're not keeping track of who's asked who what, how on earth > do we exhaust the search? -> xi > > xi) I guess one solution may be, when receiving the `will try > to find out' message, check whether we have this from all peers, > and if so report `none of my peers know about this'. This will > prune that particular branch of the search. But is that now > guaranteed to find-or-fail in all circumstances? (I can't get my > head around the topology of this) And how to we code it into an > event loop? -> xii > > xii) Don't know. > > > I have too many ideas and not enough implementation. > > You and me both. > > Simon > > From infobot-dev@metronomicon.com Thu Jan 20 22:40:04 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id WAA28419 for infobot-dev-list; Thu, 20 Jan 2000 22:40:04 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from ux1.sp.cs.cmu.edu (UX1.SP.CS.CMU.EDU [128.2.198.101]) by token.metronomicon.com (8.9.3/8.8.7) with SMTP id WAA28416 for ; Thu, 20 Jan 2000 22:40:03 -0500 Received: from ip170.pittsburgh6.pa.pub-ip.psi.net by ux1.sp.cs.cmu.edu id aa01600; 20 Jan 2000 22:42 EST Message-ID: <3887D4BB.7C21FB90@cs.cmu.edu> Date: Thu, 20 Jan 2000 22:38:35 -0500 From: Kevin Lenzo Organization: School of Computer Science, Carnegie Mellon University X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: infobot-dev@infobot.org Subject: Re: (null) References: <4925686D.00088672.00@pwj-gw-n001.pwj.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O ping, scozens@pwj.co.jp wrote: .. > Rocco Caputo writes: .. > > On the receiving end, you get an event that says "you got this > > thing, \@thing". > > Eee. Um. That's nice, but... isn't it a little trusting? I mean, .. it depends on how \@thing is vivified. Yes it is trusting -- we have the whole sandbox issue, like java and jini. authentication, encryption, validation -- Entities have identity, and even Infobot::Modules have to negotiate who can do what to who when. If there is a way to alias and resolve an entity and refer to an entity instance in the object store, there also has to be a way to make sure you're talking to the real one and even perhaps that you cannot be overheard. back to vivification. if Infobot=HASH(), or its image, is seen in the serialized form (as with using Leolo's XML::Storable), the object getting the reference should make appropriate moves to vivify the code of an object from the _internal_, safe store. i'm not sure how the ref server does this, but i think the vivification mechanism puts a lot of the burden of security onto the users faith in their internal code, which is pretty much on par with using modules. and modules, it seems, should be able to authenticate and secure channels as any other Entity might... hmm. > > > Artur/Sky has a patch pending that lets it use Compress::Zlib > > transparently, so network traffic can be balanced against CPU. > > Oh, wow. That's special. Do we have Filter::PGP yet? That or something like it would help move the burden of authentication. You could trust some hosts more than others for certain types of transfer -- like tainted 'references' that might vivify into evaled perl code. > > On the decentralized side, factoids could be propagated like > > Usenet news messages. Factoids won't get lost if there are > > redundant paths. > > OK, let's take this principle and run with it. Here's my complete > train of thought on how interbot is going to work if we go with a > peer-to-peer network. How you traverse it is up to you, but I've tried > to make it a DFA. :) .. Phew! OK i have some ideas to throw into the pot here. The way the new bot is composed, a Message object gets created when something happens. This message basically takes on a life of its own -- the message is the thread. This message object can be passed from entity to entity, and each one can act on it, decorate it, edit it, etc, and pass it on. These entities theoretically should not have to be in the same program or on the same machine. This is why Parse::RecDescent won't work for us. The message has to pass through the machine, where unknown parts at an unknown distance recognize strange languages. The message can burrow into other bots and come back with a reply. The message needs to have a routing policy, though, and the entities sending and possibly expecting replies should be able to stick plans inside the message itself. Strategy (not implemented) should make a graph of known entity instances and create a routing policy inside the message, perhaps encoded in the message directly by the originating entity instance. Since the message itself is an object, though, it does sort of have an animist quality. The messages start doing things _on their own_. For instance, a message might create a password subdialog, which would push the expectation of a password onto the listening interface, and respond to the correct and incorrect password differently. So the message isn't just the first pass of the message until the reply, it can be something hanging around with an agenda. As far as how messages propagate, if a set of bots are known, these bots will have policies on query forwarding for certain classes or hosts. For all the know bots we can use Kruskal's algorithm or something to get a minimal spanning tree. I worked out a simple algorithm i called 'N-coloring' that probably is much better done by some well-known routing algorithm, but we're probably best off with something simple to start with -- like knowing where all the bots are. ircd issues a CONNECT when a new server comes up, that seems ok. we might want something more anonymous (things behind things) later. Cycles in the connection graph seem like a Good Thing for redundancy, but ircd avoided it for complexity reasons. Most services will not be remote. I don't want another bot asking me to get a web page for it, for instance. I'm happy to give factoids to a remote bot but i wouldn't want it to be soaking up my resources when it could be doing it itself. So interbot can pretty much be raw command and database access -- and the message is instantiated with a different plan (routing path) through the entities and using Language::Interbot rather than Language::Nahuatl. > > > I have too many ideas and not enough implementation. > > You and me both. > > Simon woohoo! i got interbot.org :) kevin From infobot-dev@metronomicon.com Thu Jan 20 23:28:18 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id XAA29038 for infobot-dev-list; Thu, 20 Jan 2000 23:28:14 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from asec50.pwj.co.jp (IDENT:root@asec50.pwj.co.jp [202.32.76.250]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id XAA29035 for ; Thu, 20 Jan 2000 23:28:08 -0500 From: scozens@pwj.co.jp Received: from asec12.pwj.co.jp (barrier1.pwj.co.jp [202.32.76.1] (may be forged)) by asec50.pwj.co.jp (8.9.3/3.7W) with ESMTP id NAA06453 for ; Fri, 21 Jan 2000 13:36:27 +0900 (JST) Received: from pwj-gw-n001.pwj.co.jp (mailhost [10.159.99.13]) by asec12.pwj.co.jp (8.9.2/3.7W) with SMTP id NAA18794 for ; Fri, 21 Jan 2000 13:35:16 +0900 (JST) Received: by pwj-gw-n001.pwj.co.jp(Lotus SMTP MTA Internal build v1.2 hotfix4 (684.3 7-31-1998)) id 4925686D.0018BAC1 ; Fri, 21 Jan 2000 13:30:06 +0900 X-Lotus-FromDomain: PRICE WATERHOUSE-JAPAN To: infobot-dev@infobot.org Message-ID: <4925686D.0013B146.00@pwj-gw-n001.pwj.co.jp> Date: Fri, 21 Jan 2000 13:28:50 +0900 Subject: Re: Trust and Discovery Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O > I see three possibilities: > i) really chatty bots > ii) really slow bots > iii) really smart bots Let's see if I can remember the saying: quick, reliable, cheap : choose two, you can't have all three. > Plus if any joe can run an infobot and be "discovered" and have > their factoids shared, bad things are inevitable: > "teehee, I made purl say 'poop'". This happens already, and is, I suspect, a deliberate decision - purl is not only a *member* of the community, but a *reflection* of it. > There should not only be weight given to factoids, but weight given to > bots. Trust should be gained. This isn't as hard as it sounds, so long as you're prepared to solve some fairly fundamental artificial intelligence problems along the way. How it would work is this: Factoid not found. Ask peers. One response -> Add response to database, do not alter trust. Two responses -> Choose response from most trusted bot then proceed as below. More than one response -> Compare all factoids, rank by similarity*. Choose response from most trusted bot from factoids that are similar. Add trust to all bots producing factoids similar to chosen one, remove trust from bots producing differing factods. * Yes, this part is impossible. Not to worry. We'll work something out. So, your bot asks `what is a square?' Responses: BotA (Trust 3) : A square is a four-sided shape BotB (Trust 3) : Poo! BotC (Trust 8) : A square is a shape with four corners BotD (Trust 9) : A square is foo bar baz BotE (Trust 5) : A square is four lines connected by right-angles. Sort response by similarity and trustworthiness: BotB BotD BotE BotA BotC Select BotC's answer. Alter trust: BotB -2 BotD -2 BotE +3 BotA +3 BotC +3 Do we do this just for bots, or for humans too? > On the flip side, I don't think the solution is 'discovery', instead it > should be moderated groups. I'll explain what I mean by the concept of `discovery' because it's featuring more and more strongly these days in my programming and programming philosophy, and I want to evangelise it. :) (If you like this way of programming, forward it to some interesting people; I haven't the confidence. :-) The idea is twofold: that the computer should take as much work from the human as it can, doing almost everything without intervention; and that the computer finds out things only when it is asked to, or (and this is the clever bit) when it needs to in order to discover something else. Oh, and a third idea: I don't like hard-coding stuff. The way I typically program a `discovery engine' is to have a hash full of things to be discovered, which are represented as sub refs. I use a cunning tie such that when the hash is accessed, the sub ref is fired off and the return value takes its place in the hash, caching it. So, let's take a very, very basic example from my system configuration discovery engine. %engine = { uname => \&discover_uname, where_uname => \&discover_where_uname ... }; tie %sysconf,"Discovery",%engine; # Maybe I should put this on CPAN. sub uname { `$sysconf{where_uname}` } sub where_uname { _find_in_path("uname") } So, when I ask for $sysconf{uname}, the program hits &uname, which would run the uname command and return the value. In order to run the uname command, we need to find out where it is - we have a data dependency - so we ask for $sysconf{where_uname}. If we've already found this out for some other purpose, we can just return it. Else, we fire off another sub, which looks in the path for the command, and returns it. No data dependency here, but I have some discovery engines that go five or six deep. It's fast, it keeps the program moving, and it's a cool design, allowing you to do really neat top-down (or bottom-up, at your choice) programming in quite an obvious way. I've done this for system configuration, for my CTAN module, and I'm strongly considering using it in the rewrite of Perl's Configure I'm doing. (if crazyperl supports ties, grumble grumble.) How would we discover infobot peers this way? We need a list of infobots, so we send out for one. We try a few places and see if we can find one. (This might even require us to discover what sort of Internet connection we've got, how we can retrieve web pages, (a la CPAN.pm) and all that mundane stuff.) We then need to ping all the infobots to see which are close. We send out for the best method of pinging (`ping`, Net::Ping (UDP or TCP?), special infobot TCP ping?) and ping each bot. We investigate the nearest bots, maybe even seeing how much they trust the bots around them, how many peers they have, how many factoids they possess and so on. These are things we go off and discover for ourselves. Then we take the results, and choose our peers. Finally, we let the chosen bots know we'll be peering with them, so they know to rate us for trustworthiness. Cool, eh? Simon From infobot-dev@metronomicon.com Fri Jan 21 01:10:41 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id BAA29636 for infobot-dev-list; Fri, 21 Jan 2000 01:10:36 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from jupter.evolving.org (IDENT:root@tsp-3.dsl.speakeasy.net [216.231.35.57]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id BAA29633 for ; Fri, 21 Jan 2000 01:10:35 -0500 Received: from localhost (root@localhost) by jupter.evolving.org (8.9.3/8.9.3) with ESMTP id AAA01452 for ; Fri, 21 Jan 2000 00:20:47 -0500 Date: Fri, 21 Jan 2000 00:20:46 -0500 (EST) From: root To: infobot-dev@infobot.org Subject: BotTalk In-Reply-To: <4925686D.0013B146.00@pwj-gw-n001.pwj.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O Hi, I've been a lurker for awhile, but I'd like to share some ideas tonight. Creating smart infobot networks is a really fun problem, and yakking about design is the best part of problem solving. Anyway, I think there's a very elegant solution to this, lets see if I can think it thru here. Bot networks should be grouped into an AS(autonomus system). Auth info may or may not be required. Each bot holds a status table, consisting of the name of the each member in the AS, ID#, Ping time, and LastSpoken time. This Status. Table serves as the routing table for the AS. The first issue, is the glue that makes up the AS. How the entities exchange status infomation in a sane way. I prefer learning most info passively, and when circumstance require actively. When a bot connects, it's gets a copy of a status table, then says hello to everybody. When it says hello to everyone, and everyone says hi back. It remembers how long it took. Now, everyone has a clear picture of the AS. Now lets Chat! One to one message types are obviously one to one. General queries should broadcast, because it saves time, and it saves bandwidth. If you go with a token model, you need to have ACKS to ensure continuity. Token messages should be used for HELLO type messages, and other status messages. The protocol goes like so, the originator sends out the token to it's speediest friend. He looks at it, adds his name, and sends it to his speediest friend. If his friend doesn't answer he drops his friends name from his table and sends a CHECK{FRIEND} token out. He sends the original token on it's merry way, minus his sleeping friend. If somebody notices a name that they don't have, he requests this unknown guy to re-authenticate to everyone using his table. This uses the same method used when a new bot connects. When it gets to the last friend, he realizes this because the token has everyone else in it, he adds himself and sends it to the originator. This one token has threaded out to other tokens and synchronized the status table. Tokens require ack and should be used sparingly. Thats basically what I think, any suggestions? From infobot-dev@metronomicon.com Fri Jan 21 01:35:19 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id BAA30000 for infobot-dev-list; Fri, 21 Jan 2000 01:35:17 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from pixie.securenets.com (what.securetty.org [63.225.132.243]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id BAA29997 for ; Fri, 21 Jan 2000 01:35:17 -0500 Received: from localhost (jjacobs@localhost) by pixie.securenets.com (8.9.1/8.9.1) with SMTP id AAA02066; Fri, 21 Jan 2000 00:36:40 -0600 Date: Fri, 21 Jan 2000 00:36:40 -0600 (CST) From: Jay Jacobs X-Sender: jjacobs@pixie.securenets.com Reply-To: Jay Jacobs To: infobot-dev@infobot.org cc: root Subject: Re: BotTalk In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O Yeah... On Fri, 21 Jan 2000, root wrote: > Bot networks should be grouped into an AS(autonomus system). > Auth info may or may not be required. > Each bot holds a status table, consisting of the name of the each member > in the AS, ID#, Ping time, and LastSpoken time. > This Status. Table serves as the routing table for the AS. > > The first issue, is the glue that makes up the AS. How the entities > exchange status infomation in a sane way. I prefer learning most > info passively, and when circumstance require actively. > > When a bot connects, it's gets a copy of a status table, then says hello > to everybody. When it says hello to everyone, and everyone says hi back. > It remembers how long it took. Now, everyone has a clear picture of the > AS. Now lets Chat! > > One to one message types are obviously one to one. > > General queries should broadcast, because it saves time, and it > saves bandwidth. If you go with a token model, you need to have ACKS to > ensure continuity. I don't think we want to get into ACKs. I would vote for the UDP theory since it's essentially asynchronous communication. Send out a request and move on, wait for, or process the next event. If you get a response(s), great, deal with it, if not, you've already moved on anyway, but perhaps come back to acknowledge the original request with "I dunno". It might be different if we're talking threads... But UDP would be less overhead anyway. > Token messages should be used for HELLO type messages, and other status > messages. The protocol goes like so, the originator sends out the token > to it's speediest friend. He looks at it, adds his name, and sends it to > his speediest friend. If his friend doesn't answer he drops his friends > name from his table and sends a CHECK{FRIEND} token out. He sends the > original token on it's merry way, minus his sleeping friend. If somebody > notices a name that they don't have, he requests this unknown guy to > re-authenticate to everyone using his table.. This uses the same method > used when a new bot connects. When it gets to the last friend, he > realizes this because the token has everyone else in it, he adds himself > and sends it to the originator. This one token has threaded out to other > tokens and synchronized the > status table. Tokens require ack and should be used sparingly. Yeah, I could see this kind of thing for initializing interbot communication... but I'm not quite kosher with the notion of tokens, unfortunately we'd probably want to 'sign' each message for verification, thus just blast what ya got out there. > > Thats basically what I think, any suggestions? Yeah, sign your email and use something other than "root" to send email ;) Jay From infobot-dev@metronomicon.com Fri Jan 21 02:18:20 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id CAA30411 for infobot-dev-list; Fri, 21 Jan 2000 02:18:17 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from mail.netrus.net (mail.netrus.net [206.251.192.232]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id CAA30408 for ; Fri, 21 Jan 2000 02:18:17 -0500 Received: from rocco (abuse@dialin-pm3-miami-FL-2-107.netrus.net [206.251.198.107]) by mail.netrus.net (8.8.8/8.8.8) with SMTP id CAA03934; Fri, 21 Jan 2000 02:19:21 -0500 Message-Id: <200001210719.CAA03934@mail.netrus.net> From: "Rocco Caputo" To: "scozens@pwj.co.jp" Cc: "infobot-dev@infobot.org" Date: Fri, 21 Jan 2000 02:19:10 -0500 (EST) Reply-To: "Rocco Caputo" X-Mailer: PMMail 2.10.1999 for OS/2 Warp 4.00 In-Reply-To: <4925686D.00088672.00@pwj-gw-n001.pwj.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: GeckoNet Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O Apologies for any incoherence throughout this document. Stream of consciousness runs fast and rough around the turns. :) On Fri, 21 Jan 2000 11:41:28 +0900, scozens@pwj.co.jp wrote: > >(This is a reply to an email sent to me privately, but I'm copying >the response to the list because I feel it is interesting for infobot >development, especially since it refers to the devel series.) > > >Rocco Caputo writes: >> If geckobot's using POE, the Filter::Reference will let you pass >> around Perl structures. It freezes them on the sender's side and >> thaws them on the receiver's. Send syntax is basically: >> $wheel->put(\@thing) >> On the receiving end, you get an event that says "you got this >> thing, \@thing". > >Eee. Um. That's nice, but... isn't it a little trusting? I mean, >is there some negotiation first, or do you indiscriminately receive >anything sent to you? Presumably you'll use the received thing as a >Perl object, and maybe execute methods on it, and the idea of >running arbitrary untrusted subs is rather scary for me. Sure, it's >fine if we're just passing around factoids and meta-data, but once >you get code coming across, I wouldn't touch it with a big stick. False for at least two reasons, one of which you can pin on me: First, the example \@thing is intended to be an unblessed Perl data structure. It's my fault for implying objectness by using the name "thing". I apologize for the confusion there. And B: Even if it were a blessed reference, Storable's freeze() and thaw() don't work the way you seem to expect. freeze() doesn't include code along with the blessed reference; thaw() doesn't inject strange code into your program. The receiver's code is its own. The rest of the code works the same either way. If it's an object, the receiver's package has validators and accessors. If it's a data packet, the receiver has a library of validation functions and just accesses the data direcly. And you can use ref() and can() to make sure the object is blessed properly. >> Artur/Sky has a patch pending that lets it use Compress::Zlib >> transparently, so network traffic can be balanced against CPU. > >Oh, wow. That's special. > >> On the decentralized side, factoids could be propagated like >> Usenet news messages. Factoids won't get lost if there are >> redundant paths. > >OK, let's take this principle and run with it. Here's my complete >train of thought on how interbot is going to work if we go with a >peer-to-peer network. How you traverse it is up to you, but I've tried >to make it a DFA. :) > >i) Infobots have a set of peers. If we're really lucky, these peers >form a k-connected graph. ->ii,iii,v > >ii) How do you discover how your peers are? Either we hard code in >config files, or we automatically discover. If we're going to discover, >which I'd prefer because `discovery' is my programming buzzword of >the moment, we'll need some sort of central registration scheme >for infobots. You choose your peers by who's networkologically >close to you. If you're going to go to a central registry, though, >you might want to ditch the idea and go with something either >massively-connected (all bots connect to all other bots) or maybe >a star-based topology where everone connects to a MetaBot which >forwards and proxies (and caches, yes!) queries. You also lose >the distributed nature of the network to a single point of failure. >Or should there be multiple proxy bots? How many levels can you go >that way? -> xii Discovery is harder, but I like it better. Hard problems are more fun, anyway. About central registries: An abbreviated DNS model might work. Set up a single open registrar for the geckobot network. Distribute its data among mirrors regularly. Hardcode the root cache into geckobot. Geckobots pull a copy of the peer database at install time, and they periodically update against it. This is my favorite choice so far. IRC makes an interesting star topology. Set up a small network of private servers, and have all the 'bots meet on a reserved channel. NO HUMANZ ALOWED!!! Are there any limits on channel sizes? If you want to go all crazy and impractical and stuff, set up a virtual private network, and put all the bots on the same subnet. Sling broadcast packets around: Hey, everyone on the subnet, tell me what ``foo'' is. [X number of ACKs saying: Foo is yatta yatta] [Y number of NAKs saying: I don't know] VPN is my other favorite choice, if I'm allowed to be a complete loon. >iii) Are peerings bi-directional? Usenet feeds are (generally) >two-way; I can receive news from my peers, and I post news to >them as well. I'm named in their config files, and they're named >in mine. -> iv I like UDP right now; it's my socket flavor of the week. They're comfy and easy to broadcast. At initial startup, the querist bot grabs a list of servers from one of the registrar sites or mirrors. It periodically updates this list, perhaps daily. Peerings are one-way: data is propagated by fetch only. How a querist asks peers for a factoid: Create a virtual connection pool; load the question "What is foo?" into it. Preload it with the N most appropriate peers. Appropriateness is gauged by willingness to answer past and the typical response time. Quicker peers float to the top, where they get hit more often. I assume this will balance out the overall bot-network load. To begin with, there may be a few types of responses. No matter which response type, note the round trip time for load balancing. Keep an eye on round trip times, and keep a running average, since conditions constantly change. Positive lookup; here's your factoid. Stop loading addresses into the connection pool. Wait for any remaining transactions to finish. No factoid here. Discard the remote peer's address. No factoid here, and let me know if you find something out. Here's a cookie to remind me that I asked for the data you might be pushing at me later. Cache the remote address in case we can send a response. Stop asking me questions. Flag the site as unwilling to transact; don't contact it again for a long while (on the order of a day or more). Why recontact at all? In case the site's policies change. No response; eventually time out (on the order of a few seconds). This could get *slow*. The virtual connection pool will eventually run out, either because there are no more peers to ask or because an ACK stopped new peers from being loaded into it. If we received a positive response, broadcast copies of the factoid to sites that gave us cookies. If nobody knows the factoid, throw away the cookies (or be friendly and NAK them?). Or something. >iv) Does an information request from a bot need to be any different >from an information request from a human? -> viii Probably, since additional information may let the bot network transact more efficiently. >v) A request for information goes out to all peers, each of which >replies if they know the answer. ->vi,vii > >vi) We may receive two conflicting answers. Do we simply take the >first one? Or can we invent a way of validating which is more >appropriate? If so, do we keep both factoids anyway? In short, >how are different factoids going to co-exist in a distributed >knowledge base? -> xii Combine them: A asks, "What is foo?" B says, "Foo is what comes before bar." C says, "Foo is silence." D says, "I don't know; please tell me what you found out." A assimilates "Foo is what comes before bar. or silence." A says to D, "I found out: Foo is what comes before bar. or silence." Overlapping factoids are a little harder: A asks, "What is foo?" B says, "Foo is silence, or what comes before bar." C says, "Foo is silence." D says, "Foo is what comes before bar or a metavariable." A will have to be smart enough to figure out: A assimilates, "Foo is silence or what comes before bar or a metavariable." >vii) How do we propagate the search further? We need a sense of >a return Path and a way to terminate the search if we've found >the information. Usenet provides a `cancel' control message to >do this, effectively. But where do we store state data about a >query? -> viii, x Defined under my response to (iii). Recap: Bot transactions happen one level at a time. No more than N-1 outstanding transactions need to be cleaned up, and the "I don't know, but tell me what you find out" response gives bots a reason to wait past a positive remote lookup. This doesn't ensure that a found factoid propagates to *everyone*, but it does help spread the information around. The factoid will be cached on more servers for the next time. >viii) Ideally we'd have a response look the same at every level, >whether initiated by a human, a bot or another bot further >down the chain, just to make implementation nice and easy. Why >should the bot have to care whether it's talking to me or to >another bot? So, we'd have a message ID stored *locally* keying >what went to whom and who it's for. -> ix) The idea in (iii) involves only one level of store and forward at any time. Respondents that don't know what a factoid means can pass the querist back a cookie along with the "I don't know, but please tell me" response. The querist can use the cookie to validate the factoid it's found. Cookies might expire after (timeout * known_servers + fudge) seconds. That gives the querist enough time to finish its rounds. The whole idea invalidates the "bots and humans living together" aspect. That is, they would have to speak different languages. That may be unacceptable. >ix) However, we can't sent the message ID out if we want it to >be transparent, since I'm a human and I wouldn't send out a >message ID with my queries. So, we have a situation like this: > > Human: BotA, tell me about hoge > >BotA - need to tell Human about hoge, add to to-do list. >don't know about hoge. ask peers, [and this is the key!] >go back to the event loop. > > BotA: Human, sorry, don't know. I'll see if I can find out. > > BotA: BotB, tell me about hoge > BotA: BotC, tell me about hoge > BotA: BotD, tell me about hoge > >BotB - need to tell BotA about hoge. don't know about hoge. >ask peers. >.... > >BotF - need to tell BotC about hoge. > > BotF: BotC, hoge is the Japanese for foo. > >BotC - recieved new factoid `hoge'. Checking to-do list. >Have to tell BotA about `hoge'. Clear `hoge'->BotA from >to-do list. > > BotC: BotA, hoge is the Japanese for foo. > >BotA - recieved new factoid `hoge'. Checking to-do list. >Have to tell Human about `hoge'. Clear `hoge'->Human from >to-do list. > > BotA: Human, hoge is the Japanese for foo. > >[Hence, there was no need to keep state data. However... -> x] The list method in (iii) avoids collissions when BotA and BotB both ask BotF. It's also potentially hideously slow. On the other hand, the tree method you have in (ix) lets questions percolate through the network where they might not normally be allowed. List method example: Nick asks BotA: Foo? BotA asks BotB: Foo? BotA asks BotC: Foo? BotB says to BotA: Doesn't know. BotC says to BotA: Stop asking. Tree method: Nick asks BotA: Foo? BotA asks BotB: Foo? BotA asks BotC: Foo? BotB says to BotA: Doesn't know, but is looking. BotC says to BotA: Stop asking. BotB asks BotC: Foo? BotC says to BotB: Foo is silence. BotB says to BotA: Foo is silence. The factoid gets back to Nick in the tree structure, where it fails in the list structure. On the other other hand, the list structure balances network and bot loads by picking on ones that seem to have better resources. Perhaps a combination of the two methods: Acquire a list of possible peers at initial startup, from a registrar or mirror. Assign them all 0ms response times and assume they're all willing to answer. This ensures that every peer is tested before live statistics are used. On the first local factoid fail, process the list in list mode. This adjusts the response times, and it finds out which peers don't want talk with us directly. Continue to process peers in list mode until they all have been checked. On subsequent factoid fails, walk through our list of cooperative hosts, and pass along a few uncooperative hosts to each one. In this mode, the cooperative hosts check to see if they cooperate with one of the uncooperative hosts. If so, they act as a proxy. Proxies return the factoid, and identify the uncooperative (to the initial querist) host they contacted. The querist replaces the uncooperative host in its list with a path to it through the proxy. These rules recurse as necessary (big gloss over interesting details here), until each geckobot has built routes to each other geckobot. At that point we decide that non-cooperation isn't workable unless bots (or small nets) decide to firewall themselves off from others totally. Then we give them their own registrars and send them on their way. Chains would be periodically broken and retested, in case server policies change. >x) So, we can reliably pass information between bots and humans >without keeping any state *in the message* or distinguishing between >human queries, bot queries and second (n'th) -level bot queries. >BUT... if we have a k-connected graph, which is nice for redundancy, >yet we're not keeping track of who's asked who what, how on earth >do we exhaust the search? -> xi My entire premise, back at (iii) sort of hinges on bots speaking to one another in a special way and/or on a special network. >xi) I guess one solution may be, when receiving the `will try >to find out' message, check whether we have this from all peers, >and if so report `none of my peers know about this'. This will >prune that particular branch of the search. But is that now >guaranteed to find-or-fail in all circumstances? (I can't get my >head around the topology of this) And how to we code it into an >event loop? -> xii > >xii) Don't know. I am now extremely tired. Again, please forgive the rough bits. -- Rocco Caputo / troc@netrus.net From infobot-dev@metronomicon.com Fri Jan 21 09:22:40 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id JAA05087 for infobot-dev-list; Fri, 21 Jan 2000 09:22:14 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from mail.netrus.net (mail.netrus.net [206.251.192.232]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id JAA05084 for ; Fri, 21 Jan 2000 09:22:13 -0500 Received: from rocco (abuse@dialin-pm3-miami-FL-2-135.netrus.net [206.251.198.135]) by mail.netrus.net (8.8.8/8.8.8) with SMTP id JAA11955; Fri, 21 Jan 2000 09:24:34 -0500 Message-Id: <200001211424.JAA11955@mail.netrus.net> From: "Rocco Caputo" To: "infobot-dev@infobot.org" , "scozens@pwj.co.jp" Date: Fri, 21 Jan 2000 09:24:29 -0500 (EST) Reply-To: "Rocco Caputo" X-Mailer: PMMail 2.10.1999 for OS/2 Warp 4.00 In-Reply-To: <4925686D.0013B146.00@pwj-gw-n001.pwj.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Trust (was "Re: Trust and Discovery") Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O I've separated the problem of validating and assimilating factoids on the assumption that more threads with smaller messages is good. On Fri, 21 Jan 2000 13:28:50 +0900, scozens@pwj.co.jp wrote: > [Attribution for >> was lost.] > >> I see three possibilities: >> i) really chatty bots >> ii) really slow bots >> iii) really smart bots > >Let's see if I can remember the saying: > quick, reliable, cheap : choose two, you can't have all three. > >> Plus if any joe can run an infobot and be "discovered" and have >> their factoids shared, bad things are inevitable: >> "teehee, I made purl say 'poop'". > >This happens already, and is, I suspect, a deliberate decision - purl >is not only a *member* of the community, but a *reflection* of it. > >> There should not only be weight given to factoids, but weight given to >> bots. Trust should be gained. > >This isn't as hard as it sounds, so long as you're prepared to solve >some fairly fundamental artificial intelligence problems along the way. >How it would work is this: > >Factoid not found. Ask peers. >One response -> Add response to database, do not alter trust. >Two responses -> Choose response from most trusted bot then proceed as >below. >More than one response -> Compare all factoids, rank by similarity*. >Choose response from most trusted bot from factoids that are similar. >Add trust to all bots producing factoids similar to chosen one, remove >trust from bots producing differing factods. > >* Yes, this part is impossible. Not to worry. We'll work something out. > >So, your bot asks `what is a square?' >Responses: >BotA (Trust 3) : A square is a four-sided shape >BotB (Trust 3) : Poo! >BotC (Trust 8) : A square is a shape with four corners >BotD (Trust 9) : A square is foo bar baz >BotE (Trust 5) : A square is four lines connected by right-angles. > >Sort response by similarity and trustworthiness: > >BotB BotD BotE BotA BotC > >Select BotC's answer. Alter trust: >BotB -2 >BotD -2 >BotE +3 >BotA +3 >BotC +3 > >Do we do this just for bots, or for humans too? Humans, too! I still like the idea of combining factoids. In your example, Bot0 (your bot) would build a new factoid from the others: A square is a four-sided shape or Poo! or a shape with four corners or foo bar baz or four lines connected by right-angles Additionally, it might be fun to store with the factoid which parts came from which places at what times: A square is (BotA@948461095:a four-sided shape) or (BotB@948462000:Poo!) or (BotC@948461111:a shape with four corners) or (BotD@948459833:foo bar baz) or (BotE@948461000:four lines connected by right-angles.) Times and sources would be useful for when acquiring updates. A fun forms interface or some extra syntax could let you forget subsets of factoids: bot, forget a square/BotB bot, replace square/BotD with foo bar baz quux bot, a square is also the opposite of a hep cat That eliminates "Poo!", replaces "foo bar baz" with an updated version, and adds a new subfactoid from a local user. Now it's hypothetically stored as: A square is (BotA@948461095:a four-sided shape) or (BotC@948461111:a shape with four corners) or (BotD@948459833:foo bar baz quux) or (BotE@948461000:four lines connected by right-angles.) or (User@948476281:the opposite of a hep cat) Editing factoids might also subtract some trust from bots B and D in the peers table. The amount of trust subtracted might be proportional to the amount of trust the local bot places in the people making changes. Local user trust? That's a hard one; it may be mask or nick based, like regular karma. Editors may have to log in to participate in trust, or it could be as relaxed as karma and just work out. Since all the factoid's authors are known at least internally, point awards (and penalties) to factoids would be divided among the factoid's authors and added (subtracted, in the case of penalties) to their accumulators. Negative trust doesn't exist; 0 is the minimum. Factoids themselves don't hold karma; authors would have "authorship karma" or something. Or perhaps award an amount of "factoid karma" for each local fetch; assuming that the factoid must be good if nobody bothers to change it? This brings into play a second tier of inter-bot trust: the local bot's trust in its own factoid authors. To rehash the original factoid transaction, with a local-trust twist: Bot0 (your bot) asks: What is a square? BotA (Trust 3) says: A square is (UserAx,12345,97:a four-sided shape) Oh, the fields are (Author,Time,AuthorTrust) In the BotA response, UserAx added the subfactoid at 12345. At the response time, UserAx has a local trust of 97. BotB (Trust 3) says: A square is (UserBx,12346,0:Poo!) BotC (Trust 8) says: A square is (UserCx,12347,133:a shape with four corners) BotD (Trust 9) says: A square is (UserDx,12348,2:foo bar baz) BotE (Trust 5) says: A square is (UserEx,12349,212:four lines connected by right-angles) Overall factoid trust would be the remote bots' trust in the factoid author, weighted by the local bot's trust in the remote bot. For fun, let's try (bot trust * user trust). Sorted in decreasing order of trust: BotC/UserCx = 1064 = a shape with four corners BotE/UserEx = 1060 = four lines connected by right-angles BotA/UserAx = 291 = a four-sided shape BotD/UserDx = 18 = foo bar baz BotB/UserBx = 0 = Poo! Weighing and evaluating trust would be a lot easier if trust had a small set of values. I've specified a similar trust scheme with four inter-system and four intra-system classes; the combinations fall into a small set of overall security classes which are easy enough to manage. This won't work for a system where trust is a fuzzy value. Assuming factoids at and above the median are kept and combined, you get: Bot0: A square is a shape with four corners or four lines connected by right-angles or a four-sided shape That works out pretty well, but it's all contrived examples. These sorts of things seem to break terribly in the field. -- Rocco Caputo / troc@netrus.net / Thinks he's human, too. From infobot-dev@metronomicon.com Fri Jan 21 21:18:26 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id VAA07851 for infobot-dev-list; Fri, 21 Jan 2000 21:17:49 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from vms4.isc.rit.edu (vms4.isc.rit.edu [129.21.3.15]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id VAA07848 for ; Fri, 21 Jan 2000 21:17:47 -0500 Received: from pog ([129.21.142.151]) by ritvax.isc.rit.edu (PMDF V5.2-32 #34523) with ESMTP id <01JKZBF1CLS0CK048R@ritvax.isc.rit.edu> for infobot-dev@infobot.org; Fri, 21 Jan 2000 21:20:04 EST Date: Fri, 21 Jan 2000 21:25:59 -0400 From: Nathan Ewing Subject: Re: Trust In-reply-to: <200001211424.JAA11955@mail.netrus.net> X-Sender: nre7468@vmspop.isc.rit.edu To: infobot-dev@infobot.org Message-id: <4.2.0.58.20000121190450.00ad9cd0@vmspop.isc.rit.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT References: <4925686D.0013B146.00@pwj-gw-n001.pwj.co.jp> Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O Hi , I just started reading this mailing list, but I thought I had something to contribute on this topic anyway. I think it would be interesting if each factoid did have a trust value assigned to it, as well as every bot and person. This way a factoid's trust would actually change all the time. Let me give a good example, we will start with just one on one conversation: Human1 (Trust 3): "infobot: A square is a foo bar baz" - infobot does not know this value, so it adds it to its database with a trust of 3. Human2: infobot, square? infobot: A square is a foo bar baz Human3 (trust 2): no infobot, a square is a shape with four sides infobot adds to database: trust 2 : a shape with four sides infobots edits trust: trust 1: a foo bar baz Human2: infobot, square? infobot: A square is (1)a foo bar baz (2) a shape with four sides Human3 (trust 1): no infobot, a square is a shape with four sides infobot: removes: a foo bar baz from the database, it has reached 0 in trust infobot: increases the trust to 3 for, a shape with four sides ------------------ This is the simplest example, just to get started. Each time someone verifies a factoids trust increases, if someone negates a factoid trust decreases. It gets more fun in a more complicated situation. Human: infobot, what is a square? infobot: I don't know, let me ask around... --infobot asks a few bots on its network BotA (trust 2): a foo bar baz BotB (trust 6): the shape a box is made of BotC (trust 8): a shape with four sides BotD (trust 3): the bad dressin pog thing since infobot got more answers than it needed, it will try to weed them out by reducing every answer other than the highest one by the distance it is from the hightest one: BotC is the highest trust and becomes the base: BotA(trust 2): has a distance of 6 from BotC, giving it a trust of -4, which is <= 0, so that answer is removed BotB(trust 6): has a distance of 2 from BotC, so its factoid survives with a trust of 4 BotD(trust 3): has a distance of 5 from BotC, so its factoid goes down in smoke with a rating of -2 The end result would be two factoids: 1.(trust 8) a shape with four sides 2.(trust 4) the shape a box is made of This way the higher a trust is in a bot, the better chance it would have of eliminating untrustworthy answers from getting added. Now lets say infobot gets a couple extra factoids from watching channels, so it now has the following: 1.(trust 8) a shape with four sides 2.(trust 4) the shape a box is made of 3.(trust 6) has all equal sides 4.(trust 3) a four sided shape infobot now looks at some of the people on its list of trusted users and finds one with a high trust and msg's them: infobot: Could I ask you a quick factoid question? trustedone(trust 10): yes infobot infobot: I have heard that a square is the following: 1.a shape with four sides 2.the shape a box is made of 3.has all equal sides 4.a four sided shape trustedone: infobot, 1 and 4 are the same and 2 is wrong infobot: do you know if 3 (has all three sides) is right? trustedone: no infobot The end result of this short conversation is the following: - (trust 4) the shape a box is made of: gets removed (10 trust are subtracted from 4 for -6) - since factoids 1 and 4 are the same, infobot takes the factoid with the highest trust, a shape with four sides (8) and adds the current trust to it (8+10) for 18, and subtracts the trust from the other one (a four sided shape)(3-10) for -7, removing it. - because it could not get an answer on 3. has all equal sides, it will have to verify with someone else, or leave the factoid with a trust of 6. Current trusts for a square: 1. (trust 18) a shape with four sides 2. (trust 6) has all equal sides I like this method cause it continually reinforces factoids that many people agree with. It does make it hard to get rid of factoids that have been verified by many people though, cause one person can't remove a really entrenched factoid (which is both good and bad). I think with this system there should be some way to scale a factoid, or put a limit on how high a trust a factoid can have, so we don't create zealotbot, that refuses to forget long used factoids even if they are wrong. Two distadvantages to this method are: 1. Bots ask questions alot 2. A person could keep telling a bot a fact to artificially inflate it. You could shut the bot up in a couple ways. You could have infobot only watch channels and only reenforce if someone actually tells infobot to, or if infobot see's a factoid in a channel. You could also have infobot increase the trust of a factoid if a trusted person tells infobot to tell someone else a fact. The trust of the factoid could even be increased by a percentage of the persons total trust because telling infobot to tell someone else is not as powerful as telling infobot a fact is correct directly. To combat autoinflation, infobot could keep track of people that have told it a factoid for a limited time, say a week, so that in that week, they cannot reenforce the same factoid. One last issue left is people's trust and how to raise/lower it. What infobot could do is, each time a person has verified a factoid, the person who originally gave infobot the factoid would have their trust raised a little. If someone discounts a factoid, then infobot lowers their trust a little. How much they raise or lower depends on the scale used. infobot could also watch a channel, and if a person says many factoids in conversation that match a factoid that infobot has a high trust in, infobot could raise their trust a little, so that its not necessary to give tons of new facts to gain trust, but verifying many old ones will work too. Oh, one last thing in this stream of thought. There probably should be a way to let bots tell each other how trusted a factoid they have is. That way if a bot has some new erroneous factoid it just got, it won't ruin its trust with other bots by giving it away as a trusted fact. When a friendly bot asks another for a factoid, it should return the trust it has on the factoid. This way, if the bot that recieves the factoid later discounts it, if the factoid had a low trust anyway with the other bot, that bot won't be penalized for giving a bad factoid. It should only be penalized for erroneous and trusted factoids. The only thing I see thats bad about all this is that the factoid database could get pretty big, because infobot would have to remember the people that told it factoids, and for at least a little while, people that reenforce them. I do think it would make a much smarter infobot though. Oh, one last thing, it would be interesting to have it so that factoids degrade in trust over time, so that a factoid that hasn't been reenforced in any way for a long time that has a low trust would get removed automatically. It might make the bot keep only more trusted answers. Anyway, I hope this theory is useful, and I haven't treaded on already past steps. Thanks for taking the time to read it. Thank you, Nathan Ewing / nre7468@rit.edu At 09:24 AM 1/21/00 -0500, you wrote: >I've separated the problem of validating and assimilating factoids on >the assumption that more threads with smaller messages is good. > > >On Fri, 21 Jan 2000 13:28:50 +0900, scozens@pwj.co.jp wrote: > > > >[Attribution for >> was lost.] > > > >> I see three possibilities: > >> i) really chatty bots > >> ii) really slow bots > >> iii) really smart bots > > > >Let's see if I can remember the saying: > > quick, reliable, cheap : choose two, you can't have all three. > > > >> Plus if any joe can run an infobot and be "discovered" and have > >> their factoids shared, bad things are inevitable: > >> "teehee, I made purl say 'poop'". > > > >This happens already, and is, I suspect, a deliberate decision - purl > >is not only a *member* of the community, but a *reflection* of it. > > > >> There should not only be weight given to factoids, but weight given to > >> bots. Trust should be gained. > > > >This isn't as hard as it sounds, so long as you're prepared to solve > >some fairly fundamental artificial intelligence problems along the way. > >How it would work is this: > > > >Factoid not found. Ask peers. > >One response -> Add response to database, do not alter trust. > >Two responses -> Choose response from most trusted bot then proceed as > >below. > >More than one response -> Compare all factoids, rank by similarity*. > >Choose response from most trusted bot from factoids that are similar. > >Add trust to all bots producing factoids similar to chosen one, remove > >trust from bots producing differing factods. > > > >* Yes, this part is impossible. Not to worry. We'll work something out. > > > >So, your bot asks `what is a square?' > >Responses: > >BotA (Trust 3) : A square is a four-sided shape > >BotB (Trust 3) : Poo! > >BotC (Trust 8) : A square is a shape with four corners > >BotD (Trust 9) : A square is foo bar baz > >BotE (Trust 5) : A square is four lines connected by right-angles. > > > >Sort response by similarity and trustworthiness: > > > >BotB BotD BotE BotA BotC > > > >Select BotC's answer. Alter trust: > >BotB -2 > >BotD -2 > >BotE +3 > >BotA +3 > >BotC +3 > > > >Do we do this just for bots, or for humans too? > > >Humans, too! > >I still like the idea of combining factoids. In your example, Bot0 >(your bot) would build a new factoid from the others: > > A square is a four-sided shape or Poo! or a shape with four corners > or foo bar baz or four lines connected by right-angles > >Additionally, it might be fun to store with the factoid which parts >came from which places at what times: > > A square is > (BotA@948461095:a four-sided shape) or > (BotB@948462000:Poo!) or > (BotC@948461111:a shape with four corners) or > (BotD@948459833:foo bar baz) or > (BotE@948461000:four lines connected by right-angles.) > >Times and sources would be useful for when acquiring updates. > >A fun forms interface or some extra syntax could let you forget >subsets of factoids: > > bot, forget a square/BotB > bot, replace square/BotD with foo bar baz quux > bot, a square is also the opposite of a hep cat > >That eliminates "Poo!", replaces "foo bar baz" with an updated >version, and adds a new subfactoid from a local user. Now it's >hypothetically stored as: > > A square is > (BotA@948461095:a four-sided shape) or > (BotC@948461111:a shape with four corners) or > (BotD@948459833:foo bar baz quux) or > (BotE@948461000:four lines connected by right-angles.) or > (User@948476281:the opposite of a hep cat) > >Editing factoids might also subtract some trust from bots B and D in >the peers table. The amount of trust subtracted might be proportional >to the amount of trust the local bot places in the people making >changes. > >Local user trust? That's a hard one; it may be mask or nick based, >like regular karma. Editors may have to log in to participate in >trust, or it could be as relaxed as karma and just work out. > >Since all the factoid's authors are known at least internally, point >awards (and penalties) to factoids would be divided among the >factoid's authors and added (subtracted, in the case of penalties) to >their accumulators. Negative trust doesn't exist; 0 is the minimum. >Factoids themselves don't hold karma; authors would have "authorship >karma" or something. > > Or perhaps award an amount of "factoid karma" for each > local fetch; assuming that the factoid must be good if > nobody bothers to change it? > >This brings into play a second tier of inter-bot trust: the local >bot's trust in its own factoid authors. To rehash the original >factoid transaction, with a local-trust twist: > >Bot0 (your bot) asks: What is a square? >BotA (Trust 3) says: A square is (UserAx,12345,97:a four-sided > shape) > > Oh, the fields are (Author,Time,AuthorTrust) In the BotA > response, UserAx added the subfactoid at 12345. At the > response time, UserAx has a local trust of 97. > >BotB (Trust 3) says: A square is (UserBx,12346,0:Poo!) >BotC (Trust 8) says: A square is (UserCx,12347,133:a shape with > four corners) >BotD (Trust 9) says: A square is (UserDx,12348,2:foo bar baz) >BotE (Trust 5) says: A square is (UserEx,12349,212:four lines > connected by right-angles) > >Overall factoid trust would be the remote bots' trust in the factoid >author, weighted by the local bot's trust in the remote bot. For fun, >let's try (bot trust * user trust). Sorted in decreasing order of >trust: > >BotC/UserCx = 1064 = a shape with four corners >BotE/UserEx = 1060 = four lines connected by right-angles >BotA/UserAx = 291 = a four-sided shape >BotD/UserDx = 18 = foo bar baz >BotB/UserBx = 0 = Poo! > >Weighing and evaluating trust would be a lot easier if trust had a >small set of values. I've specified a similar trust scheme with four >inter-system and four intra-system classes; the combinations fall into >a small set of overall security classes which are easy enough to >manage. This won't work for a system where trust is a fuzzy value. > > >Assuming factoids at and above the median are kept and combined, you >get: > > Bot0: A square is a shape with four corners or four lines connected > by right-angles or a four-sided shape > > >That works out pretty well, but it's all contrived examples. These >sorts of things seem to break terribly in the field. > > >-- Rocco Caputo / troc@netrus.net / Thinks he's human, too. From infobot-dev@metronomicon.com Sat Jan 22 06:08:20 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id GAA09905 for infobot-dev-list; Sat, 22 Jan 2000 06:08:16 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from tantalum.btinternet.com (tantalum.btinternet.com [194.73.73.80]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id GAA09902 for ; Sat, 22 Jan 2000 06:08:14 -0500 Received: from [212.140.12.245] (helo=cocacola) by tantalum.btinternet.com with smtp (Exim 2.05 #1) id 12ByNm-0001MG-00 for infobot-dev@infobot.org; Sat, 22 Jan 2000 11:07:06 +0000 Message-ID: <002401bf64c8$b884a200$f50c8cd4@cocacola> From: "Russ Smith" To: Subject: Lockable Factoids Date: Sat, 22 Jan 2000 11:06:22 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O Does anyone know of a patch or piece of code in existance that allows operators or special users to lock factoids? If not, would anyone else aside me benefit from such a patch - because if I can't find one, I'll make it :) Russ 'RB6' Smith Quakenet #infobot From infobot-dev@metronomicon.com Sat Jan 22 11:50:27 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id LAA11431 for infobot-dev-list; Sat, 22 Jan 2000 11:49:56 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from praseodumium.btinternet.com (praseodumium.btinternet.com [194.73.73.82]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id LAA11428 for ; Sat, 22 Jan 2000 11:49:54 -0500 Received: from [212.140.10.42] (helo=cocacola) by praseodumium.btinternet.com with smtp (Exim 2.05 #1) id 12C3ll-0004y8-00 for infobot-dev@infobot.org; Sat, 22 Jan 2000 16:52:14 +0000 Message-ID: <000b01bf64f8$f1d07220$2a0a8cd4@cocacola> From: "Russ Smith" To: Subject: Re: Lockable Factoids Date: Sat, 22 Jan 2000 16:51:34 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O >set users, and then only let the users update set default to no modifications Yeah, but more specifically - say for example you wanted to allow people to still do 'is also', but you didn't want your own name soiled by some idiot who comes into the channel and says 'whatever is also gh3y' or whatever - this happens a lot on an immature network like Quakenet :) I've now made a patch for the infobot that allows this, so if any of you are in need of something like this, drop me an email. Russ 'RB6' Smith Quakenet #infobot From infobot-dev@metronomicon.com Sat Jan 22 15:46:21 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id PAA12529 for infobot-dev-list; Sat, 22 Jan 2000 15:46:08 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from alyosha.cashner.net (asbury.edu [206.244.156.10]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id PAA12526 for ; Sat, 22 Jan 2000 15:46:07 -0500 From: sungo@linuxhelper.org Received: from localhost (localhost [127.0.0.1]) by alyosha.cashner.net (8.9.3/8.9.3) with ESMTP id PAA12161 for ; Sat, 22 Jan 2000 15:32:59 -0500 Date: Sat, 22 Jan 2000 15:32:59 -0500 (EST) To: infobot-dev@metronomicon.com Subject: Re: Lockable Factoids Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O On Sat, 22 Jan 2000, Russ Smith wrote: > >set users, and then only let the users update set default to no > modifications > > Yeah, but more specifically - say for example you wanted to allow people to > still do 'is also', but > you didn't want your own name soiled by some idiot who comes into the > channel and says > 'whatever is also gh3y' or whatever - this happens a lot on an immature > network like Quakenet :) /me missed the first part of this convo :) is your patch so you can make, say entry1's defintion the same as entry2's defintion? or to add multiple definitions to entry1's defintion? because if you're talking the first one, i've got a little addon to do that. but if you're talking the second one, i'd be interested in the patch. ------------------------ Matt Cashner sungo@linuxhelper.org ------------------------ "That which does not kill me postpones the inevitable." From infobot-dev@metronomicon.com Sat Jan 22 16:13:04 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id QAA12725 for infobot-dev-list; Sat, 22 Jan 2000 16:13:04 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from pixie.securenets.com (what.securetty.org [63.225.132.243]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id QAA12722 for ; Sat, 22 Jan 2000 16:13:02 -0500 Received: from localhost (jjacobs@localhost) by pixie.securenets.com (8.9.1/8.9.1) with SMTP id PAA10446 for ; Sat, 22 Jan 2000 15:15:21 -0600 Date: Sat, 22 Jan 2000 15:15:20 -0600 (CST) From: Jay Jacobs X-Sender: jjacobs@pixie.securenets.com To: infobot-dev@infobot.org Subject: status of new modules? (Dict.pm) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O Did I hear Simon volunteer to keep modules straight? Or are we going to use CPAN to store them? I remember both being mentioned somewhere. In the spare time I've created through procrastination, I've updated the Dict.pm. I've added in the ability to see what dictionaries are available to search, and also added the ability to lookup a short description of that dictionary. All that information is provided by the Dict server, and retrieved at startup. I'm also adding in a "spell" feature that will use the dict protocol to verify spelling across a single or multiple dictionaries. So, if I keep up work-avoidance and finish this... where should it go? Should we make a repository on infobot.org for them? Jay From infobot-dev@metronomicon.com Sun Jan 23 07:34:09 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id HAA16769 for infobot-dev-list; Sun, 23 Jan 2000 07:33:52 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from othersideofthe.earth.li (IDENT:qmailr@othersideofthe.earth.li [210.145.136.209]) by token.metronomicon.com (8.9.3/8.8.7) with SMTP id HAA16766 for ; Sun, 23 Jan 2000 07:33:50 -0500 Received: (qmail 17141 invoked by uid 500); 23 Jan 2000 12:36:08 -0000 Date: Sun, 23 Jan 2000 21:36:08 +0900 From: Simon Cozens To: infobot-dev@infobot.org Subject: Re: status of new modules? (Dict.pm) Message-ID: <20000123213608.A16751@othersideofthe.earth.li> Reply-To: Simon Cozens References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Jay Jacobs on Sat, Jan 22, 2000 at 03:15:20PM -0600 X-Operating-System: Linux othersideofthe.earth.li 2.2.13 Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O On Sat, Jan 22, 2000 at 03:15:20PM -0600, Jay Jacobs wrote: > Did I hear Simon volunteer to keep modules straight? Or are we going to > use CPAN to store them? I remember both being mentioned somewhere. I'm happy to maintain a site which contains patches and modules for the infobot we know and love, rather than the super-duper geckobot we'll love more. I think we were planning to store modules for the geckobot on CPAN. I don't know. > So, if I keep up work-avoidance and finish this... where should it go? Plesae send it to me, as well as wherever formal we decide upon. > Should we make a repository on infobot.org for them? Would be a good plan. Simon -- Going to church does not make a person religious, nor does going to school make a person educated, any more than going to a garage makes a person a car. From infobot-dev@metronomicon.com Sun Jan 23 10:06:36 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id KAA17543 for infobot-dev-list; Sun, 23 Jan 2000 10:06:20 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id KAA17540 for ; Sun, 23 Jan 2000 10:06:18 -0500 Received: from [212.140.14.172] (helo=cocacola) by tungsten.btinternet.com with smtp (Exim 2.05 #1) id 12COd1-0000sv-00 for infobot-dev@infobot.org; Sun, 23 Jan 2000 15:08:36 +0000 Message-ID: <001101bf65b3$9b542e80$ac0e8cd4@cocacola> From: "RainbowSix" To: Subject: Re: lockable factoids Date: Sun, 23 Jan 2000 15:07:44 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O The lockable factoids addition I made works as follows (and its not too good, but at least it works): Added code in myRoutines.pl recognises the 'lock' and 'unlock' commands, and procedes to add or remove the argument from the commands to a file (separated by s), depending on lock or unlock. As for stopping users without correct flags from modifying the factoid, I've added some code to Statement.pl that basically stops the bot writing anything if it matches one of the locked words in the 'locked' file. Or at least, thats what I tried to make it do :) Russ 'RB6' Smith Quakenet #infobot From infobot-dev@metronomicon.com Sun Jan 23 13:24:43 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id NAA18547 for infobot-dev-list; Sun, 23 Jan 2000 13:23:44 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from verdi.siteprotect.com (verdi.siteprotect.com [209.100.98.18]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id NAA18544 for ; Sun, 23 Jan 2000 13:23:43 -0500 Received: from LucidX.com (adsl-63-199-194-66.dsl.lsan03.pacbell.net [63.199.194.66]) by verdi.siteprotect.com (8.8.5/8.8.5) with ESMTP id MAA07121 for ; Sun, 23 Jan 2000 12:25:37 -0600 Message-ID: <388B47D4.F3B79B2A@LucidX.com> Date: Sun, 23 Jan 2000 10:26:28 -0800 From: "Samy Kamkar (CommPort5)" Organization: LucidX X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: infobot-dev@infobot.org Subject: Freshmeat search util Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O Hello there...here is a small freshmeat search tool, which actually goes through freshmeat's own search tool, to find you anything on freshmeat. It will find the address of the download and the full name. If there appears to be more than one match it will go to the first one and get the URL for downloading and full name from there. Once you add this in your src/ directory open up your src/Extras.pl and stick this in: ################### if ($message = /^\s*freshmeat(?:\s*for\s*|\s*)(.*?)$/i) { my $app = &fnd($1); return '$app'; } ################### I'm not sure if this was made yet or not, but I don't have it so I just decided to make it and thought it would be interesting. It's a bit dirty but it works...almost. Hope to get it updated soon but it's nothing too big. Here is an example of it: lucidx, freshmeat infobot http://www.cs.cmu.edu/~infobot/src/ (infobot) lucidx, freshmeat for tetris http://www.alphalink.com.au/~michg/ace/itetris/itetris-1.6.1.tar.gz (Intelligent TETRIS) If you have any updates or anything please email to infobot-dev@infobot.org and commport5@lucidx.com. From infobot-dev@metronomicon.com Sun Jan 23 13:33:06 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id NAA18648 for infobot-dev-list; Sun, 23 Jan 2000 13:33:06 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from verdi.siteprotect.com (verdi.siteprotect.com [209.100.98.18]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id NAA18645 for ; Sun, 23 Jan 2000 13:33:05 -0500 Received: from LucidX.com (adsl-63-199-194-66.dsl.lsan03.pacbell.net [63.199.194.66]) by verdi.siteprotect.com (8.8.5/8.8.5) with ESMTP id MAA09423 for ; Sun, 23 Jan 2000 12:34:55 -0600 Message-ID: <388B4A02.9E7CE904@LucidX.com> Date: Sun, 23 Jan 2000 10:35:46 -0800 From: "Samy Kamkar (CommPort5)" Organization: LucidX X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: infobot-dev@infobot.org Subject: Rev it up #2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O Hello again, here is another patch for the infobot. This is for changing a nick name on the fly, as in on IRC. Only the owner(s) of the bot will be able to do this and it requires their password. A simple example would be this: [msg(lucidx1)] nick LucidX ωνω LucidX1 is now known as LucidX Nothing difficult again, but just something nice to have. ####################### if (IsFlag("o")) { # owner/operator flag + if ($message =~ /^nick\s*(.*?)$/i) { + if (!exists $verified{$VerifWho}) { + &status("unverified <$who> $message"); + &msg($who, $unverified_message); + return 'NOREPLY'; + } + $nnick = $1; + &rawout("NICK $nnick"); + &status("Changed nick to $nnick"); + } if ($message =~ /^die/) { ################## That's all for this time, hope to see some other patches out! -Sam (CommPort5) From infobot-dev@metronomicon.com Mon Jan 24 07:25:10 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id HAA22801 for infobot-dev-list; Mon, 24 Jan 2000 07:24:55 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from othersideofthe.earth.li (IDENT:qmailr@othersideofthe.earth.li [210.145.136.209]) by token.metronomicon.com (8.9.3/8.8.7) with SMTP id HAA22798 for ; Mon, 24 Jan 2000 07:24:53 -0500 Received: (qmail 13770 invoked by uid 500); 24 Jan 2000 12:27:09 -0000 Date: Mon, 24 Jan 2000 21:27:09 +0900 From: Simon Cozens To: infobot-dev@infobot.org Subject: Re: Freshmeat search util Message-ID: <20000124212709.B12829@othersideofthe.earth.li> Reply-To: Simon Cozens References: <388B47D4.F3B79B2A@LucidX.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <388B47D4.F3B79B2A@LucidX.com>; from Samy Kamkar (CommPort5) on Sun, Jan 23, 2000 at 10:26:28AM -0800 X-Operating-System: Linux othersideofthe.earth.li 2.2.13 Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O On Sun, Jan 23, 2000 at 10:26:28AM -0800, Samy Kamkar (CommPort5) wrote: > if ($message = /^\s*freshmeat(?:\s*for\s*|\s*)(.*?)$/i) { > my $app = &fnd($1); > return '$app'; > } Woo! CommPort5++! However, I seem to be missing the definition of this sub - could you send it to me, or to the list? Nice work on the nick patch, I've put that in the usual place. Oznoid, have a DNS cookie. -- A LISP programmer knows the value of everything, but the cost of nothing. -- Alan Perlis From infobot-dev@metronomicon.com Mon Jan 24 18:29:58 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id SAA26806 for infobot-dev-list; Mon, 24 Jan 2000 18:29:22 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from verdi.siteprotect.com (verdi.siteprotect.com [209.100.98.18]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id SAA26803 for ; Mon, 24 Jan 2000 18:29:20 -0500 Received: from LucidX.com (adsl-63-199-194-66.dsl.lsan03.pacbell.net [63.199.194.66]) by verdi.siteprotect.com (8.8.5/8.8.5) with ESMTP id RAA12949 for ; Mon, 24 Jan 2000 17:31:16 -0600 Message-ID: <388CE0FA.11B581AF@LucidX.com> Date: Mon, 24 Jan 2000 15:32:10 -0800 From: "Samy Kamkar (CommPort5)" Organization: LucidX X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: infobot-dev@infobot.org Subject: Re: Rev it up #2 References: <388B4A02.9E7CE904@LucidX.com> <20000124212910.C12829@othersideofthe.earth.li> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O Yes, yes yes! I'm very sorry about that, and I did notice that I left out the script to edit (which is src/User.pl if some of you aren't famliar) but I hoped who ever would like to use it would figure it out. I believe I put in: if (IsFlag("o")) { to show that it is only for the owner but I will make sure to put in more next time. I'll make sure to be a bit more specific in later posts for people who aren't too familiar with infobot. Have fun, kids :P -Sam (CommPort5) Simon Cozens wrote: > ......can I trouble you to give proper diffs in the future? (Ideally context > diffs, > 'cos they say which file to patch as well.) If that's a problem, don't worry > about it; I'm only trying to make my life easier. :) From infobot-dev@metronomicon.com Mon Jan 24 18:36:31 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id SAA26939 for infobot-dev-list; Mon, 24 Jan 2000 18:36:30 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from verdi.siteprotect.com (verdi.siteprotect.com [209.100.98.18]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id SAA26936 for ; Mon, 24 Jan 2000 18:36:30 -0500 Received: from LucidX.com (adsl-63-199-194-66.dsl.lsan03.pacbell.net [63.199.194.66]) by verdi.siteprotect.com (8.8.5/8.8.5) with ESMTP id RAA13847 for ; Mon, 24 Jan 2000 17:38:22 -0600 Message-ID: <388CE2A4.7EA4457E@LucidX.com> Date: Mon, 24 Jan 2000 15:39:16 -0800 From: "Samy Kamkar (CommPort5)" Organization: LucidX X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: infobot-dev@infobot.org Subject: Re: Freshmeat search util References: <388B47D4.F3B79B2A@LucidX.com> <20000124212709.B12829@othersideofthe.earth.li> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O Well as you see I'm not to great with regex's and I'm sure there are better ways to do this but I hope this is what you mean by the definition for it, it will simply require the word `freshmeat` which isn't a very nice thing and then you can include `for` in there and then what you want to search for. Examples would be like: freshmeat for infobot (or) fReShMeAt InFoBoT (if you want to do that for some odd reason) and of course it stores `infobot` and then it uses fsapps.pl to do the search on freshmeat and will choose the first match if there is more than one match, and the fsapps.pl outputs the 'http://address.for.program (then the full name of the program including version number)'. I hope that answered your question! Over and out- -Sam Simon Cozens wrote: > On Sun, Jan 23, 2000 at 10:26:28AM -0800, Samy Kamkar (CommPort5) wrote: > > if ($message = /^\s*freshmeat(?:\s*for\s*|\s*)(.*?)$/i) { > > my $app = &fnd($1); > > return '$app'; > > } > > However, I seem to be missing the definition of this sub...... From infobot-dev@metronomicon.com Tue Jan 25 04:18:17 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id EAA29422 for infobot-dev-list; Tue, 25 Jan 2000 04:18:06 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from othersideofthe.earth.li (IDENT:qmailr@othersideofthe.earth.li [210.145.136.209]) by token.metronomicon.com (8.9.3/8.8.7) with SMTP id EAA29419 for ; Tue, 25 Jan 2000 04:18:04 -0500 Received: (qmail 32318 invoked by uid 500); 25 Jan 2000 09:20:17 -0000 Date: Tue, 25 Jan 2000 18:20:17 +0900 From: Simon Cozens To: infobot-dev@infobot.org Subject: Re: Freshmeat search util Message-ID: <20000125182017.A32303@othersideofthe.earth.li> Reply-To: Simon Cozens References: <388B47D4.F3B79B2A@LucidX.com> <20000124212709.B12829@othersideofthe.earth.li> <388CE2A4.7EA4457E@LucidX.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <388CE2A4.7EA4457E@LucidX.com>; from Samy Kamkar (CommPort5) on Mon, Jan 24, 2000 at 03:39:16PM -0800 X-Operating-System: Linux othersideofthe.earth.li 2.2.13 Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O On Mon, Jan 24, 2000 at 03:39:16PM -0800, Samy Kamkar (CommPort5) wrote: > fsapps.pl This was what I was looking for. Where can I get it from? -- `And when you've been *plonk*ed by Simon C., you've been *plonked* by someone who knows when, and why, and how.' - Mike Andrews, asr From infobot-dev@metronomicon.com Tue Jan 25 10:20:58 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id KAA30868 for infobot-dev-list; Tue, 25 Jan 2000 10:20:37 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from dragon.cbi.tamucc.edu (IDENT:postfix@dragon.cbi.tamucc.edu [165.95.1.149]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id KAA30865 for ; Tue, 25 Jan 2000 10:20:36 -0500 Received: by dragon.cbi.tamucc.edu (Postfix, from userid 101) id 434CFE94C; Tue, 25 Jan 2000 09:46:27 -0600 (CST) Date: Tue, 25 Jan 2000 09:46:27 -0600 From: duff@cbi.tamucc.edu To: Simon Cozens Cc: infobot-dev@infobot.org Subject: Re: Freshmeat search util Message-ID: <20000125094627.A4173@cbi.tamucc.edu> References: <388B47D4.F3B79B2A@LucidX.com> <20000124212709.B12829@othersideofthe.earth.li> <388CE2A4.7EA4457E@LucidX.com> <20000125182017.A32303@othersideofthe.earth.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <20000125182017.A32303@othersideofthe.earth.li>; from simon@brecon.co.uk on Tue, Jan 25, 2000 at 06:20:17PM +0900 Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O On Tue, Jan 25, 2000 at 06:20:17PM +0900, Simon Cozens wrote: > On Mon, Jan 24, 2000 at 03:39:16PM -0800, Samy Kamkar (CommPort5) wrote: > > fsapps.pl > > This was what I was looking for. Where can I get it from? I've been mostly lurking, but this last exchange prompts me to pipe up. IMHO, someone (oznoid, Simon) should draft infobot patch submission guidelines. That way, at least everybody will be on the same page when it comes to posting patches here. -Scott -- Jonathan Scott Duff duff@cbi.tamucc.edu From infobot-dev@metronomicon.com Tue Jan 25 10:33:33 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id KAA31155 for infobot-dev-list; Tue, 25 Jan 2000 10:33:32 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from othersideofthe.earth.li (IDENT:qmailr@othersideofthe.earth.li [210.145.136.209]) by token.metronomicon.com (8.9.3/8.8.7) with SMTP id KAA31152 for ; Tue, 25 Jan 2000 10:33:30 -0500 Received: (qmail 24870 invoked by uid 500); 25 Jan 2000 15:35:33 -0000 Date: Wed, 26 Jan 2000 00:35:33 +0900 From: Simon Cozens To: infobot-dev@infobot.org Subject: Re: Freshmeat search util Message-ID: <20000126003533.A24390@othersideofthe.earth.li> Reply-To: Simon Cozens References: <388B47D4.F3B79B2A@LucidX.com> <20000124212709.B12829@othersideofthe.earth.li> <388CE2A4.7EA4457E@LucidX.com> <20000125182017.A32303@othersideofthe.earth.li> <20000125094627.A4173@cbi.tamucc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <20000125094627.A4173@cbi.tamucc.edu>; from duff@cbi.tamucc.edu on Tue, Jan 25, 2000 at 09:46:27AM -0600 X-Operating-System: Linux othersideofthe.earth.li 2.2.13 Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O On Tue, Jan 25, 2000 at 09:46:27AM -0600, duff@cbi.tamucc.edu wrote: > IMHO, someone (oznoid, Simon) should draft infobot patch submission > guidelines. That way, at least everybody will be on the same page > when it comes to posting patches here. Here are some draft guidelines; feel free to implement/improve/ignore them. * Patches should apply to the current stable version of the source, and should be taken from the infobot-0.xx.x/ directory. * Ideally submit patches as unified diffs; see the Perl patching guide at Porting/patching.pod in a Perl source kit near you. * If unified diffs are not an option, please use diff, and be sure to state which file the patch applies to. * In the worst case, send the file to me or Oz or someone and we'll generate the diff. * If you're adding a new extension, rather than just patching the existing stuff, the following also applies: . Post a diff to Extras.pl and any other affected files. . Then add any new extension files as an attachment, or give an address whence it can be obtained. . This is by no means compulsary, but it would be really lovely if you could use the documentation template; if you don't have one with your infobot, you can download it from http://othersideofthe.earth.li/infobot/module-template Simon -- "Nuclear war can ruin your whole compile." -- Karl Lehenbauer From infobot-dev@metronomicon.com Tue Jan 25 10:37:24 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id KAA31412 for infobot-dev-list; Tue, 25 Jan 2000 10:37:24 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from verdi.siteprotect.com (verdi.siteprotect.com [209.100.98.18]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id KAA31409 for ; Tue, 25 Jan 2000 10:37:23 -0500 Received: from LucidX.com (adsl-63-199-194-66.dsl.lsan03.pacbell.net [63.199.194.66]) by verdi.siteprotect.com (8.8.5/8.8.5) with ESMTP id JAA04677 for ; Tue, 25 Jan 2000 09:39:17 -0600 Message-ID: <388DC3DD.5FC41013@LucidX.com> Date: Tue, 25 Jan 2000 07:40:13 -0800 From: "Samy Kamkar (CommPort5)" Organization: LucidX X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: infobot-dev@infobot.org Subject: Re: Freshmeat search util References: <388B47D4.F3B79B2A@LucidX.com> <20000124212709.B12829@othersideofthe.earth.li> <388CE2A4.7EA4457E@LucidX.com> <20000125182017.A32303@othersideofthe.earth.li> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O Here you go, I'm including fsapps.pl in this email message if it didn't get sent correctly last time. If you can't retrieve it from the email you can download it from http://www.lucidx.com/fsapps.pl Just make sure to stick it in your src/ directory and also include the little snippit of code from the last message about this in Extras.pl, I'm also including it here: ################### if ($message = /^\s*freshmeat(?:\s*for\s*|\s*)(.*?)$/i) { my $app = &fnd($1); return '$app'; } ################### Adios! -Sam From infobot-dev@metronomicon.com Tue Jan 25 11:04:55 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id LAA31943 for infobot-dev-list; Tue, 25 Jan 2000 11:04:55 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from mail.in-con.com (bell.in-con.com [205.162.249.10]) by token.metronomicon.com (8.9.3/8.8.7) with SMTP id LAA31940 for ; Tue, 25 Jan 2000 11:04:54 -0500 Received: from cedar (druk.imperma.net[205.162.249.195])by BELL(MailMax 2.040) with ESMTP id 0 for mpoole@in-con.com; Tue, 25 Jan 2000 08:06:54 -0800 PST Message-ID: <0a0801bf674e$58f90cd0$c3f9a2cd@cedar> From: "mapoole" To: "infobot dev" Subject: greeting routine request Date: Tue, 25 Jan 2000 08:07:57 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A05_01BF670B.49DE4D70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O This is a multi-part message in MIME format. ------=_NextPart_000_0A05_01BF670B.49DE4D70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I know I shouldn't just make lists of things that would be nice see = happen but this is something that should get installed to prevent = channel irritations. when someone comes on channel and everyone says hi the bot doesn't = really know who it should address and consequently addresses everyone Could someone add an only welcome recent on_joins? I'll try to contribute other ways like assisting with the development of = guidelines etc. until my code gets up to speed where I can actually do = things for myself. thanks, urgen/efnet ------=_NextPart_000_0A05_01BF670B.49DE4D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I know I shouldn't just make lists = of things=20 that would be nice see happen but this is something that should get = installed to=20 prevent channel irritations.
 
when someone comes on channel and = everyone says=20 hi the bot doesn't really know who it should address and consequently = addresses=20 everyone
 
Could someone add an only welcome = recent=20 on_joins?
 
I'll try to contribute other ways = like assisting=20 with the development of guidelines etc. until my code gets up to speed = where I=20 can actually do things for myself.
 
    thanks,=20 urgen/efnet
------=_NextPart_000_0A05_01BF670B.49DE4D70-- From infobot-dev@metronomicon.com Tue Jan 25 11:16:13 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id LAA32188 for infobot-dev-list; Tue, 25 Jan 2000 11:16:12 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from othersideofthe.earth.li (IDENT:qmailr@othersideofthe.earth.li [210.145.136.209]) by token.metronomicon.com (8.9.3/8.8.7) with SMTP id LAA32185 for ; Tue, 25 Jan 2000 11:16:10 -0500 Received: (qmail 26885 invoked by uid 500); 25 Jan 2000 16:18:25 -0000 Date: Wed, 26 Jan 2000 01:18:25 +0900 From: Simon Cozens To: mapoole Cc: infobot dev Subject: Re: greeting routine request Message-ID: <20000126011825.A26552@othersideofthe.earth.li> Reply-To: Simon Cozens References: <0a0801bf674e$58f90cd0$c3f9a2cd@cedar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <0a0801bf674e$58f90cd0$c3f9a2cd@cedar>; from mapoole on Tue, Jan 25, 2000 at 08:07:57AM -0800 X-Operating-System: Linux othersideofthe.earth.li 2.2.13 Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O On Tue, Jan 25, 2000 at 08:07:57AM -0800, mapoole wrote: > Could someone add an only welcome recent on_joins? No. diff -ruN ../infobot-oxford/src/Irc.pl ./src/Irc.pl --- ../infobot-oxford/src/Irc.pl Thu Jan 6 23:54:02 2000 +++ ./src/Irc.pl Wed Jan 26 01:12:51 2000 @@ -141,6 +141,7 @@ } else { &status(">>> $nick ($user\@$host) has joined $chan"); } + &IrcNickHook($nick,$chan); } elsif ($type=~/QUIT/) { $chan=~s/\r//; if ($chan=~/^([\d\w\_\-\/]+\.[\.\d\w\_\-\/]+)\s([\d\w\_\-\/]+\.[\.\d\w\_\-\/]+)$/) { diff -ruN ../infobot-oxford/src/IrcHooks.pl ./src/IrcHooks.pl --- ../infobot-oxford/src/IrcHooks.pl Thu Jan 6 23:54:02 2000 +++ ./src/IrcHooks.pl Wed Jan 26 01:14:40 2000 @@ -54,6 +54,11 @@ return; } +sub IrcJoinHook { + my($nick, $where) = @_; + $joined{$nick}=20; +} + sub hook_dcc_request { my($type, $text) = @_; if ($type =~ /chat/i) { diff -ruN ../infobot-oxford/src/Process.pl ./src/Process.pl --- ../infobot-oxford/src/Process.pl Wed Jan 26 01:17:29 2000 +++ ./src/Process.pl Wed Jan 26 01:16:24 2000 @@ -9,6 +9,10 @@ $origMessage = $message; $message =~ s/[\cA-\c_]//ig; # strip control characters + for (keys %joined) { + delete $joined{$_} if --$joined{$_}<1; + } + $addressed = 0; return if $instance =~ /antihelp/; @@ -529,7 +533,7 @@ } my($r) = $hello[int(rand(@hello))]; - if ($msgType =~ /public/) { + if ($msgType =~ /public/ and exists $joined{$who}) { &performSay($r.", $who"); } else { &msg($who, $r); From infobot-dev@metronomicon.com Wed Jan 26 20:54:29 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id UAA07975 for infobot-dev-list; Wed, 26 Jan 2000 20:53:36 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from mail.netrus.net (mail.netrus.net [206.251.192.232]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id UAA07972 for ; Wed, 26 Jan 2000 20:53:35 -0500 Received: from rocco (abuse@dialin-pm3-miami-FL-2-136.netrus.net [206.251.198.136]) by mail.netrus.net (8.8.8/8.8.8) with SMTP id UAA23553 for ; Wed, 26 Jan 2000 20:55:42 -0500 Message-Id: <200001270155.UAA23553@mail.netrus.net> From: "Rocco Caputo" To: "infobot-dev@infobot.org" Date: Wed, 26 Jan 2000 20:55:43 -0500 (EST) Reply-To: "Rocco Caputo" X-Mailer: PMMail 2.10.1999 for OS/2 Warp 4.00 In-Reply-To: <3887D4BB.7C21FB90@cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: More Trust (was: "Re: (null)") Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O I originally wanted to run this past Kevin before posting it to the list, but his address seems to have dropped off the face of the 'net: The original message was received at Fri, 21 Jan 2000 20:35:43 -0500 from abuse@dialin-pm3-miami-FL-2-116.netrus.net [206.251.198.116] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to cs.cmu.edu.: >>> MAIL From: <<< 451 Nameserver timeout during parsing ... Deferred: 451 Nameserver timeout during parsing Message could not be delivered for 5 days Message will be deleted from queue So, here's the message: On Thu, 20 Jan 2000 22:38:35 -0500, Kevin Lenzo wrote: >ping, > >scozens@pwj.co.jp wrote: >.. >> Rocco Caputo writes: >.. >> > On the receiving end, you get an event that says "you got this >> > thing, \@thing". >> >> Eee. Um. That's nice, but... isn't it a little trusting? I mean, >.. > .. >back to vivification. if Infobot=HASH(), or its image, is seen >in the serialized form (as with using Leolo's XML::Storable), >the object getting the reference should make appropriate moves >to vivify the code of an object from the _internal_, safe store. > >i'm not sure how the ref server does this, but i think the >vivification mechanism puts a lot of the burden of security >onto the users faith in their internal code, which is pretty >much on par with using modules. and modules, it seems, should >be able to authenticate and secure channels as any other >Entity might... hmm. > Filter::Reference just passes references around. Stuff's frozen on the sender side (&freeze call); it's thawed on the receiver's side (&thaw). If it was blessed to begin with, it's reblessed at reconstitution time. It makes no guarantees about the validity of the data that it moves; that's better left to the receiver because she knows what the data's supposed to look like. > >> >> > Artur/Sky has a patch pending that lets it use Compress::Zlib >> > transparently, so network traffic can be balanced against CPU. >> >> Oh, wow. That's special. > >Do we have Filter::PGP yet? That or something like it would >help move the burden of authentication. You could trust >some hosts more than others for certain types of transfer -- >like tainted 'references' that might vivify into evaled perl code. > Stackable filters would be excellent here. Pipe::PGP looks like a good start for a Filter::PGP. The filter would probably build a Pipe::PGP in the background at constructor time, and sign, authenticate, encrypt or decrypt the things that go through it. Speaking of validating tainted references, here's some design I have in a dusty old development directory. Its MUD/Agentspace focus may not be entirely appropriate for infobot, but it seems to address some of the same problems. [ Names: Universe is an object environment/MUD/Agentspace; Continuum is a peered network of universes. ] Object Transferrence (Roaming) Sending an object 1. Extract a portable representation of the object from the dictionary. 2. Recursively extract as portable representations all templates from which this object inherits. [ This assumes a sandbox, possibly running atop one or more virtual machines, and an object repository that treats code as data. I seem to be writing this in my spare time. ] 3. Bundle the objects together. 4. Prepend internal headers to the object bundle. 5. PGP sign the object & headers. 6. Compress the bundle & headers. 7. Prepend external headers to the compressed object bundle. 8. Place the headers and bundle into the outbound object queue. Receiving an object 1. Accept the object and place it in an inbound queue. 2. Record important details of the transfer as external object headers. The machine ID of the remote Universe. The date and time of receipt. Dequeuing a received object 1. Remove the object from the inbound queue. 2. Verify the external headers. 1. Contact the object's alleged home Universe and acquire its PGP public key if necessary. If the alleged home Universe is unreachable, add an "unreachable" external header to the object and put the object back in the incoming queue with a 15-minute "do not disturb" delay. Double the DND delay for every subsequent connection failure. Return the object to its author after 8 failed attempts to acquire a PGP key. Set the destination address to the object's alleged author and place it in the outgoing object queue. 2. Decompress the object. If the object fails decompression, add a "damaged object" external header, set the destination to the alleged author, and place the object in the outbound queue. 3. Verify the object's signature. If the signature does not match (what?), add a "possible forgery" external header, set the destination to the alleged author, and place the object in the outbound queue. 4. If the object passes all initial tests, import it and the templates it rode in on. Place the object in a safe landing area. Access permitting, the object may be able to leave the landing area and move about the Universe. 5. If the object crashes for any reason, it is packed up and shipped back to its owner with external headers describing the reasons for error. External Object Headers From Each object requires a plaintext From header so that the receiving Universe knows where to look for a public PGP key. The rest of the headers will be inside the signed, compressed object. This header is external so that there is a chance of returning corrupt objects. If the key acquired from the Universe in the From header does not match, then the object is returned to the From site in a body bag with a "possible forgery" note. If the PGP key is on file, but the key's source does not match the Universe in the From header, then the object is sent to the Universe in the PGP key with a "possible forgery" note. Internal Object Headers Personal Security Level Contains the level of trust that the object's home Universe placed in the object's author at the time when the object was set. Notes about PGP & Sharing Objects Long, blocking processes A second process will be required to handle time consuming tasks including PGP signatures and verification. This can be tied into the main process with a soft-blocking job queue or a non-blocking queue with job-completion callbacks. Time Every Universe in a Continuum must use the same time standard. The Universe kernel will detect strange time changes and realign its clock to stay current. Object IDs Object IDs are unique even across Universes since part of the ID is the object's home Universe. This allows Universes to assimilate foreign objects without namespace problems. Object Purity Objects may only inherit from templates originating in the local Universe. A local Native user may copy foreign objects to make inheritable local versions with separate Object IDs. The new USL becomes Native and is owned by the admin. This is a potential security hole. Be sure to check over the object's code before allowing it to be invoked. [ Templates do not rely on Safe.pm; instead, they are a source-validated subset of Perl with object manipulation extensions. Universe code (Ptah) is validated and translated into native Perl, then eval'd into a coderef for reuse. ] Template Expiration Imported templates expire when all objects using them have left the Universe. Since each incoming object has the templates it needs, we can expire them as soon as they're obsolete. Security Classes Universal Security Class (USC) The USC is the amount of trust that the local Universe places in the Universe where an object was created. Personal Security Class (PSC) This is the amount of trust that the object's native Universe admin places in the user who created the object. An object's author's PSC is embedded in the object at the time it is exported from a Universe. Roaming agents' PSCs do not change even if the author's PSC changes. Classes: Malicious Universal This Universe does not trust the remote Universe at all. This is equivalent to the stranger USC, but the object is returned immediately to the source with an access violation. The admin who flags a Universe as malicious must record the reasons behind doing so. Those reasons will be included in the access violation message, along with the date and time of the access change and the name of the admin who flagged the Universe. The malicious Universe's USC may be changed by a quorum of admins. If there are fewer than three admins, then the malicious Universe must be approved twice. The malicious status doesn't change automatically. Personal This Universe does not trust the user at all. This is equivalent to the stranger PSC, but the user must be approved by a quorum of admins before they can become familiar. If there are fewer than three admins, then the user must be approved twice. The malicious PSC does not change automatically. Stranger Universal This Universe does not have the PGP public key for the object's home Universe on file. The object will be held in escrow until this Universe can acquire the object's home Universe's public key for signature validation. The object's home Universe's USC becomes familiar when the PGP key is acquired. Personal The object's author is a temporary or anonymous user. The admin places minimal trust in this user, and any objects she creates have access only to the most harmless commands. She probably doesn't even get to use loop commands. Familiar Universal The local Universe has the object's home Universe's PGP public key on file, but the local one doesn't place special trust in the remote one. The object's home Universe may then be held accountable for the actions of its users. Personal The object's author is registered with her home Universe. She is accountable for her objects' actions, but she doesn't have enough access at this point to do any damage. This type of user has access to normal commands. Some denial-of-service attacks (infinite loops, for example) may be possible, but the system must be able to recover quickly. Denial-of-service exceptions will be logged, and the system may temporarily flag users and remote Universes as malicious if they generate more exceptions per unit time than the admin thinks is reasonable. Friend Universal The local Universe places extra trust in the Universe where the object was created. Personal The object's author is a special friend of the admin. Trusted users' objects have access to more dangerous commands, but they should not have access to private system or user data. It should be impossible for a friend object to permanently harm a Universe. Think "co-sysop". Native Universal The object was created in the local Universe. Objects created in other Universes never have the Native USC. The local Universe completely trusts itself. Personal The user of this object is an admin in her home Universe. She has ultimate access to everything, but the system should still be robust in the face of admins of little clue. Class Combinations Universal + Personal = Combined security level Stranger + Stranger = None Stranger + Familiar = None Stranger + Friend = None Stranger + Native = Minimal Familiar + Stranger = None Familiar + Familiar = Minimal Familiar + Friend = Average Familiar + Native = Average Friend + Stranger = None Friend + Familiar = Average Friend + Friend = Average Friend + Native = Extra Native + Stranger = Minimal Native + Familiar = Average Native + Friend = Extra Native + Native = Ultimate > >> > On the decentralized side, factoids could be propagated like >> > Usenet news messages. Factoids won't get lost if there are >> > redundant paths. >> >> OK, let's take this principle and run with it. Here's my complete >> train of thought on how interbot is going to work if we go with a >> peer-to-peer network. How you traverse it is up to you, but I've tried >> to make it a DFA. :) >.. > >Phew! OK i have some ideas to throw into the pot here. > .. This explodes my brane. I'll chime in again on it once I can wrap my head around it. -- Rocco Caputo / troc@netrus.net / *paf* From infobot-dev@metronomicon.com Thu Jan 27 16:48:48 2000 Return-Path: Received: (from mail@localhost) by token.metronomicon.com (8.9.3/8.8.7) id QAA29429 for infobot-dev-list; Thu, 27 Jan 2000 16:48:18 -0500 X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f Received: from chaos.wustl.edu (masque@chaos.wustl.edu [128.252.133.13]) by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id QAA29426 for ; Thu, 27 Jan 2000 16:48:17 -0500 Received: (from masque@localhost) by chaos.wustl.edu (8.9.3+Sun/8.9.3/HappyFunMail) id PAA23603 for infobot-dev@metronomicon.com; Thu, 27 Jan 2000 15:48:43 -0600 (CST) Date: Thu, 27 Jan 2000 15:48:43 -0600 From: Masque To: infobot-dev@metronomicon.com Subject: Bug Message-ID: <20000127154843.D15817@pound.perl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Sender: infobot-dev@metronomicon.com Precedence: bulk Status: O purl, hlaghblagh is and you are neato and \you \are neato and you \are neato and \you are neato OK, Masque. hlaghblagh? and purl is neato and you are neato and you are neato and you are neato Oh, SURE. >purl< hlaghblagh [purl] i guess hlaghblagh is and i am neato and i am neato and i am neato and i am neato While purl is indeed neato, this seems weird to me. ;) Masque.