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

From Second Life Wiki
< Talk:LSL Protocol‎ | Restrained Love Open Relay Group/ORG Requirements
Revision as of 03:30, 28 June 2011 by Dahlia Orfan (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

What should 0004 change?

(discussion moved from the ORG Requirements talk page)

To add:

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

  1. (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, ...
  2. 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...
  3. actions: commands having immediate concrete effect: RLV @xxx=force commands
  4. queries: commands querying the relay or avatar for data: RLV @xxx=channel commands, !version, !implversion, !x-orgversions, !x-fwd
  5. releasing: commands removing a restriction: @clear, @clear=xxx, !release, !x-xxxx/clear, @xxxx=y/rem.

Particular cases:

  • !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):

  1. (disabled)
  2. free
  3. transient session
  4. 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)

I think it is a really good idea to have some concept of different levels of command, your definitions up top are fine. But, as a furniture maker, I don't think it is up to the relay to decide what a toy should or should not emit as a first command, so that leaves me with the view of use multiple levels, and then the question is how many should there be?

Marine's original (and current spec) leaves that wide open and I am comfortable with that both as a furniture maker, a relay maker, and a user. Of course, as a user I choose the relay I like the best and as a relay maker the relay I wear behaves in accord with my desires.

If ORG really wants to decide levels of command then I think that primarily, secondarily, actions, queries, and releases is a good definition of the levels. However, as a relay maker and a user I don't want too many levels and am very comfortable leaving it up to the relay maker to determine the levels they like and then the user to choose which relay they like.

This seems to me to be an area that *doesn't* need standardizing and allows for good variation in the community. I'll go with an ORG decision on standard levels, though I would like to be free to choose to combine levels.

Marine's relay spec originally used 3 levels, off, ask, auto. But that wasn't mandatory, just advisory. The current spec still makes it advisory to have a reasonable number of levels of protection, but doesn't say what those should be. This is an area best left to each relay maker to decide for themselves. For example, we think it's a good idea to introduce the concept of untrusted devices (ones that are not in the land group). In the tk PBA auto mode, you will get asked if an untrusted device is trying to control your relay (which gives some small protection against griefing). Should everyone adopt this strategy? I don't think so, should the PBA be stopped from adopting this strategy? I don't think so either.

With the definition of the levels, we can point people to that and it gives a common terminology, but after that it should be up to the relay makers to decide what they want to do. Particularly as there are oddities, like !x-vision which I consider to be a primary restricting command.


My vote (until persuaded by further discussion) is not to standardize on levels, I don't see the need.

Chloe1982 Constantine 21:29, 23 June 2011 (PDT)

