Group control via script, perfectly feasible?

Hey there. A while ago Kelly Linden posted in regards to group invites being handled by functions such as:
llInviteToGroup(key id, string role); (role being optionally left blank for default role)
llEjectFromGroup(key id);

She posted:

Link to post

However, I would like to point out that these technical issues are actually not an issue. The invite system is in fact already in place!
Currently, a user can quite happily invite any user they feel into a group. This must at some point be registered with a central groups server/database, either handled by a dedicated machine, or by the simulator the user is in at the time.

This actually makes it very simple for an object to add someone to a group!

Say I create an object, set it to the Renara.com Store group, and put a script inside that simply adds any user that touches it into the group. The first hurdle (of the script knowing a user's groups) is overcome because it can only add users to the group it is a part of. This is perfectly sufficient for 99% of scripter's needs that would want these functions!
So, it knows the group to add the user to, but it doesn't know my role and thus permissions. That isn't a problem either.
All the script simply has to do is issue the request on my behalf, exactly as though I had made the request myself using the group window! Taking a user's key, and the role to give them (if not the default one) the script can send away its request as though it were me, if I am allowed to do this, then it will succeed, or otherwise fail. Either handing back a TRUE/FALSE value right away, or in a dataserver() event (this is the case for both functions). If a user is already in the group, but their role is not the specified one then it will change, if they are in the group and already have the specified role, the action will still count as successful if I could have added them had they been vacant from the group.

The issue then is simply whether or not it is the simulator that does this, in which case the process of sending the request is perhaps a little more involved since the sim would need to request all required data first to perform the action. If it is done centrally it is easy, as all that needs to be done is to send exactly the same query a user would.

My only other thought is security, easily overcome by requiring an object/script to have PERMISSION_MODERATE_GROUP set, thus acknowledging that the user has okayed the object to add or remove users with the same permissions as they have.
Also in regards to group-owned objects, either the request could be on the behalf of the original owner (if such info is kept) or it is simply not possible for group-owned objects to use these functions.

I don't know if a Linden wants to comment on whether this idea is thus entirely feasible, it is already in feature suggestions several times. But I felt that since a Linden had said that it was technically infeasible/difficult that I would be better posting my thoughts why this was not the case here to get answers more directly from those that now for sure

I don't know if this is possible, but if you'd like to be able to give people a direct link to join your store group, maybe LL could give us the ability to put links to group signup pages in notecards?

Just a thought.

But you do, the simulator must know at the time that the user can/cannot invite other users. All that is needed is for the simulator to have that info as though the avatar were there, but without anything else; ALL it needs is the invite flag for the object's owner. No group info, no other roles information etc. etc.
Even the optional role variable as I mentioned isn't needed to be checked until the user is added as you say. If it is an invalid role name then it would just add them as default anyway.


For load, I expect this function in most cases wouldn't add much to load at all. I mean, it allows land/room renters to add people to a rental group automatically, this would be done anyway, but instead would now be done instantly. It would reduce load in the case of rental groups that are left open (defeating the purpose to be honest) and anyone can join, as only the people who are renting (and maybe people sharing) need to be allowed access by the script. Thus the group can be closed instead, reducing the number of people signing up to it for no reason, or specifically to place objects on the land without any moderation.
For invite spamming, the invite must be somewhere surely that it can be checked for? Aren duplicate invites just be deleted? What happens if I manually invite someone over and over? If it spams them then this would be correct behaviour in a sense, not desirable, but not the fault of object invites really?

Caching then I'm not sure is a huge issue, as the only info you need is whether or not the object owner has permission to invite a user. So long as this is a queryable field it is a tiny database request to make, opposed to a full group info request for a user to do it manually. Just fetch it before the invite is sent.
I'm assuming it'd be find user in group, join with info for their role, return invite flag.

The usual throttling systems would surely work anyway, either a delay. A progressive delay being better, perhaps based on success rate. ie if the object makes an attempt that fails then it is delayed 10 seconds, if it makes a second attempt that fails it is delayed 15 seconds, next 25 seconds and so-on, getting bigger and bigger, or after a while is simply ignored until the frequency of attempts goes down.

The reason I'm pushing for this is that I am an apartments manager, and it's a bit of a pain really, I can't be online all the time, so new tenants aren't added to the group quickly, so I currently have the land with auto-return off, which means I have to police it manually all the time, and we often get quite a lot of rubbish left on our land.
Apartments are also one of the best ways I see to help offset the cost of simulator (if I do decide to go ahead with one, downtime and bugs are still putting me off), and scripted control would be perfect.

I'm not sure what you mean? The main use really is for people to be able to join the group if they need to (ie they are part of my store vendors so need to be able to set to this group or their vendor will be returned), I don't want anyone to join the group as this would defeat the purpose of it. Anyone could just sign-up and leave their vendors on my land without permission, but if the group were closed, and a script could do it for me then it would be better as it can do checks first (e.g a password).
More specifically renting is the best example, you set-up your apartments to a group, then switch on auto-return for non-group owned items. If you have the group with open-enrollment then anyone can join it and drop stuff on the land anyway, or worse remove things from the land! I would likely have a different group for each plot, and if you get added you have return/freeze/ban rights on that land so can police your own room. But open-enrollment would kill that as anyone could join and return the actual tenant's stuff.
The alternative is a closed group, which requires someone to be online when the person joins, or they will lose a day (or more) of their rent time waiting to be invited to the group so they can place their stuff.

Oh, I see what you mean. You want to invite people into a closed group.

Is there a way to HIDE groups? You could make an invisible group and then put a link to it in a non-transfer notecard that you give to people upon signing up. Just a thought.

This, of course, would rely on the lindens providing us a way to put a link to a group's join page on a notecard.

Sorry if I'm a retard about any of this, my experience with serious group management has never gone further than making one for me to join where I could make my own custom titles.

No-no, I like that you're suggesting alternatives, there's always a chance I missed something too
There is an option to hide a group from the groups list (ie in-world search), but it would still be visible in user profiles and the about land pane. Same with the web-option, to make the link work you'd have to have the listing on the web-site.
An alternative feature suggestion could maybe do it though, maybe a join with password option? The script can give the password/code when you've paid and that allows you to join? Change it now and then to prevent it being handed out. That would still be an improvement I think, as once a room closes it could remain in a 'cleaning' period till the group is cleared and the password updated with a new one. In that way the delay for human invervention is AFTER the rental rather than before it which is my main issue.

Hmm, would be easier to implement I suppose, since it'd be part of the join option rather than invite.

Yeah. That sounds like a good idea with the password option. I think we're on to something, whether or not lindenlabs will implement it is an entirely different story, though.

I really think you should listen to Kelly about the other points, though. The logistics of making it work ARE very tough and would add a lot of strain to the servers.

Caching data that is likely to change like that wouldn't be a good idea, what I was saying in my post is that that bit is all you need to query when an object attempts to make an invitiation. But not from the object itself, from the database server.

ie:
Bob's object tries to invite Jane to his group
The simulator it is in asks for bob's invite status in that group
Simulator receives TRUE (all the info it needs) and sends off the invite to Jane

I mean, in theory we're talking a simple SQL SELECT on a boolean in the database, a massive database I expect, but with indexing it shouldn't be a massive load. Much less than fetching all info would be.

It could probably be cached for short periods, but it's only a single bit of information to fetch from the database, so wouldn't seem to be imperative that it be cached every time. An alternative is to cache it for X attempts or Y time (whichever is shorter), so every five requests would be re-checked.
But the progressive success based delay seems a better alternative to caching; if the invite succeeds (ie Bob had permission to do it), the function is throttled for a short delay (or the function sleeps). If it fails however, then the delay rapidly increases for all objects on that simulator, possibly flagging up for Linden attention or just becoming outright disabled (ie each script that keeps trying simply pauses execution like unchecking "Is running".

However, you said that group permissions follow a user around a simulator, how does this get updated if your permissions change?
e.g, Bob has had his invite ability removed, if he tries to invite someone will he know this and be unable to see the invite option, or will it send the invite off anyway and fail at the database server? Is this what you mean by presence info being required, a server tracking who is where so they can be updated?

I think the point is that it's reasonable for LL to track some information associated with an avatar because there are relatively few avatars, and they already have a lot of state associated with them. Letting objects do anything avatars can do potentially makes any object as expensive on a sim as an avatar.

Sim prim limits of 40 would get real old real fast.

So you have to strike a balance, and decide what potentially expensive things you're going to allow objects to do. Is this something that's likely to cause a lot of load or not?

One possibility... allow this, but only on group-owned land, and have the information cached in the parcel?

I'm not sure that's really very likely, as the only things I see an object usefully being able to do would be group related. That would either involve fetching info (ie llIsInGroup(key id)) or inviting/ejecting/changing-roles within the group.


I like that idea, but I think really it would only lower the problem with the caching rather than removing it?
Another alternative, in my original post I said group-owned objects wouldn't be able to do this, what if instead, ONLY group objects could do this? Furthermore, only group objects that are deeded by the owner of the group may do this, anyone else (even if they have invite status) will result in a deeded object that fails to send requests (ie the 'send invites' bit is not set to TRUE upon deeding it). I can't remember if group owners can be changed/removed from the group or whatever, I don't think they can which is why this idea would work in that case. If group owners CAN be changed or ejected then it might not work so well =)
If it is as I think, then the owner's status is not going to change unless the group is deleted, so it wouldn't need to be checked, or cached, or anything, just sent.

In this way, if Bob deeds an object to invite spam, it will fail. But if Sally deeded the object it would work just fine. An additional to that is that the object being deeded maybe shouldn't be modifiable except to the group owner as well? Otherwise someone could still change the script to make it a spam machine of doom.

Group owners CAN designate other Group Owners, and a Group owner CAN leave the group if --and only if-- the Group has another owner. Still, this happens rarely enough that it should not be much of an issue.

Perhaps each Resident could also have an optional pointer into a database of objects that need to be notified when appropriate changes are made to his/her group status? This pointer would be NULL when there are no such objects, and point to a list of entries in a seperate database when there are.

Perhaps a flag for llGetPermissions that must be asked for EVERY time an object wishes to perform group actions? Perhaps the relavent information can be requested via the DataServer system?

Hmm, but that would defeat the purpose of automating it with scripts if you needed to manually say yes every time

I suppose one of the additional's (and a feature which could be really useful anyway) is for members to have a field stating who (or what) invited them into the group. Then make it owner deedable only as I said. That way, if the owner does change, and an object is inviting people that the new owner does not want, then they can delete it using this new field which would say either "Invited by Haravikk Mistral" or "Invited by group invitation box, Koss (62, 73, 192)"

There's an old saying in computer software development... "an extra few kilobytes never hurt anyone... unfortunately, all the other developers think the same".

[Edit: when I first heard it, it was 'a few extra bytes', and it may be 'a few extra megabytes' now ]

It's not that this function would be an exceptional problem, it's that there's hundreds of cases like this that are each only a small change, but when they're all implemented they end up with objects having as many special cases for things they might need to track as avatars.
It would lower the problem from the sim having to be able to do this for any object, and thus having to perform another test for a special case on every object, to having to do this for any parcel. That moves the test code from a critical path in 15,000 objects per sim, to a few hundred (worst case) parcels per sim. That's not as good as a few dozen (worst case) avatars per sim but it's not insane.

That still means at least an extra pointer in every object in the sim... and they are already doing things like re-using bytes in objects to cut down on the load.

My error. The script would be required to ask permission every time, but it would be autogranted if the owner has the requisite authority, and autorefused if the author lacks it. [Essentially, this would be a dataserver event masquerading as a permissions event.] Thus, the script could announce "I need this information; fetch it." and the needed information would become available when needed.The actual invite would go through if the owner of the object had the authority when the permission was requested, even if the authority vanished before the invite itself went out. However, the permission would expire at first use or at N seconds, whichever came first.

Or perhaps it could just expire after N seconds, instead?

But not really any more than we'd be expecting from this idea anyway, plus zero additional load beyond the invite requests themselves (which, if I'm understanding it correctly, are done by the sim rather than a central server, that is until the invite is accepted) and no need for caching.
So beyond the single extra bit, the additional requirements are basically nothing. And even then it needn't be on a per-object basis, as this permission isn't going to affect all objects anyway, so could be tracked with a little list of object keys the simulator can shove to one side until needed. ie, this wouldn't work for group owned objects that are flying around, it would be for a static object in a simulator, de-rez it and it needs permission again.

I guess I didn't make it clear... it is more data, and it's more data in a part of the system that's already under strain.

Maintaining this in the object would mean that every object in the sim would have to have an additional chunk of data associated with it... even if it's completely unscripted, let alone whether it uses the group functions in question or not. This would be at the minimum one or two pointers added to the size of every object in-sim... and the size of objects is something that LL is struggling with. LL has already deferred features and reduced the resolution of objects to avoid making objects more complex.

Having this be associated with a parcel would mean that (a) less additional data would need to be tracked, since a lot of the necessary data is in the parcel already, and (b) it wouldn't add anything at all to the size of an object.
And that list of keys can be shoved off into the parcel that, because it's owned by the group, is already tracking them!

This wouldn't involve a different API, it would simply require that the invitation be made from an object on a group-owned parcel... which is where the fellow who wants access to the parcel already happens to be.

It was perfectly clear, which is why I said it only needed to be stored for the objects that needed it. All I was saying that for a group invites system you'd be expecting some permission somewhere, meaning an extra flag, not unexpected. Not the best solution, but not unexpected =S

In a parcel is a possibility, but if you're going to have a list of keys saying "These objects have permission to send invites for their group" then saving it in the parcel isn't necessary really, as the list will function just as well as a global thing for that simulator? Gives one advantage that you don't have to have the land be group owned, only group accessible*

With the clause that the object must be deeded to its group by the owner of the group at the time it ought to be a workable system, wherever the keys list is stored.

*(this is handy for managing rental land too since the room/building can be owned by me as the land owner. And anything the user places will either be auto-returned, or set to group, if the latter, when their rent expires I just click to return all group items =)

The list of keys, *yes*. The pointer to the list still has to exist for every object, if it's gotta be tracked on an object basis, or the sim has to check that list every time an object is deleted, created, leaves or enters the sim, to see if it needs to be updated in that list.
You don't, any more than you need a list of keys saying "these objects have permission to push" for each object in a parcel with "push" permission. The simulator checks against the *parcel*, not the *object*.

But you're talking about making the permission apply to all deeded or group owned objects on the group's parcel? That wouldn't solve the problem, as anyone with deed permission could create an object to spam group invites, revoking their deeded status wouldn't stop their object. And any group deeded object with a script could then be the one spamming, rather than just the ones the owner set.
Worse, with this method, the invites would all be valid ones, rather than them being invalid invites. At least invalid ones wouldn't result in loads of people joining the group that you don't want in it.

Besides, the list of keys/pointers to objects capable of sending invites needn't be checked every time an object is deleted, only periodically, or if it is getting larger than expected (I mean, realistically you'd only expect a handful of objects at most). Since any deleted object would no longer be able to send invites anyway.
And it doesn't need to be checked at object creation at all, only when that object is deeded to the group by the group owner.

