LSL Protocol/Restrained Life Relay/who

This is a discussion page for adding support of the controller of an device.

!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

!who/(key)

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

Implementation

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

We are making the !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 !who on a new command from an object is the same as the last !who from the same object, no ASK necessary

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

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

Further Points of Implementation

The ASK message will change if a !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 !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)

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)