LSL Protocol/Restrained Love Relay/Change History

From Second Life Wiki
Jump to navigation Jump to search
Restrained Love Relay

Changes to the specification

1.015 to 1.02

Change
Removed the llSay restriction.
Justification
That restriction (only llSay, no llShout or llWhisper) was there to make sure the avatar was able to answer. However, it made some large layouts almost impossible to build because the relay would be controlled by only one object at a time, and under 20 meters away. This led to a few derivatives of the relay spec, aimed at prisons and such. The automatic response from the viewer to commands such as @version etc was limited to 20 meters but the RestrainedLife viewer v1.12.4 and later will change that to shout over 100 meters. At the time of this writing that version is not released yet, but the sample code is modified to take this change into account.
Suggested Change
World objects must support ping queries during an active session even without the victim being offline in between.
Justification
Relay objects should be able to check that the world object is still present and working. ADDENDUM: Also prevents malicious "lock-n'-leave" use of Relay-controlling attachments.
Objection
This requires an object to keep an active listener open even if it doesn't support people going offline and returning. It prevents the fire and forget way of using the relay where you simply don't listen for responses and just always send the restrictions and the !release, so saving on having a listener. Better approach would be for the relay to check it's still within 20m of the object (and also release on a region crossing). (Chorazin Allen)
Reply
This would close a LARGE loophole that griefers and other ne'er-do-wells exploit. (Infrequently, but relays are only just really catching on) The small overhead cost of the listener in the controlling object would be FAR outweighed by the benefits of closing this hole. ADDENDUM: Periodic pings are also the only viable way to handle situations where the control script crashes inside the object. Furthermore, having an always-open listener checking for ping is the only uniform (and most effective) way to fix the issue with relay users being force-sat on an object that has since been re-occupied during their offline time; since we're already going to have a ping listen active, we may as well make use of it. -- Felis Darwin 00:06, 29 September 2008 (PDT)
I am concerned that this will be abused for jokes rendering auto-mode unusable quickly. Currently such griefers have to take into account that they will spam lots of people with permission dialogs so making the object discoverable easily. But if they can only attack people in auto mode they can hide much better. This issue has increased in priority with the increase of the sphere to 4000000m³ (radius of 100 meters). --Maike Short 16:00, 11 October 2008 (PDT)
Suggested Change
Add support for "!mode" metacommand, to allow objects to query the relay's effective current operational mode (e.g. OFF, ASK, or AUTO) as it relates to the object. (e.g. while in AUTO mode it will indicate it is in ASK mode if the object fails the "trustworthy" check)
Justification
Scripters and designers may wish to implement different actions based on a resident's relay mode, or even simply categorize them differently. (e.g. separate lists in a relay scanner based on the relay mode)
Objection
The modes OFF, ASK, AUTO are not part of the relay specification. They are used in the Reference Implementation, but other implementations exist.
Reply
True, other relays may not have the same modes, but any additional options I can think of can be classified into four basic categories: No Access (OFF), Consent Required (ASK), Full Access (AUTO), and Limited Access (e.g. certain restrictions may not be applied or will require consent first); there may be more, and we should perhaps discuss those in further detail. I'm not suggesting that the three we use currently should be the ONLY ones supported by this, I'm merely suggesting that we should implement a way to let objects query a relay for at least a BASIC hint as to the operational mode it is currently in. -- Felis Darwin 00:06, 29 September 2008 (PDT)
Suggested Change
Relay issues a "!release,ok" reply whenever it releases restrictions applied by an object or when control by an object is denied, regardless of whether or not the object issued a "!release" command.
Justification
Currently there is no way to detect when a relay has deactivated restrictions independently (e.g. by invoking the safeword), nor is there any way to detect when permission to control someone's relay has been denied, other than checking to see if a command confirm reply hasn't been issued by the relay after a set period of time. -- Felis Darwin 22:55, 30 September 2008 (PDT)

1.014 to 1.015

