[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Trust and Discovery

> 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
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?'
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?