Tiger's Tales

Permissions are all about allowing people and groups of people to do things. At least, that’s the model I’m using. There are two others… Allow everything then indicate restrictions (but that can have dangerous security issues), and mix permissions and restrictions together (but that can/will get messy and confusing).

So if you’ve been following the examples in this blog, you may have gotten the feeling that those dummy permissions I was using may not be so dummy. I did try to keep them self-consistant as I went along, even to the point of going back and tweeking them a bit. I’ve been trying to find a system of encoding permissions that is compact and clear, while retaining the ability to design-in more later. “More” both in number and in variety.

Read More »

Well, a couple of hours in learning some DHTML and messing about has got me this, an interactive verion of the permission lists I’ve been making here in the blog. It may not work on all browsers… I’ve only tested on the latest Firefox (PC and Mac) so far.

I’ll be adding more funtionality to it as I think of it. It would be totally cool to have a complete simulation running! 🙂

Next: Advance on My Allowance

Let me try another example here, this time in a future world of Second Life. I’ll use the example from two entries back as the base.

I have a plot of land. I parcel it up in chunks and do a bit of decorating and I end up with this:

I want to rent the two lots out and perhaps make a bit of money. I make a group called “Tiger Tenants” to keep the operation organized.

Now in the Olde Seconde Life, I’d put the land under the group’s control and invite people into the group when they rent a lot. They can then build on their lot, but they can also build anywhere else on my land, including the other lot. There is no limitation on the number of prims they can use, beyond the hard limit imposed by the size of the total land. Also, adding them to the group gives them other abilities unrelated to simple land rental, such as getting a portion of the dwell bonus for the whole area, among other things.

But, thankfully, I live in Nuevo Second Life, where groups work much better!

Read More »

I was originally thinking a group’s Roles would be arranged in a hierarchical format, each sub-Role inheriting default permissions from the one above it, with local changes. But it was the local changes that made it too complex.

What if, instead of granting further permissions, a sub-Role took some away. If being in multiple Roles wasn’t forbidden, then it wouldn’t be possible to tell whether a person could or couldn’t do something if they were in one Role that allowed it and one that didn’t.

By going flat, not only is the whole layout easier to see and manipulate (a list instead of a tree structure), but you can go with purely additive permissions, since you never have to take one away that was granted in a higher Role.

I thought I’d give an example of a flat group with members in multiple Roles, just to give a taste of how this would… Well, not look per se, but feel. Here it is, fully expanded. (Normally, each section would be closed until you twiddle it open.)

Read More »

(OR: How to Stand Out From a Barrel)

In my last entry, I used a lot of concepts that I might have mentioned in passing in one of my many forums posts, but never wrote down here in the blog in any detail. In fact, in the last entry I used a new term for something that I’ve given many names to over time. I can’t take credit for the final word choice, however. I first heard it from Linden lips in this week’s Groups/Covenants meetings.

The word is: ROLE

But what is it? If you read the last entry, you should have a good idea of the basics. (And if you haven’t, you probably should. I’ll wait.) But in short, a Role is a “special member” of a group. Well, not THAT special…

Right now, groups have only one special member type: the Officer. Everyone else is a Member. But needs change, and so will groups, so what follows is my take on Roles and how they will work…

Everyone in a group will now be a Member, forever and always, for so long as they are a part of that group. The Member list is everyone that has joined but not yet left the group, regardless of any Roles they may also take on. Roles are like job positions within the group.

When a new group is created, there is only one Role, which I’ll call “Founder”. I made the group, I’m in the Founder Role. I’m also in the Membership list. There’s always a Members list, and everyone in the group is always in it. And there is always a Founder Role, with at least one person in it.

For both these lists, there is a set of permissions. The permission set for the Founder(s) can not be changed. Founders have full permissions over everything in the group. Unless you truely trust someone, or are passing on the reigns, I’d suggest NOT putting anyone else in the Founder Role. You can remove yourself from the Founder Role only if someone else is in there. To do otherwise would be to disban the group.

If I invite someone to the group without specifying a Role in the invite, they just become basic Members when they join. (Though I can always add them to a Role later, as could anyone else that has the permission to do so.) If I do invite them to a Role, then they are part of the Member list AND the Role the moment they join.