Chloe, I am afraid you answered to the early comments instead of the current version of the draft. In current draft, there is not real definition of levels, but only only 2 boolean variables associated to a session.
  1. a variable that says that the relay will never again bother the user with an ask dialog (that's the Authed session state)
  2. a variable that says that current session is Locked, meaning it won't time out on its own and will be released only if asked by the source, or if the source becomes unreachable, or on safeword.
My purpose in writing it this way was to minimize unpredictibility (such that questions like "if I scan with @getstatusall, will relay wearers be spammed with blue dialogs?" or "If I send !x-who|@sit:xxxxx=force, will the relay still be grabbed in 2 hours?" may be answered), while still keeping a lot open to implementation (in particular, actual relay modes).
"Primary" and "Secondary" restrictions were my first attempt at formalizing my thoughts. Where the equivalent to "Primary" in current draft would be just a restriction (a command that Locks a session), and where Secondary would be any other command that stores some token in session memory, without locking it. Note that a command that can trigger an ask dialog can make the relay store an authentification token and could in some sense be considered as a secondary restriction... but anyway, I removed these definitions from the draft.
Another important contribution of this draft was the formalization of the notion of session, as fundamental to the relay protocol (I believe it was already implicitly there in most relays, although completely absent from Marine's specification, which made it unpredictible). This was necessary to specify more precisely how long stuff (like authentification state and tokens stored by various x-tensions) should be remembered. Moreover it made it easier to define what the session key (as defined in the Key x-tension) should apply to.
Coming back to your point. It is now time to decide whether @getxxxx=channel commands should require Auth or not, as if the answer is yes, then you won't have to worry about your furniture spamming ORG relays with blue dialogs. If the answer is no, you will have to either scan with !version or accept that some relays may pop up dialogs (which will still be a minority I think... but the possibility will exist).
--Satomi Ahn 23:52, 23 June 2011 (PDT)

Speaking as a relay maker, the reason I resonated with the levels is that I have been thinking along these lines for the generation 2.0 of the tk PBA. Right now I have 3 levels named, nerdishly 0, 1, and 2. I've been assuming that level 0 is a pass through and is where I put most of the metacommands and also the @get's, then level 1 is all the non-restricting commands (all the =force) and level 2 is the restricting commands. Given that I have these three levels it made sense to allow authorization up to a defined level. So, a relay in ask mode would, on receiving a series of @get and or =force commands ask the wearer for authorization. The wearer might reply with an authorize to this level or authorize all. If the former, then the relay would pass through any level 0 or level 1 commands but would require a reauthorization if it received a level 2 command. If the latter, all commands would be accepted.

With this scheme in mind, if we split the @get commands into ones that need authorization, I would increase to 4 the number of levels in the relay, bumping my existing levels 1 and 2 up to 2 and 3 and then splitting my level 0 into the metacommands (still level 0) and the @get and @findfolder commands into level 1.

I still like the concept of authorization to a level with a need for reauthorization if a command in the incoming stream exceeds the existing auhtorization.

Speaking as a furniture maker, the concepts of Locked and Auth and Session are good, but I am not sure how important it is to standardize when they should be applied. I am much motivated by a long conversation I had yesterday by an individual who seemed to want me to change either the TK toys or the tk PBA or both to suit the individual's tastes. (The original discussion focused on @get.) I talked with one of the TK owners who thought that we should continue to use @getstatusall as the basis for our force sitter (I believe the other owner will also agree, but I've pointed her to this discussion to weigh in as she feels fit). Given this position, I'd like to see @get commands treated as a pass through, but I wouldn't require it. If someone wants to make a relay that raises a dialog box (I can't say blue since mine are all black) that's fine with me, they can make such a relay; I will choose not to use such a relay.

I guess my bottom line is this, I think it is really neat that the spec is underspecified with respect to concepts of Locked, Auth, and Session, this allows for variation and allows wearers to choose the style that best suits them. This looseness extends to safeword interpretation; the spec used to say something about it being a good idea for the relay maker to specify a safeword. We agreed and had a way of doing so, and then I saw what Toy was doing in her relay which I thought to be a really neat idea. At that stage I asked her if she minded me borrowing the concept and with her blessing I implemented both Easy Out and Real World safewords. Yes, I know this is a side issue but is indicative of my general feeling of wanting some looseness so that we can have innovation.

Chloe1982 Constantine 05:38, 24 June 2011 (PDT)

A remark about !implversion; I cannot change the string sent by my relay as acknowledgment since this string is the first step for some objects to detect the presence of my relay (and not another one), so I cannot add "ORG=0004/"; I actually do not see the interest to change this definition of !implversion (which is actually only a recommendation) since !x-orgversions already contains the information. --Dahlia Orfan 02:48, 28 June 2011 (PDT)

It's just one more place to have the information, moreover, in a command that is also supported by non-ORG devices, which can be convenient. Also this helpes advertising ORG.
As for your devices who check !implversion, wouldn't it be better to that purpose to rely on !x-orgversion? (maybe adding proprietary x-tensions, if you are using stuff no ORG x-tension proposes?) --Satomi Ahn 02:57, 28 June 2011 (PDT)
My concern is to keep the compatibility with previous devices and I know that people do not update easily. And I do not see the interest to deliver with !implversion an information which is already in !x-orgversions; advertising purpose is not sufficient to break a compatibility OMHO --Dahlia Orfan 03:30, 28 June 2011 (PDT)