Change
Relays must accept !release even if the world object is out of range.
Justification
There are restricted areas like a room for example. If a person leave such an area the object may not notice it in time because of script lag.
Change
If a world object sent any restrictions, it must end the session with !release even if the relay did not respond with "ok" unless all commands have been "ko"-ed.
Justification
Most relays allow the victim to grant permission using a dialog. While it is active the application of restrictions is delayed. This leave the problem that the session may have already ended (dune to a timer or another person freeing the victim) before the victim grants permission.
Change
Only !pong is accepted as a valid response for !ping
Justification
Many objects check for presence of a relay and the RR viewer by asking for the !version when sat on. If the user crashes, and the object was used by someone else in the meantime (or, for testing, reset), the relay enforces all previous restrictions whereas the object doesn't know of them. (Gregor Mougin)
Change
Add a new meta command "!implversion" to which the relay should respond with the version of its implementation. This version string is not intended for automatic checks but to help debugging problems.
Justification
It makes debugging of problems easier as it is now possible to check that the wearer is using the latest release.
Change
World objects should not spam the relay channel. For example: Querying every minute the relay version of every person near although nobody shows any signs to actually use the object.
Justification
Laaaaag! You are not alone out there. While one laggy object is not that worse, many laggy objects at one place are. Beside that it makes debugging more difficult.
Change
Everyone listening on the relay channel must have enough script memory free to handle a complete chat message which is limited to 1,000 character (2,000 bytes + processing).
Justification
Although this should be obvious there is quite a number of world objects out there that crash with a stack-heap-collision if placed next to other world objects which use long commands (like a list of chat/im-exceptions for people near). Mono will improve this situation in most cases. You should, however, not be too excited about the increased memory limit, as Mono code does use much more memory itself.

Changes to the reference implementation

1.015 to 1.02

  • All changes of version 1.015 have been undone
  • the limit of 20 meters has been extended to 100 meters

1.014 to 1.015.a

New features

  • Implements version 1.015 of the specification
  • Accept !release out of range
  • !release and @...=y now clear list of commands pending the permission dialog
  • Prevent detaching while active
  • Check that the controlling object is still in range when an another object wants control
  • Can ignore commands sent by attachments
  • Can filter force-commands (like @tpto, @remoutfit)
  • Internal API to simplify Embedding of the main script into other relay objects
  • Code cleanup and moved code out of event handlers into functions to allow testing in LSL Plus
  • Plugins


Bugfixes

  • fixed a bug which allowed bypassing the permission dialog in ask-mode
  • fixed force sit on login (after two failed fix-attempts)
  • only accept !pong as valid response to ping


Old changes not split up

1.014a

  • fix of loophole in ask-mode by Felis Darwin

1.014

  • improved compatibility with existing world objects and simplified the world-object coding
    • commands to remove non-existing restrictions must be ignored silently by the relay (without spamming the user with pointless request-for-permission dialog)
    • simple (harmless) commands can now be joined in one single message without triggering the permission dialog.
    • multiple pending messages from the same object are now stored over the permission dialog.

1.013e: no changes in the specificiation, just in the sample code

  • Verified how far away the object is that is trying to control you. The specification says that the object must use llSay for 20meters max range. But as the object is not trustworth this must be checked in the relay again.Previously llShout (for 100 meters) and llRegionSay (for the complete sim) did work, too.
  • the permission request dialog was shown even if the command was for another person
  • the ping/pong on login did not verify whether the pong event was for us and not some other person.
  • fixed a problem which caused additional questions for permission dialogs
  • now automatically accepts commands from an object you were forced to sit on by the relay (so you only have to confirm that once)
  • fixed force sit on re-login which could fail if the login was very slow
  • code cleanup

1.013

  • fixed force-sit on login (by delaying it for 10 seconds)
  • allow meta commands without asking for permission
  • fixed a vulnerability which allowed faked responses for the permission dialog
  • extended object identity check for the object/parcel owner (before it checked only the group but there is groupless personal property out there)
  • prevent turning off of the relay when it is locked

1.012 Fixed a bug in !release which caused the relay to reapply those restrictions on login for the object NULL_KEY. But as there is no ping/pong for NULL_KEY the wearer was stuck.

1.011 Precision on the ping-pong routine : relay standard message would be "ping,<object_uuid>,ping,ping" so objects can keep a listener with a static filter, to reduce lag. Thank you again Monica Jewell for the suggestion.

1.010 Added the ping-pong routine as a way to ensure the object is still available when the user relogs. Also updated the sample code to handle the timeout. Thank you Monica Jewell for pointing that possible problem out.

1.000 First release

Retrieved from "https://wiki.secondlife.com/w/index.php?title=LSL_Protocol/Restrained_Love_Relay/Change_History&oldid=95229"