Subject: Re: Permissions system of moo

From: [email-masked]
Date: Wed, 24 Feb 1993 05:45:00 -0800

Pavel comments:

> Rather than add groups to the system, I intend simply to remove the 
> current restriction that only `players' can own things.  This will open up 
> the possibility of creating what I call `corporations,' entities that own 
> things and have their own separate identities from the set of players who 
> are their`members.'

I'm not clear what this will gain.  It's simple, for example, to implement
an in-DB version of multiple ownership.  On OpalMOO, we've created what
we call $ownership_utils, which contain the important server builtins
(e.g. $ownership_utils:add_verb and $ownership_utils:add_property) and which 
work off of a corified and protected .owners property.  Properties can be 
`shared' in a similar way by adding two more fake `builtins' which are 
$ownership_utils:property_value() and $ownership_utils:set_property_value().  
There are, to be sure, some more security issues, for example ownership of 
verbs after editing, which have been handled in what I consider satisfactory 
ways.

This works around the server requirements, yet it still makes players own 
things themselves.  And rather than creating a communal owner for groups of 
objects, it's the groups of objects having -sets- of owners.  We've found 
this to be terribly useful as we work on several large collaborative 
projects.

> Simple DB code would keep track of who's allowed to 
> work on behalf of what corporations and, also, of which corporation a given 
> player is acting for at any given moment.  In essence, this allows the same 
> kind of collaboration as a bunch of players getting together and creating a
> pseudo-player that they share, but much more conveniently.

While I think this sounds like a neat idea, I'm not sure what real use it 
would be.  The -easiest- way to handle this, it seems, is through multiple 
ownership, simply put, and this is quite doable in-DB.  It seems that more 
and more complications would be added if we had to keep track of the `mode' 
or `corporation' a player's acting in/for at any given time.

Seth / Blackbriar (all i want is diskbasing, mamma)

---

From: Pavel Curtis <[email-masked]>
Date: Wed, 24 Feb 1993 11:43:00 -0800

> Date:	Wed, 24 Feb 1993 05:45:00 -0800
> From:	[email-masked]
> 

The question is with whose permissions a group-owned verb operates.  I
certainly don't want any verbs that I own with a group of others to run with
*my* permissions.  By symmetry, that verb couldn't be owned by *any* of the
members of the group, so who is there to own it?  In my system, the corporation
owns it, so the verb can only read and modify the things that the corporation
can read or modify, which seems just right to me.

> or `corporation' a player's acting in/for at any given time.

Fortunately, the only operations you need to know this for is
verb/property/object creation.  Editing the code for verbs or the values of
properties does not require a `mode', since you can just check for membership
in the corporation.  I don't know about other folks, but I tend to do my
creations in fairly large clumps, so it might work out fine to simply `time
out' my decision about what corporation I'm representing.  Also, one could
default on verbs and properties to the owner of the object.

	Pavel

---

From: Roger Crew <[email-masked]>
Date: Wed, 24 Feb 1993 12:15:26 -0800

>   so it might work out fine to simply `time
>   out' my decision about what corporation I'm representing.  

For that matter, those of us who are paranoid will want to have a
default corporation that is distinct from the actual player.  (i.e.,
debug the verb while it's living in the default corporation; once
one is reasonably sure it's airtight, chown it).

One could even imagine $no_one as the default corporation for
everyone, though it would probably be better if everyone had a 
default corporation to himself.

And then there's always:

  >@verb bo:diddle this none this
  Caution!  You are about to create a verb owned by yourself that anyone can 
  use against you.  Are you sure you want to do this?  [Enter `yes' or `no']

but the less said about this, the better...
--
Roger Crew
Internet:   [email-masked]
LambdaMOO:  Rog

---

From: Mike O'Brien <[email-masked]>
Date: Wed, 24 Feb 1993 12:08:52 -0800

The scheme Pavel is proposing, of "corporations" which exist for
purposes of ownership and permission, is similar to the notion of "groups"
as implemented in DragonMUD, which runs a vastly modified original TinyMUD
server.  Don't look for the severe limitations you may associate with
TinyMUD; for the most part they're not there, and groups are a good part
of the reason why.

	Groups serve three major purposes on DragonMUD.  First, they are
groups of people, very simply.  Some groups are controlled strictly by the
group owner (a group may own itself) and exist like clubs.  Second, they
exist to allow portions of the DB to be owned by a common entity which
allows any member of the group to work on that area of the MUD.  Third,
they are used in what passes for "programming", used for quests, to
drive the machinery of what exits work when, and are visible when.  Groups
may be "light" or "dark", which controls their visibility.  Dark groups
can only be seen by the group owner.  Looking at a character shows all
of the light groups that character is in; in most cases these act as a
list of what puzzles the character has solved.  There's even a "Quester's
Rest" room on the MUD which acts as a consolidator to replace sets of
groups with a single blanket group, to keep the lists passably short
for serious questers.

	There are also objects which are really groups.  These behave
like objects in that they may be picked up, passed from hand to hand,
etc., except that the original object remains behind for others to pick
up as well.  This eliminates the limitation that only one person can
run a quest at a time since only one person can carry the necessary
objects.

	All in all, the concept of groups (or "corporations") turns out
to be an extremely powerful one, and you're all invited to go over to
turing.cse.nau.edu 4201 to have a look (no registration required).  The
help facility has recently been upgraded and the wizards are friendly.
(This is also, so far as we know, the oldest continuously running MUD
in existence.)

Mike O'Brien

---

From: Larry Masinter <[email-masked]>
Date: Wed, 24 Feb 1993 14:11:50 -0800

You are your own corporation. Actually, the current server allows
non-players to own verbs and objects, it is just set_task_perms fails.
This is most noticed when a player is toaded by they own stuff.