Idea: Adopt a UNIX style permission system.

This involves groups because I think groups and permissions MUST be overhauled at the same time.

This would effective create all kinds of major pluses for SL.

My head is too tired to write up a proposal right now, but I will start on one. Basically, we'd adopt a permission system similar to UNIX/Linux, where there are several switches per item, and each switch can have several flags. Owner, group, public, etc...

You can do amazing things w/ the UNIX permission system, and it should be looked at as a possibility.

We'd of course modify it, to be like "Creator / Owner / Next Owner / Public" or something like that. The original creator of an item would then decide what those permissions would be for the life of the object, unchangeable by anyone unless they are granted the modify rights flag.

Also, the ability for a creator to completely hand over all rights needs to be there, so they can do just that.

Please delete this message.

Given the interpersonal and philosophic ties between LL and the folks at Creative Commons perhaps some CC flags should be added so long as the permissions are being overhauled.

And even though I far prefer the simplicity of Unix style permissions, Access Control Lists should probably be used when a few tidy bits are not expressive enough for the control you desire (but should be hidden under an "Advanced..." or something).

<-- <3 ACLs

It makes sense to integrate group tools with permissions, because so many of the functions the average group wants fall into the categories of control over prims and control over land. Integrating the design of improved permissions and improved group tools would be helpful for newer residents. An integrated toolset would be easier to learn and understand.

Permissions in Unix are almost completely disjoint from each other, which makes their semantics very simple and allows them to be evaluated in any order or in parallel, and of course stored extremely compactly as well. By the same token though, this means that you can't really extend the implied semantics within a short vector wthout destroying those good properties.

Object permissions in SL seem to be a lot more complex than a system of (owner-group-anyone) * (read-write-execute) or around 9 disjoint yes/no bits would allow, but there is of course no reason why we need to limit ourselves to so few. Just add more.

My take on this is that the disjointness property is *EXTREMELY* important here. If every single bit controls only one property of an object, and thus if the combined permissions on an objects are merely the direct sum of the individual permission bits then it is allways possible to understand what is going on easily, and to fix any problems quite mechanically.

In contrast, if extra semantics suddenly appear when permission bits are combined (separate from the individual meaning of each permission bit) then you get a combinatorial explosion of possibilities, and you're on the road to disaster. The implementation bugs will never end, and surprising unexpected behaviour will creep out and bite us regularly.

So, I'm all for using the very clear Unix-style permissions-vector approach, but really must stress that disjointness is a key property of the bits in the vector, and you ignore that at your peril!

Well currently the permissions only have 3 options:
- Modify
- Copy
- Resell/Give-away

These could be done quite happily with an EXACT unix style. The change of course would be that the "Resell/Give-away" option would no longer rely on Copy permission, which IMO is what it should do anyway, plus it should really be broken up into "Resell" and "Give-away", so free objects can remain free!

Some extra ones that could of course be incorported (as they are permissions too):
- Take copy
- Take original
- Move

The way you have total permissions for:
- Modify
- Copy
- Transfer
- Resell
- Take-Copy
- Take-Orig
- Move
- Unused

So 8 bits per permission, with an unused one for later additions or whatever.
These would be available for:

- Creator (allows the creator to repair items that they made without taking them back)
- Owner
- Next Owner
- Group
- Public

See what I mean?

The more you think about it, the more complexity you find in the actual semantics of object rights and ownership in SL. Indeed, it's been the subject of huge threads in these forums over the years. And of course, people want ever more complex behaviours, the requests have never stopped coming.

Which is why I believe that LL needs to *totally* factorize out the very complex useful-but-composite semantics into unique primary behaviours controlled by single disjoint bits in the permissions vector. "Normal" object behaviour will then be a default composite pattern of primary behaviours, just like 0644 is typically the default pattern for data files in Unix. What? Setting 4 bits just to get default behaviour? Surely that can't be right ... but history has shown that it was the right choice.

Decouple the semantics into completely disjoint primary behaviours, each controlled by one bit, and the world is simplified immensely.