[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
On Fri, 21 Jan 2000 email@example.com 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.