LSL Protocol/Restrained Love Relay/Change History

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. (Felis Darwin)

---

Suggested Change

Add support for "!mode" metacommand, to allow objects to query the relay's effective current operational mode (i.e 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.

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
  • Safeword support
  • Color indicates mode

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