From infobot-dev@metronomicon.com  Wed Jan 19 20:25:47 2000
Return-Path: <infobot-dev@metronomicon.com>
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 <infobot-dev@infobot.org>; 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 <infobot-dev@infobot.org>; 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 <infobot-dev@infobot.org>; 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: RO





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:

<q[Simon]> purl, wibble?
<purl> Bugger all, I dunno.
<purl> 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 02:25:10 2000
Return-Path: <infobot-dev@metronomicon.com>
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 <infobot-dev@infobot.org>; 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" <sburke@netadventure.net>
Subject: factoid
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: infobot-dev@metronomicon.com
Precedence: bulk
Status: RO

The long arm of coincidence yet again...

>Date: Thu, 20 Jan 2000 00:05:03 -0500
>From: Wordsmith <wsmith@wordsmith.org>
>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 14:27:20 2000
Return-Path: <infobot-dev@metronomicon.com>
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 <infobot-dev@infobot.org>; 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 <larry@wall.org>
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: RO

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 21:41:00 2000
Return-Path: <infobot-dev@metronomicon.com>
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 <infobot-dev@infobot.org>; 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: RO





(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  Fri Jan 21 02:18:20 2000
Return-Path: <infobot-dev@metronomicon.com>
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 <infobot-dev@infobot.org>; 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" <troc@netrus.net>
To: "scozens@pwj.co.jp" <scozens@pwj.co.jp>
Cc: "infobot-dev@infobot.org" <infobot-dev@infobot.org>
Date: Fri, 21 Jan 2000 02:19:10 -0500 (EST)
Reply-To: "Rocco Caputo" <troc@netrus.net>
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: RO

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  Tue Jan 25 11:04:55 2000
Return-Path: <infobot-dev@metronomicon.com>
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 <infobot-dev@infobot.org>; 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" <mpoole@in-con.com>
To: "infobot dev" <infobot-dev@infobot.org>
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: RO

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>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.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>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</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Could someone add an only welcome =
recent=20
on_joins?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>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.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; thanks,=20
urgen/efnet</FONT></DIV></BODY></HTML>

------=_NextPart_000_0A05_01BF670B.49DE4D70--


From infobot-dev@metronomicon.com  Fri Feb  4 11:37:15 2000
Return-Path: <infobot-dev@metronomicon.com>
Received: (from mail@localhost)
	by token.metronomicon.com (8.9.3/8.8.7) id LAA28703
	for infobot-dev-list; Fri, 4 Feb 2000 11:37:00 -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 LAA28700
	for <infobot-dev@metronomicon.com>; Fri, 4 Feb 2000 11:36:59 -0500
Received: (from masque@localhost)
	by chaos.wustl.edu (8.9.3+Sun/8.9.3/HappyFunMail) id KAA04979;
	Fri, 4 Feb 2000 10:37:08 -0600 (CST)
Date: Fri, 4 Feb 2000 10:37:07 -0600
From: Masque <masque@pound.perl.org>
To: scozens@pwj.co.jp
Cc: infobot-dev@metronomicon.com
Subject: Re: Patches and Matches
Message-ID: <20000204103707.M9197@pound.perl.org>
References: <4925687B.0028B7F3.00@pwj-gw-n001.pwj.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3i
In-Reply-To: <4925687B.0028B7F3.00@pwj-gw-n001.pwj.co.jp>
Sender: infobot-dev@metronomicon.com
Precedence: bulk
Status: RO

There's a lot of snippage in here.  Figure it out.  

On Fri, Feb 04, 2000 at 04:25:03PM +0900, scozens@pwj.co.jp wrote:
> First of all, congratulations to Oz on the success of Sphinx;
> if I've got it right, he's out at Linuxworld right now talking
> about Sphinx and Sourceforce. Hope it goes well. There's been
> a lot of very good coverage of Sphinx in the techno web press,
> and I think we can all agree it's going to be an important
> milestone in, for want of a better phrase, free speech.
 
::APPLAUSE::

(There, now wasn't that worth a six line quote?)

> To directly contradict all that I've just said, I don't know if
> we're yet at the point where we can start deprecating the old
> bot. Certainly, the new one should be the primary focus of
> development right now, and I'm hoping to run myself completely
> out of business pretty soon. :)
 
It would be nice if the bugs introduced between 0.44.2 and now would
go away, otherwise I'm all for the new bot getting primary focus.
Give us a procedure for creating extensions, and we'll get hopping. 
:]

> However, if you do still want to kick around with it, here's
> me top 10 wish-list for what I'd like to see in the current 0.4x
> bot before we wrap it up. I'll be randomly implementing some of
> these as and when I get bored, so give me a shout if you want
> to play with them:
> 
>      1) I don't want this to happen:
> <foo> Simon?
> <Simon> Yes?
> <purl> Simon is a matter of fact, or a villian in a million.
> 
> How to avoid it: keep track of who's on the channel. (This is
> an excuse to put some more user-defined hooks on IRC events)
> On join : $whowhere{$channel.":".$person}++
> On part/nick change: $whowhere{$channel.":".$person}--