And it's different from the push setting I think, as push is saying "You can or cannot be pushed while on this parcel", a group-object setting says "Objects on this parcel can invite you into this parcel's group regardless of where you are", it's very much a global thing opposed to local. Plus it (potentially) involves a dataserver event for every single invite that is sent, which push, and other simulator level settings do not.

Maybe I'm still misunderstanding, but it seems to have all the same problems anyway?

No, only to object owned by people in a role that had the appropriate rights.

This would not require tracking any additional information in the object. The call would check against the parcel rather than the object to see if it should be permitted, just as existing calls like llPushObject() do. The parcel would need to track what members have the right to make the call, but the parcel is already tracking a lot of inofmration about members anyway.

[/quote]And it doesn't need to be checked at object creation at all, only when that object is deeded to the group by the group owner.[/quote]That would be significantly less versatile than my proposal. You couldn't delegate the right to send invitations from scripts at all!

That's a test that would be performed after the permissions check is made. If the check fails, the dataserver is of course not going to be involved.

I mean, llPushObject potentially involves the dataserver, because it *might* be applied against an object to push it off the grid.

From what Kelly has explained so far about the system, a parcel doesn't track any info about members. Kelly's explaination seems to suggest that when a user logs in, all info about their groups and group statuses is sent to the simulator they are in, as they move around, their group info moves around with them so that simulators can make group-related decisions regarding that avatar. Since avatar presence is stored anyway, any changes to group can be sent directly to the simulator that avatar is in.
The parcel doesn't track anything about member statuses unless I'm missing a quote somewhere. So the problem of verifying the object would still exist, as the parcel would either need to constantly keep updating its information, or be registered somewhere centrally so that it can remain up-to-date on someone's status. Otherwise as Kelly says, once the invite status is revoked, the object could keep sending invites which would then fail if accepted. Any caching would make the problem of false invites worse, while no caching would greatly increase load as permissions would need to be checked by the groups server BEFORE the invites are sent.