The Members list, except for that fact that everyone in the group is in it, is otherwise just like a Role. It has a name, a description, a title, and a set of permissions as to what all members can do, just like a Role. The general idea is that this is the most restrictive class of permissions in the group. Any permission granted by a Role will override a lack of permission in the Members list. Meaning, if the Members can’t talk in the group IM window, but one of Bob’s Roles can, then Bob can talk in the IM window.

A player can be part of as many Roles as there are in the group. A player’s sum permissions are all the “Can”s from all their Rolls combined. Being removed from a Role will withdraw any granted permissions unique to that Role. When selecting a title to go over your avatar’s head, you pick from both Groups AND Roles. (Hmmm… It may be easier on the system if your current permissions were JUST of your active Role instead of a sum of all your Rolls in alll your Groups. It would be more confusing, though. Anyway, it’s just a thought.)

A Role can be empty, have just one member, or have many. Every member of the group could have his or her own private Role, though I’d hate to have to manage something like that for a large group. More often than not, a group will have just a few rolls, or even just the two you start with… If you are just making a book club.

Now that I’ve gone over Roles here, you might want to go re-read the last two paragraphs of the previous entry and see how the examples there feel, knowing what you now know about this system. Hopefully, it will feel simple and elegant. 🙂

Next: Stay Flat or Go Hier?

No, I’m not talking about an autopsy of a coiffure. I’m asking “What is permission?”

At its heart, a permission is all about “Can” and “Can’t”. But you need more than that… You need a who and a what around them to start with. “Bob Can Edit” for example.

Next, you need a frame to contain the permission, or else Bob will be editing everything: “Bob Can Edit the Group”

And lastly, you need the permission giver. This is an important one, and needs to be strongly defined. Bob saying Mary can have access to Tom’s bank account should be about as effective as me saying it should rain gold dubloons. The frame of the permission has to be the same as the giver of the permission.

So only “the Group” can say that “Bob Can Edit the Group”.
Or… The Group says: “Bob Can Edit Me”

Now, from Linden comments (and common sense) it would seem like groups will, eventually (perhaps in stages), not be able to own things. [Why? See my earlier entries.] Land for start, at least. So then we have a problem… How can a group say who can and can’t edit land if the group doesn’t own the land. “Bob Can Edit Tom’s Land” just won’t fly. The giver and the frame are different.

The old way would be to just give the land to the group:

But that meant giving up control of it completely. Instead, the owner needs to stay the owner and just share with the group:

Now the owner remains the owner and can control how much permission to give. This could end here if the group was a single person, but a group is many people, spread across many possible rolls (not just the two we have now, Officer and Member). We will need to be more specific than that:

I don’t trust groups. Have I mentioned that?
[ this is an exaggeration, not my driving purpose ]

I’ve been burned. I’ve heard plenty of accounts of other people being burned too, friends and strangers alike.

It’s just not safe to be in [some] groups when there is no accountability among the members. People can’t be held accountable for their actions in a system that has no (or at least few, we have the ToS) laws.

Well, if you don’t have accountability, the next best thing is trust. But while trust works for small groups, where you know and respect all the members personally, it’s useless for large groups where the member list is longer than you friends list by more than 2 to 1.

Looking to the real world for answers, governments stand out as facing much the same problems. They solve both issues (as best they can). But the solutions found there for accountability are far too complex to try and implement in miniature… You rarely see multi-branch leadership systems in anything smaller, like the local school board, for example. But for trust, there IS a scalable solution: Voting.

Ah! Maybe we’ve found the solution to the problem. We could let groups vote people into office… But that would require defining terms of office and such. And besides, most groups don’t want or need that. When forming a company, the future employees don’t vote to see who will be the CEO. It’s messy. Besides, we’re just looking for something to improve trust.

So… If trust in an officer wanes, allow the membership to vote them out. Simple to set up, easy to execute. I think we have a winner!

Oh, wait… But if a corrupt officer sees the membership is trying to vote him out, he might take the money and run. Okay, solution: Freeze the group assets once the vote is proposed and keep them frozen until it ends.

And so ends my imaginings of how Linden Lab’s early group voting design was formed.

Of course, we all know what happened after that. Bad eggs in a group found they could paralyze all group activity just by starting a vote. It didn’t matter what the results of the vote were, the mere act of starting it did enough damage.

So that feature, eventually, got disabled. And now we’re back to the original problem of Trust and Accountability.

Is there a new solution? I don’t see one on the horizon. Corrupt group leadership could happen in any group where some members have the ability to control assets of other members. And without that ability, groups would be rather pointless. If everyone can only control their own assets, then what’s the point of forming a group.

