Better Than Groups

[Abstract: Proposal for a system of granular permissions and a label system of access lists to simulate all the abilities of Groups and to go far, far beyond their capabilities, while at the same time re-vamping permissions AND adding a powerful new editing tool: The property outline.] Please read on if this piques your interest! (Bolded text has been added for the skim-readers...)



Imagine Second Life without the prim... Instead, there are themed sets of parts with which to build, only. Then what this forum would be about is: what new themes to add and what new parts to provide to improve the residents' toolboxes.

Isn't having raw prims to work with instead of pre-made cookie cutter parts what MAKES Second Life... Second Life?


I think reworking groups will get us nowhere -- Our needs are far too varied for mere groups. We need to get down to the "prim" of the issue. Only then will we have the creative expressiveness that Second Life is known for, but now in terms of how players associate, and not just build.


If you list what groups are, one would be a label and everything else would be permissions.

Ah... Permissions. That's been another limiting factor and subject for continued discussion for a long time. But in looking at this breakdown of what groups ARE, it turns out that both issues are one and the same. So lets run with this and see where it takes us.


First, imagine a window with a list of all properties of an object in outline format. That's a pretty powerful thought to start with! You could edit by numbers or even save objects offline for backup. You might have a selection containing several object, expand one of those objects to see its prims, expand a prim to see its properties, expand a property to get down to the numbers... It would be a hierarchical object view, something I think a lot of people would love to have as a tool, no?