My system would work as follows:
1. Set-up object "Inviter", script contains calls to llGroupInvite and llGroupEject (or whatever they'd be called).
2. Object is placed somewhere.
3. Group-owner then goes to the object and deeds it to the group.
4. It can now make group invitations.

Alternative 3. Script applies for permission from the simulator to make group invitations. This is done the first time it tries to invite someone. If the object is owned by the group's owner then it may do so, otherwise it fails. This may be better as this way all you have to do is find objects owned by the previous group owner and remove them.

Therefore, no checking needs to be done during object creation, as only verified objects can have permission, and they are verified either by deeding, or by trying to send an invitation to begin with. Thus, only checks needs to be done when deeding or when a first invitation is sent.

The thought process on this is that the group owner will be more responsible in who is invited to their group, as spamming invites to everyone that walks past could result in the whole group being removed when they get banned.
Similarly, group ownership changes are extremely rare compared to people's roles changing. So invite status can be retrieved once and assumed from then on. It could be re-checked periodically to be sure, but high frequency should not be a requirement here, as the number of ex-owners causing abuse should be almost none as they do it voluntarily, whereas someone demoted from officer is more likely to throw a wobbler.
In this way we overcome the need for permissions checks externally all the time, as only one is made.
We also mostly remove the issue of failed invites, as the only time this will happen is if the group-owner changes. If this happens, then the invite will fail, since the object doing the inviting will be doing so on the behalf of the old group owner (unless they still have invite powers in which case it may as well carry on). If it was done on the behalf of someone who is not (or rather no-longer) the group owner, and the invite is flagged as being from an object, then it will fail, and the simulator sending it will be informed the object is no longer valid. The result here is one failed invite should the group owner happen to change.


Yeah, but the simulator is able to handle first whether it contacts the other server, while if it needs to fetch permissions it can't

Did that last post clarify for anyone? I get the feeling I probably didn't explain very well to begin with, mainly due to how I write everything I'm thinking in no particular order. Well not everything, or you'd get biscuit cravings inter-mingled, at which point it would be IMPOSSIBLE to understand

Can you get a dataserver query that would ask (given a group ID, such as the llGetOwner() of a group owned prim) what the name of the group is and the leader/owner of the group?