Sounds good, provided the behavior changes when addressed.

 <Masque> Simon?
 <Simon> Yes?
 <Masque> Sorry, meant:
 <Masque> purl, Simon?
 
> Don't respond if not addressed and $whowhere{$channel.":".$query}
> 
>      2) Privacy on `seen', especially if spanning multiple
> channels. Hint, this is bad:
> 
> <foo/#perl> purl, seen nou?
> <purl/#perl> nou was last seen 3 hours ago on #hotsex saying
> "whip me again with that leather vegetable!"
> 
> I suggest multiple levels: users should be able to say
> `watch what I say and when I say it', `watch when I say something'
> or `don't watch me at all.' Further, channels should have a setting
> to state whether seen data is shared outside that channel.

I disagree, I would implement it soley based on channel status.
If the channel is +s and I say something, I think purl should keep
that information confined to the channel.  Otherwise I think the 
current system works fine.  If you're in #poundmeharder and it's 
not +s, people will know with a simple /whois anyway.

>      4) Ditto spanning multiple servers. The cheap hack we're
> doing with purl could be better. This could be a big project requiring
> some big source changes! Do not rush off and implement lightly!

I'm not sure exactly what you mean, but it would be nice if purl
had a list of servers to choose from, so that she would come back
if her current server went down.

>      5) Anti-escaping. This is tedious:
> purl, \what \I want is <reply>\why do \you ask \what \you want\?
> 
> and people get it wrong on a daily basis.
> 
> This is not:
> purl, literal what I want => <reply>why do you ask what you want?

Very good idea, though s/=>/is/ will save confusion.

Then again, when has that ever been a goal of software design.... ;)

>      6) Update documentation, POD on extension modules and maybe
> autogenerate manual.

I VOLUNTEER!  I'd be THRILLED to help...find someone else to do this. 
 
>      7) Collect other cool tales of what people are doing with
> infobots and write a web page with links.

heh.  Look up 'Sherlock' sometime.  Talk to joebloe.  There certainly
are some interesting other projects out there.  Otherwise a great idae.

>      9) CPAN i // or search.cpan interface

Nobody has done this YET!?  Six months ago I listed it in-channel as 
my next project, and a whole bunch of people said things like "Way
ahead of you" and "Already almost done" and "Shut UP Masque, we're
sick of hearing you talk" and "Where's stimps?".  I took that as 
a sign, else I'd have turned one in by now.  Maybe I can dig up the
framework I put together....

>      10) Masque, you had a cool extension idea I was going to steal
> but I've forgotten what it was.

Erm, uh, well, hrm.

OH.  I think I know what you're referring to.  I'll go find you now.
 
> That'll do for the moment, because I have just got a Perlix bug
> report, meaning that the world is surely about to end.
> 
> Simon

Masque.

From infobot-dev@metronomicon.com  Wed Feb  9 17:50:34 2000
Return-Path: <infobot-dev@metronomicon.com>
Received: (from mail@localhost)
	by token.metronomicon.com (8.9.3/8.8.7) id RAA01586
	for infobot-dev-list; Wed, 9 Feb 2000 17:50:34 -0500
X-Authentication-Warning: token.metronomicon.com: mail set sender to infobot-dev@metronomicon.com using -f
Received: from vegovc.s-sser.lj.edus.si (IDENT:root@vegovc.s-sser.lj.edus.si [193.2.190.78])
	by token.metronomicon.com (8.9.3/8.8.7) with ESMTP id RAA01583
	for <infobot-dev@infobot.org>; Wed, 9 Feb 2000 17:50:32 -0500
Received: from localhost (black@localhost)
	by vegovc.s-sser.lj.edus.si (8.9.3/8.8.7) with ESMTP id XAA03492
	for <infobot-dev@infobot.org>; Wed, 9 Feb 2000 23:55:00 +0100
Date: Wed, 9 Feb 2000 23:55:00 +0100 (CET)
From: Tit Petric <black@vegovc.s-sser.lj.edus.si>
To: infobot-dev@infobot.org
Subject: modularized infobot..
Message-ID: <Pine.LNX.4.10.10002092350160.3203-100000@vegovc.s-sser.lj.edus.si>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: infobot-dev@metronomicon.com
Precedence: bulk
Status: RO

can someone please check
dark.skylined.org/~twilight/wanker/wanker.tar.gz
its my modification of infobot .44 ..

anyway idd like to see some of the new features modularized..

read the wanker.txt in there to see what i did
you can ghuess what files by black ++ marks
and maybe by comments at the start..

i tried to comment shit but i didnt make a rule of it
so if its something you need to know.. ask me

err.. ignore the "are" to "je" changes..
the bot is ment to be slovene.. ghuess ill
speak to lenzo on multilanguage support..

check it.

black