LSL Protocol/Restrained Love Open Relay Group/who

This specification has been copied from LSL_Protocol/Restrained_Life_Relay/who after Marine Kelley's decision to deprecate the meta-command "!who" in the core relay specification v1.100.

As this meta-command had received a lot of positive feedback from users and scripters, it was only natural we decided to "scavenge" it into the ORG x-tensions list.

Because the specification of !who has already been thoroughly discussed, and even implemented in a non-negligible set of devices now, we can consider this current specification as final (until some bugs are found, of course). Some precisions might need to be added too.

!x-who

Implemented in THINK KINK's tkPBA v30i

Partly implemented in the Cool Hud v2.30  

Implemented in OpenCollar and in Satomi's Multirelay HUD

Note that as of now, this is actually !who which is implemented. We recommend that relays who already support !who, now should support both !who and !x-who indifferently during the transition period. In-world devices should ensure compatibility by using !who during the transisition, and later only !x-who.

Description

meta command to pass the UUID of WHO is trying to operate your relay, not just WHAT device and the OWNER of the device (more often than not, WHO's the operator and WHO's the owner are NOT the same avatar).

Background

we constantly have people coming to our store wanting a way to know WHO is trying to control their relay, it's almost become a mantra "I don't care WHAT it is, I want to know WHO it is!". This is a simple way to pass that information from a device to the relay when the device attempts use the relay.

Syntax

!x-who/(key)

(key) is the UUID of the AV that you wish to present to the relay.

Implementation

• 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
• 00000000-0000-0000-0000-000000000000 (NULL_KEY) is valid, meaning an unkown avatar
• The content of this message is obviously only as trustworthy as the world object is, which is most of the time enough if the object has been put by the land owner.

as THINK KINK is implementing this, we are making a few caveats -

We are making the !x-who as the FIRST entry in a command string, so it can be picked up immediately and used in an ASK dialog (if necessary)

IF the !x-who on a new command from an object is the same as the last !who from the same object, no ASK necessary

IF the !x-who on a new command from an object is DIFFERENT from the last !who from the same object, ASK again

IF no !x-who on a command string, normal object verification rules apply

Cool Hud v2.30 partial implementation:

When in "Ask" mode, and !who is used somewhere in the command line (and not necessarily as the first command) the relay presents the permission request menu with info about who is controlling the device.

When !who is present in a command line sent to the relay and bears the UUID of a user who was previously banned from the relay, the relay immediately frees the wearer (with !release ok sent to the RL device) and tells them the banned user attempted to control them via the device.

Further Points of Implementation

The ASK message will change if a !x-who command comes in, instead of "Dastardly Device owned by Random Avatar wants to control your relay, ALLOW/DENY?"

the message becomes "Crafty Avatar wants to control your relay using Random Avatar's Dastardly Device, ALLOW/DENY?"

if the owner and the operator are the same, then a more succinct message could be "Crafty Avatar wants to control your relay using their Dasterdly Device, ALLOW/DENY?"

further if YOU (the victim) are the 'operator' (ie. by walking into an area effect device) you could say "You have activated Crafty Avatar's Area of Doom and it is attempting to control your relay, ALLOW/DENY?"

addition of a this will make for clearer messages and communication with the victim.

if a !x-who is present, then should the victim DENY the request, an IM can go back to the 'clicker' "Sitting Duck has denied your attempt to control their relay".

Extension of the ALLOW/DENY dialog to include ALLOW/DENY/ALWAYS ALLOW (effectively give this AV 'Auto' Permission, no matter the relay setting)/ALWAYS ASK (give this AV the 'Ask' requirement no matter the relay setting)/ALWAYS DENY (effectively 'blacklist' this AV from any attempts to control your AV)

Means of saving/restoring these AV lists (allow/ask/ban) to/from the relay as backup/restore of data

This function is currently being implemented in the THINK KINK tkRLV 5IVE relay and THINK KINK devices.

Compatibility

since this is a metacommand, relays that don't support this should ignore it

--Ilana Debevec 10:44, 15 February 2009 (UTC)

EDIT: added some usability message examples --Ilana Debevec 20:22, 15 February 2009 (UTC)

Discussion

I came to this page to add something similar to this !who meta-command. But I am not opposed to the proposed mechanism, provided it ensures that there is never an ambiguity on who is the current user (but as you present it, it looks ok).

