Proposal: new flag-llike command to implement relay filtering on folders

[Former user]

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.

[Former user]

And I forgot to sign... It's me, Henri Beauchamp

[Satomi Ahn]

May I suggest a slight extension of this command? (for reference, this would make it close to my proposal in issue #11).

Please allow a UUID parameter for @relayed, as this could be useful for relays handling several RLV sources without using several prims (such as my own relay, of course !).

The viewer would then interpret relayed commands with different UUIDs as commands coming from different objects/prims, thus preventing different commands interfering with each other.

• Typical case is restrictions from object A being released by a co-relayed object B, although this is something that can be dealt with at LSL level by the relay (and already is, although I would prefer if the viewer would handle this, since it already has all required mechanisms for this).
• Also the command @getstatus should report only restrictions pertaining to the object who issued it, not all restrictions of sources who used the same relay.
• @permissive=n and @xxxx_sec=n commands currently can be defeated by exceptions set by other co-relayed sources.
• Finally there are other cases where RLV behaviors do not affect (by design) the object issuing the command (unfortunately, I do not remember which... ). One does not want this exemption to still hold for other co-relayed sources.

On the side of little details to take care of: make sure an actual direct source is handled separately from a relayed source supposedly having the same UUID, as the relay could be lying to help the wearer cheating out of this source. For the same reason, if two relays were worn, either sources from the first should be handled separately from sources from the second even in case they had the same UUID, or maybe the viewer should only allow one attachment to act as a relay at a given time.

Also remark this means UUID announced by the relay only commit this relay, so maybe arbitrary strings could be allowed almost to the same effect (thus the parameter should be seen more as a "session" name). In this point of view, the mechanism could be used for different subsystems/plugins in single attachment to issue their RLV commands without interfering with each other, without even speaking of relays.

Coming back to the topic of single-prim multi-source relays: one may object that relays having several prims with an effector script in each work as well with half the hassle. But this approach is rather hacky in my opinion as it is an incentive for artificially increasing the number of prims and of scripts. Moreover, single prim relays are easier to embed in third party devices. That is why I think it would be useful if the viewer helped that kind of relay being more efficient and more accurate.

[Former user]

@Satomi

The concept of a single-prim multi-relay is flawed because RLV has been designed from the ground up to differentiate sources by their UUID. Also, this causes the multi-relay code to be much more complex than a multi-prims relay and the "advantage" of a single script against several is then mostly lost, not to mention bugs that invariably will affect more the most complex, single prim version.

The idea behind the @ralayed command is to act as a filter, not to reaffect source UUIDs (which, by the way, would then be utterly easy to use so to cheat out of devices with a custom script).

Plus, remember that since @relayed would be a new command, you would have to implement in your single-prim multi-relay the code to cope with both @relayed-aware viewers and older viewers without @ralayed available. It would only make things even more complex and cause bloat in your relay script.

I'm therefore against your proposal for the UUID parameter extension to the @relayed command.

Henri.

[Satomi Ahn]

For having detailed them at length in many posts in many places, I am well aware of the flaws of different multi-relay approaches. The purpose of my proposal is precisely to make it possible to keep advantages from both approaches (integrability and single-scriptednes from single-prim approach and unbloatedness from multi-prim approach).

As for checking whether the viewer supports this new approach is only a matter of a single test on script start-up.

Now I am also aware I am piggy-backing my own pet subject on your proposal which also has its own valid motivations which happen to be completely orthogonal to mine. It just appeared to me that the information whether current source is actually a relayed one could be use to more purposes than inventory filtering, that is why I wanted to mention it.

[Satomi Ahn]

Other improvement suggestion (this time not related to multi-sourcedness).

While the (norelay) tag makes it possible to blacklist subtrees, sometimes it is more practical to take the dual approach and whitelist a subtree instead.

For instance we could go for a #RLV/Relayed subtree to which commands prefixed by @relayed would be restricted.

However I would personally prefer a more flexible mechanism allowing to sandbox or "chroot" (like in UNIX) into an arbitrary subtree as I have the feeling not only relays could benefit from something like this (indeed, different RLV attachments have different ways of dealing with #RLV which may call for different folder organizations... and such sandboxes cannot be simulated in LSL because of @findfolder). This mechanism would be triggered by a RLV command like @setrlvroot:path (=y/n, =force ? ... ).

The latter maybe calls for a separate ticket as there are many details left to discussion (what kind of command would @setrlvroot be, how to hide and protect it from relayed sources, and so on).

[Alan Glover]

I don't support this proposal.

1) It's a problem easily avoided by any capable scripter - the means already exist to query whether a folder in #RLV has any sub-folders and when a picking a folder to force-wear the script should only choose a folder that has no sub-folders. Trying to wear too much in one go is a long standing problem and the means already exist for careful scripters to avoid provoking it.

2) Anything that involves massive upheaval of #RLV folder layouts, or requiring every single relay to be updated, is going totally against the principles of back-compatibility and ease of use. It doesn't matter how easy the change in the relay is, the assumption that every relay author is still in SL, that every relay author will update their relay, and every relay user will update their relay to a new version is flawed.

--Chorazin