Proposal: new flag-llike command to implement relay filtering on folders
Problem: In #RLV, you often have two kinds of folders. Folders which represent a full outfit, and folders which just contain a (set of) accessories (cuffs, gags, blindfolds, etc). When using in-world devices such as transformation machines, wands, etc, that pick up a random sub-folder in your #RLV folder to force-wear it on your avatar, you may find yourself in a real mess if the folder that is picked up is an accessories folders (for example, in my #RLV/ folder, I put all my accessories inside sub-folders of #RLV/Accessories/. When a device force-wears #RLV/Accessories on my Av, I get in real troubles with dozens of cuffs, gags, blindfolds and whatnot force-worn on my Av, often with SL's asset server failing to rez half of them and forcing me to relog).
Need: we need a way to still allow access to accessories sub-folders to device that pertain to us, but to filter out these folders (and all commands that attempt to access these folders) for external devices.
Proposed solution: I though about flagging the folders I didn't want accessed by external devices in the same way as "nostrip" folders. Since external devices must all use a relay, I propose that any folder with "norelay" in its name be protected from relayed commands.
I first implemented the access filtering in my RestrainedLove relay, simply not relaying any "@bevah:folder_name (norelay)=force" command. But the problem is that commands such as @getinv can't have their replies filtered by the relay (the reply being directly sent to the relayed device), so you may still see an external device attempting to force-wear a "norelay" folder (since the folder is still listed in @getinv replies); while the relay will block the force-attach command, it's no fun since nothing happens (when other folders listed by @getinv could have been force-worn instead).
The only solution is to have RLV itself distinguish between relayed and non-relayed commands and act accordingly.
I propose that a new @relayed "command" (it's actually a modifier/flag) be implemented, that would be used by relays to indicate to the viewer that the command(s) that immediately follow (in the same group, example: @relayed,attach:blahlah=force) are in fact relayed commands.
On receiving a group of commands starting with @relayed, the viewer then just has to position an internal flag and filter out any use/result dealing with folders which name or path contains "norelay". On completion of the command group, the internal flag is reset (meaning that a @relayed sent alone (in a llOwnerSay()) won't affect any command following it).
On the relays side, it's simply a matter of pre-pending any relayed command with @relayed (for example "Attach:blah=force" is sent as "@relayed,attach:blah=force), so while it will need a change in all existing relays to take benefit of this new protection scheme, the change is very minor and straightforward. The relay will not even need any more to filter out by itself commands containing references to "norelay" folders (this will be done viewer side).
Note that I got such an implementation ready for the Cool VL Viewer and the Cool Hud RLV relay.