Talk:LSL Protocol/Restrained Love Open Relay Group/ORG Requirements

While I preferred the name !x-tensions (yes, I liked the pun), !x-orgversions is fine by me. I am not sure what the version of ORG will relate to, but it won't hurt to put it into the spec.

The requirements on relays are not onerous. I am for this and, if approved, will withdraw the !x-tensions proposal. --Chloe1982 Constantine 13:15, 18 July 2009 (UTC)

Being the one originating this proposal, it is obvious I vote for it too. Now, why voting for this? It is more than the requirements per se that are important, but acting the principle that

1. ORG does not only proposes extensions but also fixes some breaches in Marine's spec
2. everything ORG proposes, being the optional extensions or the fixes in the core specification has to be versioned
3. versions of core specification are necessary for the same reasons as the RLVR spec are versioned. Moreover, if Marine ever reads those fixes, maybe... maybe some day she will fix her spec, and then we will be able to remove this from ORG.

For the future of the core requirements, sometimes I wonder if I won't rewrite the RLVR protocol from scratch, making it both easier to read and more precise than it is now, while preserving compatibility (someone pointed to me that Marine's spec actually left a lot more implicit things than I thought: it is not even clear that every "@" command should be acknowledged, actually! Neither are the meanings of "ko" and "ok" explained).

--Satomi Ahn 09:56, 19 July 2009 (UTC)

All looks good from here, no objections or complaints... rock on.

--Ilana Debevec 18:52, 19 July 2009 (UTC)

I would suggest handling the "unrestrict when out of range" problem differently. Susan Daviau currently provides a proprietary extended mechanism for restricting someone who may go out of shout range. This sort of extension requires a communications mechanism that is not restricted by llShout distances - email, or http requests for instance provide cross-sim control.

((Correction)). I see that such a proposal is in the works , an e-mail extension. If someone is using this extension, I don't think we want restrictions automatically dropped when they get out of range.

In addition, if we want to get Susan Daviau on board (has anyone contacted her?) it might be good to make org extensions compatible with her products.

I am not sure how to reword the specification exactly.

I also am somewhat in favor of making the range check a function that the relay wearer can trigger, rather than automatic function. For instance, I might wish to allow someone to restrict me with a portable control device and wish to honor the restrictions even if they go out of range. Making the out of range check more interactive and manually triggered would make this possible.

Nano Siemens 00:12, 20 July 2009 (UTC)

Concerning Susan: I don't know if she was contacted. I believe she should be.

My proposal about releasing restrictions was only for unreachable controlling devices. If the relay is using e-mail, then the controller remains reachable from other sims (although it is less easy to check).

Should the wearer trigger the function by hand? Well I don't know. Let's reword the requirement, then: "make it possible for the wearer to be released if the controlling device is not reachable" and not specify if this will be done automatically or called by the wearer.

Concerning portable devices: currently the issue is that after teleporting, even if you come back, you cannot release the relay, as the portable device UUID has changed. Using e-mail can circumvent this. Other mechanisms can be considered.

As a side note, everything that is done by email up to now could from now on be implemented using http-in. I don't know what are the compared advantages of the two approaches, but anyway I will eventually write a !x-httpin extension.

--Satomi Ahn 14:10, 22 July 2009 (UTC)

I like Satomi's suggestions, and have taken the liberty of attempting to reword the specification to incorporate them. Nano Siemens 22:37, 23 July 2009 (UTC)

Other remarks

• !ping/!pong? Is it ok to have pong not acknowledged? It would be a notable exception... but this acknowledgement is useless
• As it is now, every known meta-command has to be executed when requested. Maybe it is not a desirable behavior. But there are several other possibilities:

• allow answering "ko" when for some reason the relay wants to refuse a meta-command it knows
• adding a new possible answer distinguishing between unknown and refused

If we don't change the current spec, it is still possible not to announce the support for some commands in !x-orgversions reply. However, it is likely all the relays will want to reply to !x-orgversions automatically without thinking twice, whereas some meta-commands might require some authorization from the wearer (for instance it would make sense to ask authorization for e-mail mode). This means that !x-orgversions does not necessarily have all the data for knowing whether meta-commands will be accepted in the future.

• Another question concern the hypothetical 3rd suffix, which would be used for RLV-like effect that are implemented by LSL scripts instead of viewer mods (x-tensions like vision, gender, species, freeze, follow, control, listen, message or animate). I believe those should be handled by the relay core script almost like RLV commands, but sent to plugin scripts instead of the viewer with a llOwnerSay. It would also be nice if we could write a common API for such relay plugins.

--Satomi Ahn 11:44, 24 July 2009 (UTC)

I added the criterion of "ping" for device reachability definition: I had overlooked that Marine's specification said that every device has to be able to answer "ping"s anytime. Which implies that lots of devices are actually not compliant with Marine's specification, including mine! (I will fix this in all my devices as soon as I can.). Of course it makes as much sense to ping by chat in normal use as to ping by email, in case of email mode. --Satomi Ahn 13:12, 27 July 2009 (UTC)

I think there was still some controversy on whether devices should always answer pings or not. Last I recall there was some controversy over this, with Chorazin being against it. But I don't recall the details. Nano Siemens 20:38, 27 July 2009 (UTC)

