@putinv

Hi there,

Sorry for staying silent for so long, I have been working at ironing out a few bugs in the viewer that I had overlooked until now (thanks to Kitty Barnett who made an outstanding job at tracking them down), and also thinking hard about the @putinv command. This is what this post will be about.

What exactly is @putinv ? It is a command that allows one to give you a folder, which would be automatically be put into your #RLV folder without you having to move it manually (sometimes you can't even do that if you don't have access to your inventory anyway). It can be very useful for places that must transform you one way or another, or even just furnitures that need to give you cuffs to work. Problem is, shared folders are based on the principle that whatever is shared is done so *voluntarily* by the user. What is not shared is out of the scope. Plain and simple. @putinv violates this principle in more than one way.

So let me explain my point of view about this command : it is a *dangerous*, but *very nice feature* to have. I do want it into the viewer, but am very cautious about its implementation. Despite my relative silence, I have been lurking all the forums and watching all the discussions about it for some time, one day deciding not to implement it then changing my mind the day after. This one was a real roller-coaster. At the time of this writing (but I am pretty much decided by now), I want to implement it for the next version, but with a lot of safety guards to avoid serious griefing.

Now why exactly is it dangerous ? What in the world could happen ? Well let's say I make an object that locks itself on you after I give it to you and sends outrageous particles around (racist, pornographic, you name it), then you would be tagged as a griefer while you would actually be a victim. And no way you could defend yourself, the Lindens are well known in the "shoot first, ask questions later" community.

So we need safeties. @putinv is a command that acts as a "whitelist", to filter out all rogue inventory offers in the first place and only accept to put into #RLV/whatever the offers coming from objects owned by the avatar specified into the UUID part of the command. And this safety is... pointless. Basically an object that is not owned by the user is allowing itself (through their relay) to mess with their #RLV folder. The only use I see into this command is to prevent someone in another sim from sending inventory that way. If I find a way to check that the inventory offer comes from the same sim, @putinv will have no point anymore. There has been a discussion about preventing @putinv from being accepted if it comes from an object contained into the "drop box" (more on that later), but it would not work either. The object can just use the relay channel to work around this restriction. So in my opinion, the whole feature of "dropping directly into #RLV" does not need a command like @putinv as a safety check, because it would be easy to fool.

Where does this lead us ? Actually the core part of the feature is not @putinv (which is just a safety check) but the inventory redirection itself. When a script calls llGiveInventoryList with a "#RLV/~"-like path (as Henri suggested), the folder does not go to "My Inventory" but to "#RLV/~blahblah". This is a "drop box" in which would go all folders given through that technique. A drop box is necessary because the user does not want their shared root to be cluttered with obsolete folders they didn't even put there themselves. It is also necessary because it is a check in itself : no drop box, no redirection.

The inventory offer must also trigger the dialog box with the Accept/Decline/Mute buttons. I have thought about it through and through, I don't see a safe way to go without it. While the dialog is showing, the folder will have a special character added to its name (yes, another special character I know), to tag it as "do not allow me to be worn yet". Because you know that the folder is already in the inventory while the user has not accepted it yet. It would be moved to the trash should the user press Decline or Mute, but there is a short moment during which the folder is ready and waiting, even if it has not been accepted. Only when the user presses Accept will the special character be removed, rendering the folder totally available for wearing.

Yet another special character could also be used in the name of the folder (oh yeah), this time added by the maker of the object which gave the folder, in order to automatically wear it once Accepted. Just a nice addition to simplify the scripts a little, since most of the time this folder will be worn right away anyway.

The "drop box" (name pending) would be created by the user and not by the viewer itself, very much like #RLV. Sub-folders would be created automatically though, if the drop box exists. By creating it the user will acknowledge that they are to be wary of all inventory offers which name begins with "#RLV/~" because they will be worn automatically. A lot of communication needs to be done about that step, which is crucial to the whole automatic inventory sharing feature.


So to recap :

* @putinv might not even be necessary if I find a way to check the inventory comes from the same sim.
* The name provided in llGiveInventoryList is all we need to know what to do with the folder and where to put it.
* Creating the drop box would be a manual step the user has to take. Using a debug setting would have given the same result, but would be harder and less intuitive for the user. And would be machine-dependent.
* Folders would go into that drop box only.
* Folders would not be wearable until the user has Accepted the inventory offer.
* Pressing Mute would mute the object and trash the folder even if @shownames is active (hiding the name on the dialog box).
* The inventory offer dialog box is necessary. Without it many things could happen behind the scenes, without anybody noticing anything. This would open the door to "worm-like" objects. Remember : to the Lindens, the user is responsible for accepting and using inventory items. Being forced to do so by a custom viewer like the RLV is no excuse.
* While I like Henri's idea of rejecting @putinv commands issued from objects contained into the drop box (assuming I use @putinv at all), it is very easy to overcome if the user is wearing a relay. So I'm not sure I will implement that check.


Ok, so this is where I am now. If nothing comes up I should implement it soon, but as you can see this is pretty close to Henri's chosen solution. Therefore it should not be far from what he already tested in his Cool Viewer.

And last but not least, that would end this awkward situation of having a feature in another RLV which is not in mine. And this particular one is very controversial, I could have rejected it altogether if I were lazier.

Marine