Changes to the specification

1.040 to 1.100

I, Marine, am taking the responsibility of the maintenance of the relay spec again, now that Maike is gone. She has done a great job at keeping things together and without her, this spec would be much messier. Everybody was putting their own favorite commands in the spec, which made de facto every existing relay out of spec. This was not acceptable nor constructive. We are now back to the basics, with !implversion being included as an optional command (since it is tied to the implementation of a particular relay).

However I want to thank you all for your contributions and discussions, and do not intent to make this move look like closing the spec. I am still receptive to suggestions but I believe in keeping things centralized and controlled in order to avoid shooting in the corners again. I am trying to do as little damage as possible.

It must be very clear, though, that adding commands to the spec makes a new spec, and kicks existing relays out of compliance. This is why such changes need to be thought and tested very seriously first.

1.030 to 1.040

Change: Added !who command
Justification: On public places the owner is often not controller but at many such places the owner of objects is trusted enough to say whom they are controlled by.; Discussion

Change: Added an optional !vision command
Justification: World object like cages should be able to restrict the vision of the victim. This command is optional because it requires a HUD.; Discussion

Change: Added !handover command
Justification: World objects should be able to pass control on the the next step in a processing facility or teleport people directly into a trap without a redundant permission query; Discussion

1.020 to 1.030

Change: Relay must send !release,ok if an active session is canceled from the relay side for example by calling safeword or another release mechanism implemented into the relay.
Justification: The world object should be able to detect that it has lost control. This is useful to change the status text from "securely locked" to "escaped". And it works for world objects that cannot do collision- or sit-detection because of their nature.

1.015 to 1.020

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)
Reply: Relays can check if the object is still there by using llGetObjectDetails() and free restrictions when it's not or if it's too far away. A script crashing should be fixed rather than having external means work around the problem. If a developer can get away with broken scripts, because the Relays try to cope with them, they will never learn to fix their bugs. "Griefers" will always be able to harass you (rez a poseball that force sits you and then run away). You can very easily have an object answer to !pings from anyone when it's ready to take a prisoner, so I don't understand the problem with "being occupied afterwards". The NULL_KEY listener overhead on a private channel is neglectable. Voting against. --Toy Wylie 12:19, 25 March 2010 (UTC)

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)

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: 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
- 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

LSL Protocol/Restrained Love Relay/Change History

Contents