[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Thu, 20 Jan 2000 22:38:35 -0500
- From: Kevin Lenzo <firstname.lastname@example.org>
- Subject: Re: (null)
> 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
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
> > I have too many ideas and not enough implementation.
> You and me both.
woohoo! i got interbot.org :)