But it can be so much more than that, even. Now you can go anywhere in the outline and add an access property to any object OR property. This new property can be permissive with exceptions ("everyone but" or restrictive with exceptions ("nobody but" in any of several categories such as: View (ability to expand and inspect this item and all its [otherwise unprotected] sub-items in the outline), Modify (ability to change the properties), and Copy just to name a familiar few.

What does this mean? I can make an object and set its root access so that it can't be modified, then dig down to the texture property of one face of one prim and let the owner modify it (along with the texture property's sub-items of offset, scale, color, etc). I now have a picture frame that requires no scripting to add pictures to... The new owner can just re-texture the photo, but the rest of the frame remains unchangeable. This is permissions on a property-level and not just for entire objects at once. (Though you can, of course, still do that.)

This granular take on permissions, as presented in an outline format, opens the way for easy to manage and VERY powerful permissions. No longer will they be all-or-nothing with a system like this in place.


Now what has this to do with groups? Well, it replaces them... Almost. With similar outlines on land, all the permission elements of groups can be simulated with even GREATER potential. The only thing left out is the label I mentioned above, we would still need those. But instead of the label controlling the permissions, the permissions would USE labels.

So while I could grant access to individuals, I can also grant access to all individuals that have a particular label, that are part of a particular group of people. But more than that, labels go so much farther than groups...

I make two new labels, one with a short list of people and one with a long list of people. I allow any member of the short list to add to it, but only allow them to remove their own name. On the long list, I give all players the access to add their own name, and give everyone ON the list the access to remove their own. I further allow anyone with the first label to add or remove anyone from the second. And so we can perfectly simulate the standard, open-enrollment group. But we could now go farther and also do things that are completely impossible for groups as they are today, or with any other group-oriented system one could think of.

I now set out two badge objects I made, one for members, and one for staff. On the member badge, I edit its top permissions and limit Copy to members of the long list. On the staff badge I do the same, but for the short list members only. I can also either limit all transfers completely, or allow transfer to anyone with the same permissions needed to Copy. You can't do THAT with the current system.

On a parcel's outline list, I can grant or restrict permissions based on either label... But more than THAT, to OTHER labels as well! There doesn't have to be just TWO member types in a "group" anymore. There can be any number of related (or even UN-related) labels. I can set an object to be manipulatable by anyone with any label from a long list of them, or even require memberships in several at once.

But wait, there's more!

I can make a label and add names to it, then restrict View and Edit permissions to myself alone, thereby making it just a private list of names. But I can have a script on the other side of the grid checking membership in that group whenever anyone interacts with its object, and my objects will know who is or isn't in that group, immediately! I could give object rez permission on all of my lands to anyone with a particular label and keep and maintain that label's member list myself. I could have a fleet of vehicles that only work for member of a label, and have a vendor that will add you to that label for a certain amount of time for a fee.

You know those land access tickets that NO ONE uses? You could do the same thing under this system but with FAR more versatility.


Really, I'm just scratching the surface here with what PRIM-LIKE permissions would mean. This isn't the Sims... We aren't restricted to pre-fab parts to build with. Nor should how we interact be limited to gross units of access. Granularity is key!


I propose this as something BETTER THAN GROUPS!


MICRO-PERMS!


Thank you for your attention, and (if you think this IS the way to go) you help in promoting the idea to the Lindens. Lets make it a catchphrase (like "Havok 3": "micro-perms"

Oh, and as this touches quite heavily on permissions, I wanted to state my current views on the Creative Commons system. The CC is a system designed for use in a real world of paper and people, hence its simplicity. But we are "living" in a completely digital world, and we should take advantage of our digital environment in creating a system of permissions.

We CAN do more, so why settle for less just to be doing the "in" thing?

We're a population of VERY creative people (I know because I've seen what the residents of Second Life have done over the past few years) and we should put that creativity to work making a system of permissions, groupings, and social dynamics that is a perfect fit WITH that creativity.

The CC is good for what it was designed to do, but don't shove that square peg into such an amorphous hole as we have dug here for our second lives to live in.

I like it.

I like it too. It's a more refined implementation than Jarod Godel's idea of "grouping" calling cards into folders and assigning them individual groupish permissions. His fear, and mine for Tiger's proposal, is that such granularity will obsolesce our current vision of groups.

If Philip, Prokofy et al are willing to let go of a centralized grouping mechanism and allow us the flexibility of detailing individual permissions as we need them, this type of system might be entertained. The stated advantage of reusing the permission outline code for prims, people and land is particularly elegant.

The time to be saved by not having to rewrite the group-related code for that single purpose, and still needing to overhaul the permission system, and still needing to improve the land management tools, should at least capture the developers' attention. But the question still remains whether or not the management at LL will cave their penchant for centralized systems and support the endeavor.

This is an interesting idea.

I see a new market, selling 'group systems' along whatever lines you want to devise. Want a corporate style structure? Go see who is selling the one that has the right permission set for how you want to run your company.

This past summer, Robin organized an "Events Workgroup" (much like what is being organized here) in order to address concerns with the Event Calendar. A bunch of us got together, and threw out a lot of cool ideas as to what would make the Event Calendar ideal.

One of the things that quickly became apparent in the discussion, was that there were changes that could be made in the short term, with a minimum of development effort from LL - and changes that were more long-term, that would require significant development time.

Many in the group chose to focus their energies on these long-term solutions for the event calendar, because those were what made the most sense. I was one of them. (Example: Keyword filters instead of categories.)

At the end of the day, however - our conversations that focused on the long-term solutions that required lots of dev time turned out to be futile. Linden had a pre-existing agenda of what they wanted to accomplish, and a set amount of development time that was unswayable.

My feeling is that the situation is going to be very similar here. While I totally agree that these ideas are super-cool, if we create a scope of work for LL that is too broad, we could end up with nothing, or - more likey - what Linden had intended to implement in the first place before they asked for our input.

Correct me if I'm wrong, but my understanding is that the impetus for changing the group tools is to provide covenants so that residents can better police themselves in regards to zoning needs. Additionally, Linden is responding to resident complaints that that the "One size fits all" paradigm of groups currently implemented is insufficient.

While I think its a great idea in the long term, if we're talking about taking groups (or calling cards) a step further to involve object permissions - that may be outside the scope of what Linden wants to accomplish with this latest change. If in these focus groups, we spend the majority of our conversational energies on items that are out of scope, I'm concerned that what Linden will end up actually listening to will be much less than any of us expect.

If I'm off base here, or am misunderstanding what's being proposed - I welcome the correction

It is true that this proposal is quite a big change, and would take considerable effort to implement. But, it comes with "fixes" to many problems at once. Nothing stop-gap will satisfy many people for long. I think only something as open and flexible as this idea (or some other along the same lines) has any hope of lasting OR satisfying the needs of the many.

At this point, I'm not going to limit my suggestions by what I think Linden Lab does or doesn't have the resources and time to do. I want to give them the best possible suggestions I can, and THEN see what happens.

They ask, I suggest.


As to my proposal, I know there are things I didn't cover to save wordage. Voting for example. While it would no longer be tied so tightly to groups, there would still need to be a way to do voting. But the current voting system can be re-used, just tying it to a list of labels instead of a single group. Permission to create a vote for a particular label would be one of the label's properties. The only thing we'd lose is the hard-coded ability for the majority of members to vote a staff member out of their position. (But I think that is so rarely used properly OR successfully, that its loss is no loss at all.)

EDIT: Of course, a vote can still be TAKEN for that purpose, leaving it to whomever has the power to actually follow up on the result and eject the disbarred staffer.

If people don't quite follow what I mean by all this, I can make some mock-ups if you think that would help...

I think Tiger's is a very good suggestion, but would like to expand on the voting part since I think this is an essential issue with groups and land management. Note, this may be what Tiger has in mind, but it wasn't clear to me.

The idea is that members of a list wouldn't just be people, they could also be passing votes of a set of people, "vote members". Only if the vote passed would the permission be available. The list of eligible voters, the type of voting, required majority, automatic notification types, how long the voting would remain open, etc. would be set up front. The rules for changing the "voting member" would themselves be a set of permissions handled like any other.

As an example, suppose a sim was set up with restrictions on what could be built. As is now, build permission would be given to the individual land owners so they could build anything they wanted. However, the enforcement would be to also have a "vote member" in the list allowing the rest of the land owners on each parcel to modify builds on that pacel.

The "vote member" would mean that a vote could be called by anyone in the vote list, requiring say 2/3 majority within 2 weeks with automatic IM notification of the vote. If the vote passed, the builds on the land would be modifiable by the people in the vote list. To shut this permission off, another vote would be taken, and if it failed, the exclusive permission would revert back to the land owner. In this example 2/3 would be required to get the permissions and 1/3+ required to shut it off, but the rules would be whatever was set up for that "vote member".

This could also be applied for all other permissions, such as buying and selling land owned by a group. These might be set up by the group as only having a "vote member" in the buy/sell permissions list, so only by having a vote would the permission be available. Of course they would then stay available till a failing vote were taken.

Mock-ups would be excellent.

I'm not entirely sure I follow you here, so I'll just go over my thoughts on voting. (Again, if you just want to skim, read the bold bits and anything around them that looks interesting.)

The current group system can use voting in two different ways (ignoring details like length of the vote, number needed to pass, etc): 1) as a poll, where the system doesn't do anything with the results except display them to the group members, and 2) as a recall election, where if enough people register a vote of "no confidence" in one of the staff members of the group, that staff member (even if the creator of the group) is ejected.

