From: petersom@ucsu.Colorado.EDU (Mark Peterson)
Subject: Re: TECH: world description
Originator: hlab@milton.u.washington.edu
Organization: University of Colorado, Boulder
Date: Thu, 13 Aug 1992 17:32:59 GMT



dstamp@watserv1.uwaterloo.ca (Dave Stampe-Psy+Eng) writes:

>rmg53668@uxa.cso.uiuc.edu (Ryan M. Grant) writes:
>
>>I've been "MUDDing" before and they really have all these problems
>>solved (to their satisfaction anyway).  I know people rip MUDS all the
>>time, but all these places (especially the better, non-goal-oriented)
>>need is a kick butt interface.  They usually use ownership as criteria
>>for control.  If you made the table, you can make it fly.  There are
>>pre-built areas open to the public, and they have sensible
>>restrictions based on location (past, present, future).  Those places
>>usually obey physics more than others (no teleportation).
>
>The MUD is actually the inspiration for Bernie's and my ideas of
>object ownership (Bernie has used MUDs, I haven't).  Of course, you do
>have a few control rules for an object: presumably, these are sent to
>you along with the ownership of an object.
>
>>I don't see why we don't just throw the stuff to the public
>>(ourselves) and see what happens.
>
>Indeed.  The MUD concept is basically the first cyberspace-- add 3D
>graphics, worldwide sharing etc. and the media will be crawling all
>over the thing.  Bernie and I would like to get a prototype together
>rather quickly (at the PC end) and sort of "grow" the rest of the net
>through incremental development.  After all, the changes will be
>largely transparent to the low-power end user, and would mostly affect
>those high-end network controlling devices.

I think MUDDs are a step in the general direction of Cyberspace,
however, I see a few MAJOR draw-backs to this type of environment.
The problem I see lies in creating security for such a system.  For
those of you whom are not familiar with how the object-oriented system
of how a mud works, it is as follows.

1)      The user types some command.

2)      The system then looks for a procedure that handles that command.

3)      ***Here's the problem.*** The system starts in your inventory,
        looking for an object to handle that command, then it goes to
        the inventory of the room...this could be your player object, or
        some object lying in the room, next it goes to the environment itself.
        If it goes all of the way through this list, and can't find the
        command, it will give you an error.

Here's why this is a problem.  If you override some command, in for
example an object in your inventory, it will never get to the
environment.  This is bad, because a net-runner could override your
security also, which is embedded in the system, simply by calling the
base-level procedures or creating his own to run on your system.

An argument to this would be that you could imbedd security checking
in your base level code, but this will both slow down your machine and
be expensive.  Also, if ever even 1 copy of your custom software got
out to the rest of the net, your security measures would be useless.
Also, you would have difficulty sharing data with the rest of the net.

This is a common problem on Muds, when people become wizards, they
sometimes try to write objects which give them administrative access.

Anyway, this is the major problem I see.  Any ideas???

Mark Peterson

---------------------------------------------------------------------------
Mark Peterson                           petersom@ucsu.Colorado.edu
"To every locked room,
there's an open door."