Well this goes against the principle that controlling devices should be kept as simple as possible... but also gives a convenient way to escape devices that are stuck or just unrezed for whatever reason. Anyway, controversy or not, it has been in Marine's spec for a long time, and I think it is right to assume that devices are compliant (even if it is not true!).

What do we risk in case they are not? Releasing restrictions when it wasn't supposed to be possible? Is it that big a issue if the relay only does this when asked to by the wearer (wouldn't be worse than a safeword)?

--Satomi Ahn 11:41, 29 July 2009 (UTC)

Version 0002

I added two things, I think most of us will agree with:

• the possibility to send a RLV relay command to *every* relay around, using NULL_KEY instead of an avatar key. Landowners may be reluctant to set their furniture to use this, because some relay won't be compatible and won't be seen in a scan using a wildcard "scan,00000000-0000-0000-0000-000000000000,!x-orgversions", but we have a good argument as it will help decrease lag and make scripts a lot simpler. Moreover, ORG compliant relays are now a majority of the market. Anyway, adding this feature in relays is not a great involvement, so why not add it in prevision for the future?

• the requirement that a relay sends all its message towards a controller through the same prim. Until now, this wasn't really necessary to specify this, but I ran into this problem with a new relay (Dahlia's relay, just released), a multi-prim relay, like tkPBA, which in its pre-version was sending acknowledgements both from the root prim and from the secondary core. This caused issues with my Witchy remote, as it restricts is listener to one key, as soon as it knows the key of the relay. Dahlia and me agreed that it was a good practice to make it easy to restrict listeners, so she fixed her relay so that only the root prim sends acknowledgements.

For the future, I think it is wiser to put this restriction in the specification.

--Satomi Ahn 13:19, 5 August 2010 (UTC)

Big problem in 002: using NULL_KEY as a wildcard was not a wise choice. It seems many buggy devices already inadvertently send NULL_KEY sometimes, when the target id variable is not initialized. 003 will change this, suggesting another UUID to use instead. Key points:

• keeping it as an UUID makes it easier to analyze in relay scripts without changing too many things
• the UUID that is used must either be easy to remember, or already exist as a constant in LSL (like NULL_KEY), to make it easier to write a controller script without having to open the spec again to look for the exact value.

Suggestions:

• 00000000-0000-0000-0000-001812221819: the number at the right is the same as the relay channel, so no need to look up for another constant to copy/paste
• FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF: very easy to remember
• TEXTURE_* LSL constants: very easy to remember and to type... but a bit confusing

--Satomi Ahn 09:54, 20 December 2010 (UTC)

• What I have done is use sensor and get the list of people in range. If they do not respond then I target them individually. This gives only one additional message if no one has an ORG relay other wise it does save.
• I would use FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF as I will not have to look it up or 00000000-0000-0000-0000-001812221819 as it is less likely to be used other places and you already have the number in the script or will have to look it up anyway.

Master Starship 15:03, 20 December 2010 (UTC)

Let's go for FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, then.--Satomi Ahn 14:37, 22 December 2010 (UTC)

I like this option best--Chloe1982 Constantine 00:57, 24 December 2010 (UTC)

Other ideas

I have a few ideas I'd like we consider for future versions.

!implversion and !x-orgversions

What about:

• Having !implversion answer contain at least ORG (and why not more information from !x-orgversions). Reason: makes it faster to check ORG compatibility in case of relays who don't answer to !x-orgversions.
• Eventually (but maybe it's too late to do this) deprecating !x-orgversions and put everything in !implversion. Reason for doing this: most relays answer to !implversion

Criticism: the most common relay who does not answer to !x-orgversions also ignores !implversion... Added to the fact !x-orgversions is now well established, maybe this point is now moot.

Make it possible to break a command line on ko

This could be just another x-tension, but if this became common place, it would make it much easier to specify new interesting x-tensions, that would rely on relays having this mechanism.

More precisely, I suggest a new command !x-break_on_ko (and maybe a variant !x-break_and_release_on_ko), that would ensure the relay won't execute commands that do not make sense given that a previous command did not work (i.e. was ko'd, for any reason: not supported, or refused).

For instance, it could be combined with !x-delay, if you don't want the command to be executed at all by relays who don't support !x-delay ("execute this in 10 minutes, but if you can't count 10 minutes, don't bother with this").

Other case: if the relay has filters, for instance if it won't accept IM or inventory restrictions (which I would understand, considering how obnoxious those can be!), but the person who controls the cage or device thinks it is important for the victim to be thus restrained (yes some people have weird ideas :P). Then it would be possible to just not grab this non-cooperative victim.

!x-break_on_ko does not make it possible stuff that was not possible before. It just makes it easier, as there is no need to listen for "ok"/"ko"'s anymore (btw: it's an interesting combination with !x-ack), and in some case you won't even need to check !x-orgversions anymore. So less communication between controller and relay is needed and less complex controller scripts.

Biggest issue: it is very hazardous to rely on !x-break_on_ko if you don't know whether the relay supports it. So, an initial !x-orgversions or !implversion might still be needed, which makes this feature less attractive. --Satomi Ahn 15:21, 6 January 2011 (UTC)

Version 0004

Discussion moved there. Current draft is there.