It is the second part that most people have a problem with, along the lines of "it's MY group and MY assets, why should members be able to kick me out and steal my stuff?"

At the same time, what it was meant to provide was a model of a democratic government where leaders are elected and impeached. But any other form of organization is hindered by this feature. The most common form of group is a corporation, and if the employees can kick out the CEO on a whim, it's just not safe. And other forms of government are very difficult if not impossible to organize in this system.

My suggestion is to just do away with recall elections entirely, leaving just the polling system. When you create a poll, you pick one or more labels (maybe "access list" is a better term... Yes, I'll call them that now to be more clear)... one or more access lists of people to send the poll to. So if an organization has three different types of members, then you'd send the poll to all three access lists.

If you wanted to make a democratic organization with one Leader and everyone else a Voter, with the right scripting you could still replicate recall elections. If scripts can edit the names on the access lists, start and stop polls, and react to their results... Then you can SCRIPT a democratic government, same as Linden Lab did on the server side originally.

But at the same time, you could script any OTHER form of government you wanted.

Power to the people.

I'm saying something quite different I believe.

My proposal is that rather than limiting voting to recall elections or other group member actions, make them a general feature of all the permissions access lists (ACL's).

My understanding of your proposal is that there is a tree of permissions with ACL's of people with that permission.

What I'm proposing is that those ACL's can also include members which are not AV's, rather are objects which represent the latest result of a poll (I'll refer to them as "Polls" rather than "Voting Member" for clarity). These Polls contain their own lists of AV's, but are only active if a vote to activate that Poll by its members passes. Otherwise, it's in the ACL, but can't do anything.

The idea is that to enable convenant enforcement, these Polls will stay in the ACL's for various permissions only to be activated if something needs correction. Since it requires a passing vote, these can't be activated unless several people agree that there is a problem that warrents action out of the ordinary.

By adding these Poll objects to the types of objects an ACL can contain, it's a general capability for all permissions.

In my original example, plots of land would have a permission for building which would have an ACL, normally just containing the owner AV. In a covenanted sim, the ACL would have 2 members, the plot owner AV and a Poll consisting of all sim land owners minus the plot owner. If the land owner violated the covenants, 2/3 of the sim land owners could vote themselves the build permission on that land and fix the builds.

I'm all for that functionality, but to have Linden Lab code that into the base system, you block out other organizations that would want to run things differently. But you could still do this with my system suggestion, through scripts, without needing to define and code every sort of voting system people would like. Instead, one person can make an object with a script that group members can see, but can't change (so people can see what it does, but can't mess with it). The script could be written to permit whatever voting rules the group wants to operate under, and modify the access lists accordingly.

Further clarification and additional features...


As prims can be linked together into an object, so too would access lists be joined into a group. The group would then behave very much as groups do now. You would be able to search for groups, join them, etc. In fact, done right, the change to a system like the one I'm proposing would be invisible to the general populace, except that more is possible and there would be greater diversity in how groups are arranged.

It would only be in creating a new group that the differences become obvious. Though if certain common patterns of groups are pre-defined and pickable when setting up a new group, starting one will be just as easy as before.

But the power-user can dig in and customize to their hearts content.


This is a bottom-up design. It's like defining the basic Lego brick and how it snaps to other bricks. From there, you can build whatever you want.

The current group system and all other change proposals I've seen are top-down designs. They are like defining all the possible things you may want to build from the start, and presenting you with a menu of choices to get the one you want. And if what you want isn't possible in that system, then tough.

Not only does the bottom-up design let you make any custom creation you desire, but you can also create the top-down designs as pre-fabricated parts and anyone that doesn't want to build from scratch doesn't have to. (As with building... most people don't make their own furniture, the buy it pre-made from others.)


When starting a new group, you would be presented with a pop-up list of prefabs to choose from. Perhaps something like: Classic Group, Corporation, Friends, Social Club, Custom, etc...

Choosing "Custom" would create a new group with very basic settings, blank and ready for customization OR the application of prefab organizations that other residents provide for free or fee.

The "Friends" prefab group would make a private group that the founder can invite their friends into. No one gets rights to modify anything. It's just a social group. The "Social Club" group would be similar, though public for anyone to join.

The basic "Corporation" group might have a list of executives and a list of empoyees, with access permissions to match the positions.

Of course, once a prefab is chosen, it can STILL be modified and customized to meet the organization's needs.

I agree with Tiger on the idea of prefabs and power access.

I'm not 100% sure what the prefabs should be my list would probably run:

Rentals group
Company
Social group
Building/scripting group
Club/Events group
Custom

Maybe I'd have some variations in them - collective, democracy, aristocracy perhaps, so you'd choose rentals, then feudal/aristo if you want a land barony, but rentals/collective if you want shared land with your partner (in a business or personal sense). Feel free to add to either list, but it gives us a mechanism to have two click prefabs in a wide variety of styles (15 two click prefabs from my lists for example) and still retain that entirely customisable model.

I've deliberately left multi-tier hierarchies out of my list btw, because I think they'll be too tricky to predefine, but I think that *should* be part of the options that are built in too.

Overhauling the money system would be nice to go with the permissions etc and is a logical part of the system that should be addressed.

I like the idee. Sounds very plausible and efficient to me. The term "prefab" is a little unusual, though (in IT circles you would usually talk about a "template" maybe), but it is a term that is very much "Second Life".

I don't want to highjack the thread, but would like to point out that this is very similar to the idea (not mine) of "roles" for users right, I outlined here. One more reason to like it.

One addition I would like to add: If I understand it right what has been proposed here, a list of prefabs/templates should be predefined for all SL users. Why not allow them to be swapped like objects or notecards? In the end such a "type" of group is just a set of on/off switches. If i have made one group and I like its structure, I would simple "save" the setting in some way and give this document to someone else who can use it as a template for his or her next group.

OK, here's how I have it mapped out in my mind. You have a Group Structure object. Within this Group Structure are Labels. Each Label has three properties: Add, Remove, and Permissions, detailing what each Label is allowed to do within the Group. Under Add, you would have a list of people or Labels with permission to add a member to the Label and a required percentage vote (if any). Remove has similar functionality, describing who can remove people from the Label, and how many are needed to do so. Actions that require a vote would be passed to everyone eligible to vote on that issue, possibly as a dialog. The final category, Permissions, describes what members of that Label can do with group resources, such as withdraw group funds, delete Group, modify Group, see individual poll votes, etc. Here's a sample of what I'm talking about:

GROUP: ExampleGroup
LABELS: Owners, Officers, Members

Owners:
ADD:
Owners (Simple Majority)
Officers (2/3 Majority)
REMOVE:
Self
Owners (Simple Majority)
Officers (Unanimous Vote)
PERMISSIONS:
Withdraw Group Funds
Edit Group Objects
Modify Group Structure
Delete Group (Unanimous Vote)

Officers:
ADD:
Owners
Officers (Simple Majority)
Members (2/3 Majority)
REMOVE:
Self
Owners
Officers (Simple Majority)
Members (2/3 Majority)
PERMISSIONS:
(none)

Members:
ADD:
Self
REMOVE:
Self
Officers
Owners
PERMISSIONS:
(none)

I've been refining my ideas and the latest rendition can always be seen in my blog.

I'm about to put up a new entry today. After writing the last one, I've found the pattern that would seem to work in all cases, so I want to try it out.

If you haven't seen the blog yet, I've been using an outline pattern for both groups and land. The same format can be used for objects in the fullness of time. The outline always starts with two sections:

1. Everyone
   
2. Owner/Founder
   

The Everyone section includes everyone that has joined, for groups... Everyone that is on the plot, for land... And everyone, everywhere, for objects.

The Owner/Founder section will have the person that created the group, for groups... The owner of the land, for land... Or the owner of the object, for objects.

[ I'm torn between letting groups change who is in the Owner/Founder member list or not. Land and objects definitely could not, since there can only be one owner. For land and objects, you would have to make a new section with full permissions and add people to that instead of adding them to the Owner/Founder section. You could do the same for groups, but as it is far more likely that people will want/need multiple people with complete access to the group, it might be best to let them be added to the Owner/Founder section. Besides, only in groups can you edit the Everyone section's member list, so why not the Owner/Founder section too? Okay. Made up my mind: Yes. ]

A new group, parcel, or object would have just these two sections when it is first created, but you can add more, named however you like.

Each section will have two parts to it, like so:

1. Permissions
   
2. Members
   

The Permissions part will list what members of that section are allowed to do. The Everyone section will start with a few minor permissions that can be removed if not to the Owner's liking. More can also be added.

The Owner/Founder section will have a special Permissions part that can't be opened or modified. Instead it is just marked as "Permissions (all)" and grants access to do anything to the object, land, or group.

The Members part lists all the people in that section. This list can't be opened or modified for land or object's Everyone section, and is marked "Members (all)". For groups, it will list everyone that is in any way part of that group. Adding people to this list adds them to the group, and removing them will eject them completely. While everyone in the Owner/Founder section of a group will appear in here, they will not be removable here.

The Owner/Founder section's Members part will start with only the person that made the group or that owns the land or object. In groups, you can add members of the group to this section, but not for land or objects (since there can only be one owner). You can't remove the owner from this section for land or objects, but you can for groups... IF there is someone else in there too. There must always be at least one person in the Owner/Founder section's member list, or the group is disbanded. So it would be possible to create a group, invite someone to be a second founder, then withdraw from the group and leave the new member in charge.

So if I made a new group, this is what it might look like:

1. Everyone
   1. Permissions
      1. Group IMs
         
      2. Land Access - Unlimited
         
      3. Group Inventory - Take Only
         
      
      
   2. Members
      1. Tiger Crossing
         
      
      
   
   
2. Owner/Founder
   1. Permissions (all)
      
   2. Members
      1. Tiger Crossing
         
      
      
   
   

The three permissions I put in the Everyone section are just for example purposes. I'm still working out the details about how the permissions are displayed and manipulated. So grain of salt here.

Check out the blog if you want to see a prettier version of this with icon buttons that can be used to modify the lists.