Talk:LSL Protocol/Restrained Love Open Relay Group/who/002 draft

Traps

Is it intentional that you removed the statement traps that are automatically triggered by the victim should use the uuid of the victim instead of the person who has setup the trap, perhaps hours ago? That requirement seems reasonable and useful to me. In particular, it seems reasonable that a relay user (and hence a relay) may desire different behaviour if they stray too close to a trap that is set to autocapture, versus if a third party clicks a 'capture' button on the trap menu. Specifying the behaviour in the case of getting caught by a trap allows such a distinction to be made. Melancholy Lemon 14:22, 13 June 2011 (PDT)

To me sounds a bit oblique to use !x-who to that effect. However I acknowledge there is currently no other way to signify that the current command is sent by an automatic trap.

Maybe I can suggest adding a second optional argument to !x-who in the syntax:

          !x-who/<user key>[/<grab type>]

where <grab type> would tell more about the context, such as whether it was triggered by another user action, or by the avatar stumbling upon a prim or entering a zone, or sitting on something. So typically for a trap you'd have

          !x-who/<land owner key>/zone_entered

or

          !x-who/<key of some earlier visitor>/stumbled

It is clear we would need a list of cases that is more or less standardized.

Now I would be interested to know if some relays already were using the hint that the key was that of the relay wearer, how they were using it, and how one could use more detailed info.

Chloe, Dahlia? Any insight about this?

--Satomi Ahn 05:38, 14 June 2011 (PDT)

I suppose my thought was really just that the requirement has been in the spec for a long time, so it's possible people might be using it. It seems to me that it costs nothing to include the victim's uuid in the message, since there's nothing else that can really usefully be put in its place, and removing it constitutes an (admitedly small) incompatible change. For an established spec with deployed devices, I think it is better to try to avoid changes unless really needed. Also, the possible alternative approach of trying to specif the UUID of the person who set the trap doesn't really work, I think, because it's not well defined. Who is the person responsible? The person who last touched the controls? The person who most recently enabled auto-trap mode? Something else again?

Consider the following scenario. I encounter a device in a public place that is set to auto trap (perhaps I get trapped by it). I spend some time playing with it, at some point disabling auto trap mode, perhaps instead using a capture mode on someone else. Finally, when I'm done playing I take care to set the settings back as they were when I found it, including re-enabling auto-trap mode. Should I now be regarded as the person who set the trap? Should subsequent people who get trapped by the device now be told that *I* am trying to trap then? That wouldn't seem correct to me Melancholy Lemon 12:06, 16 June 2011 (PDT)

Authentication prompts

I'm also a little unsure as to whether the spec should really be saying anythign about authentication prompts - it should be up to the relay maker how it behaves, I think. Consider the following play (without the use of !x-who):

I allow someone to lock me in a cage is a public place. My relay is set to have no safeword. They subsequently set a timer on the cage, and leave, knowing that the cage controls are such that any passer-by may use the controls, e.g. increasing the timer or changing the RLV restrictions I'm subjected to, and knowing there is nothing I can do to prevent this. Of course, they plan to come back later to check on me and ultimately release me but in the mean time I am helpless.

Now, how would this play be achieved if the cage and relay both supported !x-who? If the cage were to send an !x-who with the UUID of the person operating the controls when someone changed my RLV restrictions, and if the relay were to present me with an authentication dialog when it saw a new UUID in the session, then it would be my choice as to whether to allow it the change in RLV. I could set my relay to 'auto' but even then, depending on the design of the relay I would probably be able to change it back to 'ask' again later. Our only option to achieve the scenario of the previous paragraph would seem to be to select a cage that doesn't support !x-who or to select a relay that doesn't support !x-who.

Now, I'm not sure what the fix is for the above, but I think the spec should leave it open for relays to process the !x-who UUIDs in different ways, as they feel appropriate. e.g. a relay may wish to only check x-who on the initial locking command and then accept all subsequent commands as long as it remains locked. Melancholy Lemon 12:33, 16 June 2011 (PDT)

The spec does not say an ask dialog should necessarily appear. It only says it is a command that asks for some kind of authentification (that can be automatic or interactive, depending on relaysettings).

This means that in Ask mode, and in absence of black/white lists and other exceptions, then the dialog should definitely appear.

The spec should says nothing about relay modes, but it is a good thing to know what commands will definitely be accepted (or rejected) with nothing asked in any case, and which commands might trigger some dialog (depending on settings).

It is good to know that by sending !version all over to everybody around, you know you are not spamming them with blue dialogs.

--Satomi Ahn 06:16, 17 June 2011 (PDT)

The part I'm not sure I agree with is: This means that in Ask mode, and in absence of black/white lists and other exceptions, then the dialog should definitely appear.

Normally, as a relay user, I expect a possible authentication prompt when a controller establishes a session. I'm not at all sure I want to get further authentication prompts during a session I've already accepted. Once I've made the decision to allow the session I don't think I want to have a way to block any part of that session, short of safewording (if I've chosen to leave myself that option). Melancholy Lemon 08:42, 19 June 2011 (PDT)