Talk:LSL Protocol/Restrained Love Open Relay Group/ORG Requirements/0004 draft
What should 0004 change?
(discussion moved from the ORG Requirements talk page)
- llRegionSayTo recommended (except for wildcards)
- !implversion reply prefixed by ORG/
- make clear what commands are restricting/secondarily restricting/... and how they affect the relay state and when and how they should be accepted or not
- !x-clear/<string>: clears all meta-restrictions having the string
Definitions of types of commands:
- (primarily) restricting: any command which once executed produces a lasting effect restricting possible behaviors of the wearer until explicitly released. Example: all the RLV @xxx=n/add commands, !vision, !follow, !freeze, ...
- secondarily restricting: any command which has a lasting effect (and requires some global variable to store its state) but whose point is moot if there is no (primary) restriction: !x-email, !x-channel, !x-key, !x-ack, !x-noping, !x-autoforward...
- actions: commands having immediate concrete effect: RLV @xxx=force commands
- queries: commands querying the relay or avatar for data: RLV @xxx=channel commands, !version, !implversion, !x-orgversions, !x-fwd
- releasing: commands removing a restriction: @clear, @clear=xxx, !release, !x-xxxx/clear, @xxxx=y/rem.
- !x-delay: should be seen as primarily restricting since the "timeout" is not at the discretion of the implementation and no currently effective restrictions needs to exist for !x-delay to make sense. On the other hand, no explicit release command is needed.
- For !x-takeover, there are 2 possible points of view
- either releasing (never refused), but with the secondary effect that an open session will be transfered if the key was valid
- or secondarily restricting... but then one must consider that the choice accept vs reject was based on a new criterion: the validity of the session key
- In either case, it must be clear that !x-takeover cannot ever open a new session or trigger an interactive dialog.
- !x-handover: a choice must be made. The most natural would be secondarily restricting, I believe. It can trigger an ask dialog. If accepted, then trust can be transfered over. If there is no actual restriction in the session, there is no point in keeping it open longer than the reasonable life of the auth token !x-handover creates.
Relay states (with respect to one controller):
- transient session
- persistent session
In my view:
- releasing and queries commands should be accepted without question in every relay state
- restrictions (primary and secondary) and actions are accepted without question within a session
- otherwise the income depends on relay settings: commands can be automatically rejected or accepted according to some criteria, or the wearer can be asked.
- accepting a secondary restriction or an action while free opens a transient session
- accepting a primary restriction while free or in a transient session opens a permanent session (or makes the session permanent)
- releasing *all* primary restrictions makes the session transient
- a transient session is always automatically closed after a reasonable timeout
- when no session (relative to a controller) is open, all sessions variables are forgotten, which includes various authentifications tokens and other communication preferences.
Does that make sense?
--Satomi Ahn 09:32, 9 June 2011 (PDT)
Transient sessions may look like a useless complication, but from the point of view of trap scripters, it makes stuff much easier not having to explicitly open a session only to send @xxx=force commands. Consider the sheer amount of strip walls or forced teleportation traps (and who does want to answer 10 consecutive dialogs for each piece of clothing that will be stripped?). So we need transient sessions in practice anyway (my relays use them, and I believe other relays also do under some form).
Now coming back to commands such as !x-email, !x-channel, !x-key, !x-ack, !x-noping, !x-autoforward... These set a lasting behavior which thus needs a session to be open at least for the duration of the effect. Also let's keep in mind that no session can be opened without authentification, so these commands need auth to have an effect.
The question is whether one of these effects alone (with no true restriction) justify keeping a session open until an explicit release. My feeling was that the answer was no, which makes these commands of a different nature than either instant effects and permanent restrictions.
If the answer is no, there is still one point that needs to be specified: the behavior when sent outside of an authed session
- should the command be ignored? (ko)
- or should the command be authed and open a (transient) session?
If the answer was yes, then these commands should add restrictions and be handled exactly like @xxx=n commands (and in this case, we must check that every of these commands has a corresponding command for releasing them).
--Satomi Ahn 00:24, 10 June 2011 (PDT)
On a close topic, 004 should also make a clear statement about @xxx=channel commands. Do we consider them as a privacy risk? Are they acceptable for just "scanning" relays?
On the pros side:
- getting an actual answer from the viewer is something more reliable than answer from the relay (the controller knows that both relay and RLV work)
- it makes it possible to spare a few messages by asking directly what you need before attempting to grab (or not... if the answer is not satisfying)
- information the viewer can leak has pretty limited impact (and could be requested later on, after grabbing, anyway)
On the cons side:
- letting @xxx=channel commands get through makes it possible for the viewer to leak some potentially private information
- using several messages for scanning and requesting information is not as bad as it used to be, thanks to llRegionSayTo
Anyway, considering there is a demand for privacy protection, I don't think it is reasonable to require that relays should automatically accept @xxx=channel commands.
To mitigate with annoying ask dialogs, maybe we could propose the following extensions/commands:
- either something like !x-dontask, which would tell the relay not to interactively prompt the user (and refuse all subsequent commands if auth would have been required)
- or the !x-modeinfo command, already proposed before, which tells the controller what mode the relay is currently operating (in particular whether it is interactive... and maybe some more information like: "interactive, but channel commands go through")
Of course, !x-orgversions only can tell whether these x-tensions are supported. Fortunately !x-orgversions triggers no interactive dialog in any relay I know of.
--Satomi Ahn 08:24, 20 June 2011 (PDT)
OK, I'm in a strange situation replying to this, since I represent 3 types of RLV scripter and I switch between those roles (furniture maker, wearable maker, relay maker) frequently. My answer to at leasr part of the discussion you've raised is from the furniture maker point of view.
I help make toys that have a force sitter embedded in them and I try my best to provide the toy operator the best possible information with respect to who can be forcibly sat. Now, there are three choices: 1) run a sensor for avs and present a list of people around the toy and hope that they have an active relay 2) run a sensor for avs and test them with !version to see if they have a relay that responds 3) run a sensor for avs and get their restrictions, eliminating anyone who cannot be forcibly sat on the toy.
We often got questions of "why can't the force sitter sit this or that av" when we used choice #2 and now the commonest question (after adopting #3) is "why can't I force sit myself". Which is for completely different reasons.
As a furniture maker with a force sitter, I don't care if an av is wearing a relay, I care if they can be forcibly sat. So, I want to know the av's status. For example, they may be sitting with an @unsit restriction, or they may be standing with an @sit restriction, or they may be leashed and have an @sittp restriction (OK, if they're within 1.5m they can be forcibly sat, but they might well not be when their name is selected even if they are when I test). All of these cases stop an av from being forcibly sat and therefore lead me to drop anyone with those conditions from the list I present to the operator.
So, if we require !version to know if someone is wearing a relay, fine, I'll do that, and then test their status and they'll get asked. Yes, it's different to use @getstatusall and not !version or @versionnew, but different isn't wrong, it is just different. From the point of view of a furniture maker I want to present the best information to the operator and the only way to do that is through @getstatusall.
If people are worried about privacy? Don't wear a relay, or wear a relay that is set on an ultra paranoid setting and queries the wearer on every @get.
Chloe1982 Constantine 21:02, 23 June 2011 (PDT)