(Of course, there are groups that don’t involve such inter-member controls… In fact, ALL of the groups I belong to fall into that category! Why? Because I’m slow to trust. Oh, I may trust the current officers of a group, but things can change, and I can be a bit paranoid sometimes. Until something changes, I prefer to play it safe and have fun without worry.)

Tyranny works. At least it does in a realm where you can easily step away from a BAD tyrant. I’d take a good tyrant over a complex democracy any day… At least when I CAN take one step and be rid of the tyrant (by removing myself) should it ever go “bad” on me.

But right now, with the mixed up ownership issues groups have (see my earlier entry), a mere Member can’t take their ball and go home if things go sour. Objects given to the group can NEVER be reclaimed. And land given can only be removed by an Officer. Only with land allocation credits can a mere Member keep control enough that trust never becomes a big issue. And that just isn’t good enough.

“What’s mine is mine, even if I agree to share” is a common attitude when it comes to working in groups. Of course, taking that concept as the rule opens groups to even MORE issues of trust. If Mr. “mere Member” takes his ball and goes home (maybe because you are screwing the poor thing over in some way) and that’s the only ball, then the whole group is hurt. “What’s mine is mine” means trusting every Member that contributes something vital to the group, and not just the Officers. And it’s not just trusting that the ball owner doesn’t go home, but also trusting that no one in the group will force him to go home in some way.

Layers and layers of trust. Is it no wonder that some little majority vote system failed to bring harmony?

So what do we do? For every solution I can think of, I can think of cases where it won’t work. For every combination of solutions, I can still think of cases where they won’t work.

But. But… But! …But for every case, I can think of a solution! (Or someone can.)

That may be the ticket. The only ticket that can truly be said to WORK. Find solutions as they are needed for each case. More work? Maybe, but we have more people to do it. 20% growth per month, remember? Plus, a solution for one case might work for many others. People can share their solutions.

But how will people make these solutions? Good question. They will need tools. Good tools. Powerful tools. Tools that let them build, from the ground up, exactly the solution tailored to their problem. They don’t have to start from scratch… An almost perfect solution someone else found can be made perfect with some modifications. Re-inventing the wheel wouldn’t be necessary in the vast majority of cases.

So what are these tools of which I speak? I’m not entirely sure, but I have a vision of a shiny red toolbox… I’ll open my vision and share it with you. (But only if you come back and read it, of course.)

Next: Anatomy of a Perm

A short break from my thoughts and ideas to take a gander at some of Linden Lab’s. Earlier this evening, I was able to take part in a small discussion group about… groups. It’s funny that I had to join a group to attend the group about groups. In fact, since I was at my limit of groups (a limit that is technical, it was mentioned this evening), I had to drop a group to join the group to attend the group… about groups.

Groups on the brain.

Before going to the discussion, I was wondering whether Linden Lab had a blank slate and was looking for any and all input, or if they had a general idea of where they were going next only, OR if they knew exactly what they were going to do and just wanted to get our reactions.

Showing up a bit late (about 8 minutes), what I first heard upon rez made it feel like it was the third possibility. But after getting TWO notecards with logs of the parts I missed (thanks!), I saw that it was the second case. They know where they want to go, and they’re working on the first steps to take them there.

One of the topics was Covenants. (Think homeowners’ associations, for those unfortunates, like me, that are saddled with the damn things.) This is something that really only concerns the Estates, or island regions. This confused most of the attendees, even me at first. It seemed like it was just a document stating the rules and regs the Estate owner wished to uphold. Sounded like your typical notecard-giver would do the job just fine. But then, from Daniel’s comments, I saw where they were going with it.

Eventually, much to a number of people’s joy, Linden Lab does want to let us host our own grid servers. Oh… Nowhere in the near future, nor even in the nearish-far future, but eventually. Giving the Estate owners more autonomy is a step in that direction. When they can make the local rules — their own ToS, if you will — then we’re a little closer to the day when people can run their own continent from home. (Hope you have a lot of bandwidth by then!)

Now, this was all mainly for the Estates, not the mainland. But it makes sense if you think of the mainland as the estate run by Linden Lab. They run the “hippy-San-Francisco-Utopia” we all know and love, but they want to leave the Estates open to be anything else we can imagine. I’m encouraged by that mindset.

