The purpose of this device is to establish a white list for communications within Second Life, and restore communication control back to the user.
It was created for a friend who was being relentlessly followed by a stalker. The stalker would send IMs while she was logged on and diminishing the joy of her SL existence. Banning the avatar did not deter them, as they simply violated the Second Life Terms of Service by creating dozens of alts. This pervert even created an alt and set the display name to the person he was stalking.
To combat this problem, the Anti-Stalker device works to create a whitelist on an avatar. It uses the RLV feature built into some of the Second Life clients like Phoenix to turn off communication except for those people allowed. Optionally, the user can turn local chat on/off as well as public IM chats. It’s not something that a stalker Avatar can control or prevent from happening since the client is altered to prevent unwanted communication.
The first question people will ask is, if I turn on RLV, can I be turned into a slave? The short answer is no. And even if you do find that one of your other devices are RLV enabled, you can you can turn off RLV in the viewer, restart the viewer and detach the item that causes you to lose control, then restart SL with RLV turned on to fix the problem.
To be controlled by RLV you need a relay device attached either on you HUD or on your body. What the relay device does is accept messages from a remote control that are then relayed to your viewer. While it’s possible something else you have is a relay device, it’s highly improbable. The probability of actually losing control is virtually zero.
If you are intentionally using a RLV relay device, I strongly recommend you let the dominate know you are using it and why because it may interfere with their control of you.
How it Works
The first stage is to identify your white list. These are the people you know and love and are on your friends list. You will need to identify all their UUIDs so that the system knows who they are. I recommend the use of Phoenix to get your friends list, as this viewer has a “Friends Export” feature. Simply take its output and load it into a notecard. Alternatively, you can painstakingly list all the avatar’s keys in a notecard and store it with the device. The system is smart and can pick up either format automatically.
Next you attach the device to your HUD. This is because the system uses text to identify the status:
IM is On
Local Chat is On
The system is pretty simple. It uses RLV commands to control whether IMs (including group chat) can be seen, and when local chat can be seen or not. If the user elects to turn off IMs and local chat, then only friends on the white list can send communications.
If an avatar who is not on the white list sends an IM, the viewer will block the message. On the viewer, the user sees this message:
Avatar Name: *** IM blocked by your viewer
And the Avatar Name will get this message:
The Resident you messaged is prevented from reading your instant messages at the moment, please try again later.
In local chat, non-white list members simply appear in Local chat as “…” and no notification is given to the member who sent the message.
The system is easy to use. Simply attach the device to your HUD, edit it and load your white list into the notecard called “!WhiteList”.
Next click the device on the HUD to bring up the menu
RELOAD – Reloads the current notecard.
CHAT ON/OFF – Turns Local Chat On/Off. When OFF text is muted and received as “…”. When ON, text appears as normal. (OFF by default)
IM ON/OFF – Turns IM Chat On/Off. When OFF text is received as “*** IM blocked by your viewer” from avatars that are not on your white list. Group chats, unless they are initiated by a friend are ignored. When ON, text appears as normal. (OFF by default)
ALLOW… - Scans the room and gives a list of all avatars. Selecting one allows you to temporarily add them to your white list. If you RELOAD the notecard then relog, this temporary ALLOW list is lost.
RLV forgets any settings you might have between sessions. It takes a few moments for the white list settings to be re-established. This also means that offline communications are still received, but while online undesired communications are blocked.