Now imagine you are using a multi-device relay and you are under restrictions from several users through the same device. How should the relay interpret a !release? Should it clear every restriction from the device? Or only those that where issued by the user in the latest !who? I believe both should be made possible (but in a way that won't make the older relays go wrong... Should, in this case, a pratial release be ignored or be interpreted as a full release?).

If we can agree on a good spec, I'll try to help you pushing it into the official protocol ^^. Anyway I put this in the TODO list of my multi-relay. :--Satomi Ahn 16:30, 19 February 2009 (UTC)

I am sorry I am not sure whether I understand you correctly: On the one hand you are talking about a multi-device relay and on the other hand you are talking about multiple doms controlling the same device. !release must be implemented on a per device basis. Imagine you are locked up in a cell. Someone griever could simply free you with an attachment that sends !release otherwise, so spoiling all the fun.

For multiple persons controlling the same device, I think the last one should override older settings. It gets way to complicated to understand my non-coders otherwise. The world object should check whether it allows access by another person or not. And the relay can ask the user if she trust the new dom or not.

We have to keep in mind that !who can be easily faked by untrusted world objects. --Maike Short 18:36, 19 February 2009 (UTC)

Ok, I admit what I have in mind is quite complicated. I was thinking of considering a single device as several virtual devices when controlled by several doms (no risk of faking: if the command comes from another real device, of course I don't want it to allow releasing the commands from another one!). But even without going that far, it would make sense, if restrictions come from several doms on a single device, that in certain cases (to be determined by the device maker), only the restrictions coming from one dom would be cleared. --Satomi Ahn 22:05, 19 February 2009 (UTC)

We are only !release'ing by object, not by person. We COULD say "release everything this person has" when they !release one... but that's not very .. er.. realistic... if they have you locked in multiple restrictions (a device in a cage for instance), they can only undo you one-at-a-time... and for the !who being faked.. yes it could be, but a) you have to have an object with the !who command (by default) so you would have to be able to fake the UUID of an object that has you actively controlled and the UUID of a person... --Ilana Debevec 23:51, 19 February 2009 (UTC)

Other point of discussion: when a bunch of commands prefixed by a !who have been ok'ed, should the device assume that every following bunch of commands from the same user will also be accepted? --Satomi Ahn 14:35, 23 February 2009 (UTC)

No, it cannot. Some people do not like to be tpto-ed away or stripped and therefore reject those commands. --Maike Short 20:21, 23 February 2009 (UTC)

I don't understand your point. How can you know the next bunch of commands from the same user will tpto you or strip you? Is it because the previous bunch had an unpleasant result? Oh.. or maybe you say that some ppl block every srip or tp command? Ok... but that's not the issue I wanted to point to (and this precisely is not really an issue!). The problem would be if you accepted @behav=n commands and then, later, refused the @behav=y.--Satomi Ahn 22:10, 23 February 2009 (UTC)

If no, the device should take care of eventually releasing every restriction in a non-prefixed command (which should work, provided the relay keeps the order of execution for commands issued by a same device).

If yes, this makes the relay more complicated, as you have to keep in memory the fact that a user still has restrictions on the wearer. Then either you allow only one user per device to lock the relay (as older relays did for devices: only one device using a relay at a time), or you have to do some very complicated bookkeeping for users, similar as what you do for devices in multidevices-relay (which would give an over-kill, over-bloated, multi-device and multi-user relay!).

Well, what is your opinion on this? --Satomi Ahn 14:35, 23 February 2009 (UTC)

I strongly advocate only to keep track of one user per device. Things get really complicated if different users have their own restrictions. And I thing that is not how the real world works. Sure, there can be two locks on a door with multi device support. But a second persons operating the same lock as the first person with a completely independent set of restrictions is strange. In the rare case this is really desired, the object can use a second prim or do the book keeping itself. Which is a good idea anyway so that the second person can see the restrictions of the first one.--Maike Short 20:21, 23 February 2009 (UTC)

Apart from that, I think !who should only be send as first command or on change, but not prefix every command. --Maike Short 20:21, 23 February 2009 (UTC)

This is not what the current spec says, but why not. In that case, we should also have a "!who/NULL_KEY" which says that from now on the commands do not come from a user. I believe we need at least that the final !release does not belong to a user (who could have been ko'ed). --Satomi Ahn 22:10, 23 February 2009 (UTC)

Oh and, btw, the answer was in the proposal: a new ask dialog can pop up at every new !who that is different from the latest, which is equivalent to have only one user at a time.--Satomi Ahn 22:13, 23 February 2009 (UTC)