But even the mainland can possibly benefit from such ideas in the form of zoning and collective projects that go beyond share-and-share-alike. There’s room for new ideas everywhere.

But all that, we were told, is still in the future. What we can expect to see soon will be updates to the interface of our current group system, AND one new feature that remedies one of the many flaws I mentioned in my previous entry here. That of locking permissions — what a particular group participant can and can’t do — to the two levels of current group design: the Officer and the Member. So just two, and no more… For now.

From what was said, I gather that (at least at the time of creating the group, or maybe later as well) the permissions of each sub-group can be customized from a list of options. The interface has yet to be finalized, but one can imagine a list of checkboxes for each sub-group that can be clicked on or off to limit or empower. Ability to edit group land or objects, manipulate group money, invite people to the group, initiate a vote… All candidates for such options.

Could it be? Granular permissions! Albeit only for group-related actions, but granular nonetheless. Could this be a sign of things to come? Granular permissions across the board?

One can hope.

But still, this change remains of a top-down design. It answers the question “What sort of groups will people want to make?” instead of the more fundamental question “What are the basic building blocks of social interaction in Second Life?”

I’m more interested in answering the second one…

Next: Voting, Trust, and Accountability… Oh My!

Groups in Second Life are social organizational structures. So what makes a group a group?

• Meta-Data — Information about the group itself, such as its name
• Organization — Currently just a two-tier system of Officers and Members
• Permissions — Who can do what?
• Communication — Movement of data (even objects) among group members
• Ownership — The group itself can own objects, land, and money

Meta-data is split between what is determined at the time of creation of the group, and data that is descriptive of the group and can be changed at a later time: mission statements, member titles, status on public registers, etc. There will always be a need for this meta-data, as well as a means to control who can change it.

The organization options for current groups are few, offering only the two-tier system of Officer and Member, and a one-tier system if only the Officer tier is used. A military system of many ranks would be impossible, as would a government system with multiple branches. There needs to be any number of sub-divisions to a group, in whatever inter-relationship that the group requires.

Permissions are set solely on the status of being either an Officer (full permissions) or a Member (few permissions). Beyond that, permissions are set by the objects and land that are associated with or owned by the group. There is no fine-tuning of who can do what beyond clumping people into one of the two categories. Without that ability, even having more sub-divisions in a group would be limited by the permissions built into them unless groups came with the ability to edit permissions on a detailed scale.

Group communication is fairly primitive at this time. A message can only be sent live to all group members (regardless of which sub-division they are part of) when they are online. The only way to send a message to all members is to create a vote event, the outcome of which no one cares about. I’ve even seen Lindens use this hack, a sure sign that there is a need for better communications in groups.

Ownership. This is a true tar pit of (dis)functionality right now. By being able to own objects, money, land, and the abstract of land allocation credit, groups take on the mantle of playership. They become a semi-living entity to the system, but without any one person in control. Allocation, once given to a group, can be taken back at any time by the member that gave it. Land, however, becomes the property of the group and only the Officers can sell or give it away. Groups can own money, but only till the end of the day at which point it is distributed evenly to every Officer and Member — a distribution that can not be changed or prevented. And objects, once given to a group, can never be un-given. Not one type of ownership is like any other. Horribly confusing and inflexible.

So that’s the way things stand. It’s no wonder that Linden Lab is looking for suggestions as to how to clean this mess up and make groups into a tool for creating engaging social organization. Linden Lab took a shot at imagining the needs of future residents when groups were designed, but fell short. But that’s not surprising to me. Even with a larger pool of minds assembling lists of possible refinements and extensions to groups, some needs, and it may even be safe to say most, will still not be met in the end.

You can’t plan for every possible case, so what is there to do? …I have some ideas.

Next: Groups on the Brain

Let there be Blog.

I’ve thought about making a Second Life (SL) blog for some time now. A place to put my thoughts where I can find them later without digging through the forums.

The latest request for feedback on Groups changes in SL by the Linden Lab staffers led me to post what turned out to be a thread almost entirely written by me. But a forum thread isn’t the best place for a still-changing idea. Editing forum postings is possible, but can get confusing if done too much. So it was time to offline it to somewhere I have more control.

Now a blog isn’t much better for making changes, but this will be a one-two punch of blog (for stream of consciousness) and web page (for “current” version display). We’ll see how it goes. (And if I keep it up…)

Next: What’s in a Group?