[sldev] Suggestion to improve moderation capabilities: auto-mute banned avatars

[Kamilion]

On 9/13/07, Erik Anderson <odysseus654 at gmail.com> wrote:
>
> On 9/13/07, Dale Glass <dale at daleglass.net> wrote:
> > > However, the mute should also be automatically removed either after X
> > > hours or when leaving the parcel or simulator. Any automated action
> > > should be undone after it's no longer needed.
> > It'll be automatically applied when you change parcel, and undone when
> > you leave it.
>
>  Just my couple cents, I would almost like to see this "parcel mute list"
> maintained separately from the user mute list.  That way we don't end up
> with problems like we do with touch() events in LSL.  What happens if a user
> redmaps or leaves the parcel in an uncontrolled fashion?  We don't exactly
> want to be fixing bugs here regarding failure to un-mess up their mute
> list...
>

If I'm second-guessing Dale correctly, I'm thinking that this is
mostly all clientside.
I'm guessing the mutelist would likely be in an array of some kind
that just gets thrown away when a parcel change on the client is
detected.

<snip>
> My suggestion to fix this: Automatically temporarily add to everybody's
> mute list the avatars banned from the parcel
</snip>

When someone is banned from a parcel, clients on that parcel mute the
banned resident, preventing griefers in the next parcel over from
bothering anyone on the parcel the ban was set on. When you leave that
parcel, the temporary mute list is dumped in favor of the new parcel's
banlist.

Boils down to: If you're banned on a parcel, everyone on that parcel
automagically mutes you, even if you're not on the parcel.

Muting of this type probably should not mute IMs specifically.

> In principle, part of this can be implemented quite easily by requesting
> the parcel's banlist each time a parcel border is crossed (could have a
> delay to save some performance impact and avoid unnecessary banlist
> fetches while flying around).

Sounds to me like we need something like a way to query the server for
a timestamp of when a parcel's banlist was last updated. This way, we
can cache the banlist for frequently visited parcels, and be notified
when the banlist has changed.

Last I poked around with CAPS, they accept the connection, sit there,
and basically either timeout or return data when something happens.

Sounds like a dead simple addition on LL's side of one or two caps:
deferred request for the return of the banlist modified-time-stamp,
and immediate request.

Reading some of the messages earlier this month about the public CAPS
urls, they seem to be able to take HTTP GET values:

https://cap.secondlife.com/cap/0/b713fe80-283b-4585-af4d-a3b7d9a32492?var=slRegionName&grid_x=997&grid_y=1002

So what we'd be looking at would be similar to:
https://cap.secondlife.com/cap/0/941ff5db-4586-4b40-b533-ba62648118e2?var=slParcelBanTimeStamp&sim_name=Luskwood&parcel_id=398472947&now=1
[NOTE: THIS DOES NOT REALLY EXIST, IT'S JUST A MOCKUP]

Hopefully this isn't too much to ask ;)


However, if I'm not mistaken, progress on the client in this area has
already been done:
http://ablewhitman.org/blog/
Able Whitman's been working on his Mute Visibility patches for a while.
Perhaps you should take a look at 'em and see if he's already
implemented some of the bits you need to pull this off.

Also, I'm sure OSLCC could benefit from Dale, Nick, and Able's patches.
https://sourceforge.net/projects/oslcc


Stamp out griefers: When they can't get their lulz from you anymore,
they'll get bored and go find someone else to bother.

Good Luck, Free Seg!