[Opensim-dev] A proposed groups architecture

[Kyle Hamilton]

That's "trying to create a complex mechanism to support a simple
idea."  Plus, there's absolutely no reason why chat should be routed
through remote regions (why should I open my communications to a
potentially-hostile region operator when I have no encryption between
group members and no key management?)

-1.

-Kyle H

On Wed, Jul 2, 2008 at 11:53 AM, Melanie <melanie at t-data.com> wrote:
> Hi,
>
> yes, that's the idea. Link the communication group to an ACL record.
>
> But, it can't be region scoped, IMHO, unless that is fully
> automated. We can't burden a region owner woth creating those
> mappings manually for each group someone happens to carry. But if it
> is automatic, then it could be region level...hmmmmm that makes
> eminent sense.
> Create an ACL record for the group only if any land/objects have
> that group set on them.
>
> That would be a quite limited list, suitable for region level
> storage. Looks like that could work.
>
> Melanie
>
>
> Frisby, Adam wrote:
>> Option #4: Seperate them.
>>
>> Use a permissions/ACL groups system on the sim which is separate from
>> the grid ones.
>>
>> Then use the grid ones as simple communication / interaction groups.
>>
>> There's two different tasks here as far as I can see - so cramming them
>> together to match what the viewer does may not be the optimal solution
>> (there's nothing stopping you from having the viewer action affect both
>> however)
>>
>>> -----Original Message-----
>>> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
>>> bounces at lists.berlios.de] On Behalf Of Melanie
>>> Sent: Wednesday, 2 July 2008 11:32 AM
>>> To: opensim-dev at lists.berlios.de
>>> Subject: [Opensim-dev] A proposed groups architecture
>>>
>>> Hello,
>>>
>>> in chat, an interesting question was raised, concerning the scoping
>>> of groups.
>>>
>>> It appears that groups really serve a dual purpose, as a
>>> communications platform and as a permissions system.
>>>
>>> In the role of permissions administration, groups are tied to land,
>>> which scopes them at grid level, most likely.
>>>
>>> In the other role, as comms medium, they are user-tied, you would
>>> want to take IM/Notices with you if you teleport intergrid.
>>>
>>> A few possible solutions come to mind, none is 100%:
>>>
>>> Scope groups at grid level: Allows consistent land
>>> ownerships/permissions, but group chat would be grid-local
>>>
>>> Scope groups at user level: You could take all your groups with you
>>> anywhere, but permissions become tricky.
>>>
>>> A combination, where the groups from your current grid and those
>>> from your userserver are merged and form the group list on the grid
>>> you are on.
>>>
>>> There may be options to scope all groups at user level, and let them
>>> own land anywhere, but that would put a certain amount of trust into
>>> a UUID that is not locally manager, and I would hesitate to do that.
>>>
>>> As I write this, another option comes to mind.
>>>
>>> If groups were scoped with the user, then each grid could create a
>>> record that maps that group (by name) to a local ID, which could
>>> then own land.
>>> This might yet give the option of implementing groups that can have
>>> both functions in one.
>>>
>>> Thought are appreciated.
>>>
>>> Melanie
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>