Blacklist

[Marine Kelley]

Hi !

During the last meeting, the recurring subject was about a "RLV command blacklist", i.e. a way for the user to block potentially fun-breaking RLV commands in advance. For example, some users are very much against having their IMs blocked either way. Others are very much against having their inventory locked away.

As of now there are two ways to prevent a RLV command from being executed at all :

• Use an out-of-date RLV which doesn't know the command (for example, pre-2.2 doesn't know anything about locking folders).
• Use a non-RLV viewer.

In other words, if the version is high enough, a script can expect a command to be executed without conditions. This discussion is about adding a way for the user to fine-grain control which commands are accepted by their RLV and which one are to be ignored.

Before entering into ideological debates, let me detail what a good implementation should look like :

• A new "status" command so the script knows what to expect up front. Possibly a part of @getversionnum (after a comma, perhaps) or even @getversion (once again after a comma). After all, the script knows what it is up against the moment the RLV replies with its version number.

• Any refused (blacklisted) command should give a feedback as a notification so the script is not left in the dark. Accepted commands already give feedback through a notification anyway, so that only makes sense.

• Blacklists should be easy to modify by the user, perhaps in the debug settings, but NOT updated at run-time. The user should not be able to revoke a restriction after it has been applied, unless they relog. Or else there is no point in issuing restrictions at all.

• Informational commands ("@get*") should not be blacklistable, they are not fun-breaking, the user actually don't even see them, and they are necessary for a script to work.

Now on to the ideological part :

I am a strong advocate for NOT adding any more workload upon scripters and their scripts (especially those which creators are no longer in SL), so I believe that "blacklistable" commands should be the ones a script actually does NOT care about.

If all commands were blacklistable, then if a critical command is issued by a script it would have to do this :

{{{ #!pseudocode

Issue_command() IF command_is_accepted() THEN do_stuff() ELSE do_something_else() ENDIF

}}}

This would add a lot more work on the scripters, for very little gain for the user since I think most won't use blacklists anyway.

As of now, some commands make the user do things (strip, for example, or sit somewhere), or prevent them from doing things (stand up, teleport). There are commands that are necessary for the script to work well (if the object is undetachable, the script should not have to check the attach() event, if the user is prevented from teleporting, the script should not have to check that they are online and not there, etc).

Some commands are like dead-ends, they act upon the viewer by preventing from doing something in particular, but have little meaning for scripts.

For example, since IMs are out of reach from a script (as they are meant to be), issuing "@sendim" has no impact on the script itself, it just impacts the user. Therefore @sendim is blacklistable (and will be blacklisted by some).

On the other hand, in a combat sim, players are very much expected to NOT be able to run or fly. In cages, prisoners are very much expected to NOT be able to teleport out or sit far. These should not be blacklistable, in my opinion.

What do YOU think ?

[Satomi Ahn]

A command for announcing up front what commands are blacklisted should be enough to address all the problems (even if all commands are blacklistable). Scripts would just have to do one verification at the beginning, then work as usual provided all necessary commands are accepted (and act appropriately in the other case).

Other point (maybe obvious): the blacklist should not be modifiable while restricted (or while under a special restriction added for that purpose, like "@modifyblacklist=n").

[Alan Glover]

I've been letting this one rattle around my brain for a while before commenting...

I'm coming down in a similar position to Satomi... there should be a way to retrieve the blacklisted commands, and that the blacklist should be something that is intentionally hard to modify, ie it's only read once during login (preferably at login rather than startup to avoid creating another quit-the-viewer-and-reload-it scenario). Therefore, it's best done as a debug/configuration setting.

I don't believe there should be any other changes in the semantics. Now, for example, there's no feedback if a RLV command unknown to the viewer is attempted and RLV has always tolerated the setting of restrictions that it doesn't understand. Given the event driven nature of LSL coding introducing an ack for each RLV command (accepted, blacklisted or unknown) would involve more complexity in the scripts and is unlikely to be adopted by any but the most paranoid coders who aren't worried about free space in their scripts. It would also have implications towards the relay protocol too.

I am not in favour of it being an extension on an existing @version(xx) though - the version strings with version/versionnew can already get quite long with some TPVs where the viewer version, API version and RLVa version all appear, and adding it on versionnum is sure to break someone's code that tries to parse the API number out of the response.

In addition, @version(xx) returns constant information and a blacklist is dynamic - there should be a new @get... command, eg @getblacklist, to return the blacklisted commands. The return should be similar to getstatus, including the proposed specifiable separator to allow for someone who might want to protect parts of their #RLV (ie / appearing in the blacklist as a folder separator).

Having a blacklist at all does raise some philosophical questions... that prompts one other suggestion here -- at the moment @version in an IM can be used as a quick check for someone really running RLV. Perhaps also @getblacklist should be permitted by IM too so that someone playing with a person using the blacklist can see what they aren't going to be able to apply by RLV.

I see the argument in favour of some commands not being blacklistable, but also think that is probably getting into too much detail. I favour a simpler implementation where anything could be blacklisted and if someone blocks a command that stops a toy working (eg something in the @get... hierarchy) that's their problem. Similarly if someone sets their blacklist so that cages become escapable that is ultimately up to the person concerned and whether the person they're playing with considers it legitimate or cheating.

Implementation note... since some commands are multifunction depending on their right hand parameter, eg detach:blah=n and detach:blah=force the blacklist needs to include storage of =n/=add/=force as well as fragments which match anything they are a substring of.

[Marine Kelley]

You make very good points here. To me the "@get..." commands should not be blacklistable at all, since they don't hinder the user's abilities, they are done silently. I also presume it would be easier to let any other command be blacklistable, perhaps even "@detach=n", who knows. As long as the script knows it, and as you mentioned, it can be checked in IM as well (good idea here).

As far as not including the blacklist inside the "@version" command, I still think it is a good idea. Agreed the response is already long, but you are limited to 1023 chars anyway, and I don't want to force the scripts to make TWO events in sequence to check both the version and the blacklist.

As for your sentence "preferably at login rather than startup to avoid creating another quit-the-viewer-and-reload-it scenario"... I must confess I did not understand that. Can you elaborate please ?

[Alan Glover]

Hi, I hope this will be clearer.. :)

When you change some debug settings, eg RestrainedLove for whether RLV support is on or off, the viewer has to be closed down and restarted because the setting is only read when the viewer first starts up. Unless the user has the presence of mind to make the change before they log out of their current session, they have to log out, start the viewer, make the change, quit the viewer, start it again, then log in.

If the blacklist setting was read when starting login instead of when the viewer starts those intermediate steps of change the setting, quit the viewer, restart the viewer could be avoided.

I agree that turning RLV on or off in toto is a major change and justifies forcing the viewer to be quit and restarted. I don't think a blacklist edit before login would be such a major thing. I do agree that the blacklist settings should be read once and remain applied for the duration of this login even if changed during the session.

I would still prefer to see the blacklist in its own get... command though. 1023 characters can get eaten quite fast if some #rlv folder paths are involved and something like "RestrainedLove viewer v2.7.0 (Firestorm 3.0.1.22566 - RLVa 1.4.0)" already takes a chunk out of that total.

I believe that version(new) has been out there too long now to introduce a structured syntax to it. Even the Firestorm example above and "RestrainedLife viewer v2.07.04.02 (3.2.3.21649)" have enough subtle differences to make a reliable parser difficult to do. Nowadays I use versionnum to get absolute data and version(new) as something to show the user of the script rather than carrying useful data for a script (aside from checking for the viewer family by substring search sometimes)

I'd also like to have the flexibility that getstatus(all) has to call it with eg getblacklist:tp to check for specific blacklisted restrictions/substrings that appear in specific blacklisted items.

[Former user]

 - Any refused (blacklisted) command should give a feedback as a notification so the script is not left in the dark. Accepted commands already give feedback through a notification anyway, so that only makes sense.

If you mean that a blacklisted command shall report via @notify like if the command was executed, then I agree with you (this is how it is implemented already in the Cool VL Viewer). I however disagree if you mean that the viewer shall report a "ko" status via notify on blacklisted commands, since it would confuse (and probably break) existing scripts that look for a @notify reply to a command before taking the next step. A possibility to get the best out of both worlds, would be to add a @newnotify command that would report both successes (command accepted and executed) and failures (command blacklisted).

- Blacklists should be easy to modify by the user, perhaps in the debug settings, but NOT updated at run-time. The user should not be able to revoke a restriction after it has been applied, unless they relog. Or else there is no point in issuing restrictions at all.

100% agreed, and that's how it is implemented in the coming release of the Cool VL Viewer. I also made 3 default profiles for users to select from: a "Persona-player" profile (for persons not making an IC/OOC distinction) with an empty blacklist, a role-player profile (for players not wanting to be restricted themselves (OOC) but agreeing on seeing their avatar ICly restricted) with all OOC restrictions blacklisted, and a "Vanilla" profile (for non-BDSM people) with all restricting commands blacklisted.

- Informational commands ("@get*") should not be blacklistable, they are not fun-breaking, the user actually don't even see them, and they are necessary for a script to work.

Agreed. I also don't allow restricting some essential or non-BDSM commands, namely: @notify, @clear, @detachme, @setrot, @adjustheight, @emote, @findfolder, and of course @version*.

I am a strong advocate for NOT adding any more workload upon scripters and their scripts (especially those which creators are no longer in SL), so I believe that "blacklistable" commands should be the ones a script actually does NOT care about. .../... On the other hand, in a combat sim, players are very much expected to NOT be able to run or fly. In cages, prisoners are very much expected to NOT be able to teleport out or sit far. These should not be blacklistable, in my opinion.

I disagree, here... For example, non-BDSM people who are using RestrainedLove for purposes such as using it for outfit management (wearing/removal via a HUD, for example), or with a teleporter, or for an emoter (redirchat/emote), really DO NOT want to get restricted in any other way in what they can do or not with their viewer. Such people shall of course expect to see BDSM-biased scripted items to stop working as intended if they use them with a non-BDSM RestrainedLove profile. This is not an issue the scripter of the said BDSM items should care about (at worst, all they have to do, is to mention in their documentation what minimal features their item requires in a RestrainedLove viewer, and they could even check the said requirements from their script with a "@getcommand" command).

The next Cool VL Viewer release will provide @getcommand[:partial_name_match]=channel as a way to check for supported (and not currently blacklisted) commands. For now, this @getcommand is compatible with RLVa's, but it also could do better (it's just a matter of changing a #define in my code), by providing a mean to distinguish between "force" versions and "add/rem" versions of commands; for example, for a vanilla user, I blacklist @setgroup=add/rem, but not @setgroup:group=force. So I can make it so that @getcommand:setgroup=channel returns "setgroup" (for @setgroup=add/rem) and/or "setgroup%f" (for @setgroup:group=force) depending on which is/are not blacklisted.

Henri.

[Former user]

Blacklist implemented in Cool VL Viewer v1.26.0.28 and v1.26.2.6.

See this http://sldev.free.fr/forum/viewtopic.php?f=7&t=646&p=2740#p2740 for the implementation details and screen shots.

Henri.

[Marine Kelley]

Ok, so I've read Henri's forum page attentively and this seems like a good implementation (except that I won't include profiles myself, I like simplicity and additional commands in future versions would require to think about what profiles these new commands should be part of).

So I'm going to start working on the blacklist now and implement it this way :

• RestrainedLoveBlacklist is a new debug setting, responsible for holding the list of ignored RLV commands. Tokens in this list are separated by commas (','), and the user can add a "%f" suffix for "force" commands in order to distinguish them from their "=n" counterparts. Attention, this list does NOT contain wildcards. In order to blacklist a command, this command must be written entirely.

• This debug setting will be read at startup and a modification to it will require a restart.

• The new @getblacklist[:partial_command_name]=2222 command will retrieve the blacklist, filtered by the option if any. For example, @getblacklist:tp=2222 will respond with sittp, tploc and tplure if those 3 are in the blacklist.

• @getblacklist[:partial_command_name] will also be a built-in recognized IM just like @version, so that anyone can send this IM to a RLV to enquire about the blacklist it currently holds. Just like @version, this command won't trigger any feedback to the user who receives this IM, they won't see anything.

• @versionnumbl=2222 will be a new RLV request for both the version number of the RLV API that this viewer implements, and the blacklist itself after the number and a comma. For example, @versionnumbl=2222 would respond something like "2080000,sendim,recvim,sendim_sec,recvim_sec". Normally, @versionnum would have worked for that purpose too, since scripts would generally check its result against a number, by doing this in a script :

if (minimal_version <= (integer)result_from_versionnum)  {
  do_stuff();
}
else {
  complain_that_the_viewer_is_not_recent_enough();
}

And in LSL, casting a string to an integer will cast all the digits from index 0, up to the first character that is not a digit. So here (integer)"2080000,sendim,recvim" gives 2080000. However (integer)"2080000,1" also gives 2080000. In other words, anything after the comma in @versionnum would be discarded when casting to an integer.

• There will be no special notification when a command is blacklisted, the RLV will send an acknowledgement if a notification for this command is active. To know if a command is actually accepted, a script must have sent a request to the RLV through @getblacklist or @versionnumbl first.

[Marine Kelley]

Implemented in 2.8.

I'd really like to change @versionnum, to include the blacklist as well, but for now it behaves as it always has. So that change would be for later.

[Marine Kelley]

So I got fussed at by the very proponents of the blacklist from the meeting. This was totally unexpected. If there is so much concern about it, let's discuss it here. I am reopening this issue just for this.

Feel free to state your mind here.

[Former user]

I was involved in this discussion, except from what I hears on the channel afterwards. So when I was invited to add my two cents I did a little reading.

The black list, when I first heard it mention, I thought was against user UUIDs, which I am a supporter of. However.. It seems to be some way of watering RLV down, so that the people using it can make grandiose claims that they only want X feature. Well, erm, we have that, its called scripting. It appears to me, that people are trying to shift the blame for RLV abuse from the scripters who make poor code, to the API maker.

There was already one public abuse of RLV trust, in the case of Dahlia's relay, vs the user. And in instances such as these, where there is quite clearly someone abusing the trust of its users, we should name and shame THEM, not water the API down. It's quite possible to have a wardrobe hud, for example, that does what it needs to, without the fear of random stripping such as a relay would offer. So why add the new features for people to pick and choose, when such is already there in the script level?

I am not really supporting, or berating the move, its just one that doesn't make sense to me. Since the script doing the job of sending RLV commands is more than capable of doing so already. I mean, isn't that why the relay was coded?... To allow things to interact and apply restrictions, and if you didn't want it, you didn't wear one? o.O

[Marine Kelley]

First and foremost, let me say for the record that I am personally against the very idea of a blacklist. In my opinion the RLV should be all-or-nothing, but I can understand the need for blocking certain heavy restrictions. I added it to the spec because of this, because I want the RLV to get rid of its sticky "kinky" label.

The main reason for adding a blacklist is that a lot of people want to use this feature and that feature from the RLV, without fearing to be "abused" one way or another by other features they don't want. Granted, scripts should watch themselves but we all know that's not always possible. A lot of people still use a variation of my basic relay, which does not handle any internal blacklist, so they are "vulnerable" to abuse.

Besides the relay is one concern, but wearing restraints without wanting ALL of their features is another.

Let's take an example. A BDSM player wants to use a lot of different restraints, but doesn't want to ever have her IMs restricted. By accident, she gets gagged and her IMs are restricted, breaking her fun and forcing her to relog (twice) to get rid of that restriction and get back to normal. In the long run, she stops using gags since she's always weary of having her IMs restricted. A blacklist would help her there.

Oh, and I'm not sure this is "watering the API down", since a user who plays with 2.6 will in effect be exactly like a user who plays with 2.8, with "@temprun" blacklisted. Scripts DO have to check the version anyway, the blacklist is technically a variation on the same theme.

Lastly, I said it is in the spec. I have added it today but I can remove it, if it pisses off too many people. I'm not here to make the scripter's work harder, but easier and more fun. Same for the user. If the blacklist overcomplicates things, it will have to go.

I wish there was a vote feature here in Bitbucket.

[Alan Glover]

I'm "for" the feature, and don't believe the work for scripters is that much either. A toy queries the blacklist when it first acquires a target and at that point can refuse to engage if anything it relies on is blacklisted, otherwise it simply continues as-is applying restrictions and not knowing/caring some restrictions it applies happen to get blacklisted.

The IM example is one of the the best. Someone might be responsible for customer support, or have a role in some vanilla organisation, either of which can generate IM traffic or Group IM traffic at any moment. Finding IMs have got unexpectedly blocked is inconvenient and embarrassing and risks jeopardising the professional relationship with the people who expect an on-call response at any time.

Another example is playing HUD-based games such as Tiny Empires. Is the purpose of a BDSM toy to stop someone playing a game in their HUD for the quiet times? Yet, some RLV restrictions do so (eg detach of hud items, hiding hud hovertext). Are these critical to the toy's proper function? No. Does playing a game in the hud invalidate the participation in whatever scene the wearer is involved with? No.

I don't buy the argument that if you don't want to be IM restricted by a gag, don't wear gags. So long as a relay is being used a gag can be force worn if it exists in #RLV, a gag can be given to inventory and force worn by someone who didn't own a gag previously, or the underlying RLV restrictions can simply be applied through the relay. So you should stop wearing relays? That's too fundamental to give up on.

Should the relay handle this? It could, but let's come back to one of the design principles of RLV. Put complexity where it is easiest to handle - that's in the viewer, not in scripts. Relays should be fast and simple. Handling it in the relay only addresses half the picture anyway - items owned and worned by the av communicate directly with the viewer.

It's not as simple as saying 'so don't get gagged'. Any toy with an isolation element might choose to block IMs. Do you avoid all those too? A capture device might block IMs during capture. Do you turn off your relay to stop being captured? A maze might block IMs. Do you avoid all mazes? Someone using a control ring might click the button to block IMs. Do you stop wearing any control ring?

Not having the blacklist, keeping RLV as all-or-nothing, forces those who have to avoid some features of RLV into a situation where they either have to hope people read warnings in profiles (like that ever happens, and what about restriction sets being applied by a device rather than a person) or go around with their relay off or RLV itself unused.

Customers expect customer support. While some might be amused that the support agent is themselves RLV restricted if they understand what's going on, it doesn't get them any closer to having their issue solved and it makes the support operation for the product seem amateur and unprofessional. Ultimately, it loses customers as they either don't understand and go to a more responsive supplier or do understand and consider that the support team wants to enjoy their own RLV fun more than helping other people.

Let's take a step back from the people and politics here. Using RLV should be about enjoyment. Not having the blacklist prevents some people from enjoying RLV, forcing them to safeword out of scenes and get restrictions they can't work with lifted as soon as possible.

Within B D S M there are limits that consenting players agree and accept. RL B D S M is not all or nothing. Consensual is a key word. Having the blacklist allows the same consensual play whilst using RLV. Just as someone might say 'I don't do water sports' they should also be able to say never block my IMs and enjoy the rest of the experience without risk of it happening.

Vote: For.

[Satomi Ahn]

Wow, this was a long discussion and now I have the feeling of coming after the battle (although I did give my 2 cents at its beginning).

There is a point I believe was not mentioned. Being able to query the blacklist is useful. Having a command to query what actually works would be both useful AND practical.

Indeed I have mixed feelings about @versionnumbl, since it means that you have to have the changelog of RLV API next to you when you write a script which checks what commands are supported (not being in the blacklist is not sufficient: you have to verify the command actually exists in this version of the API).

Why not go the easy way and implement something like @getavailablecommands[:partial_command_name]=2222 instead?

[Alan Glover]

@Satomi - querying the capabilities seems orthogonal to this, although I agree there could be a tristate return - known, unknown or blacklisted (whether known or not)

This is getting off of the blacklist topic so maybe needs spinning out into another Issue ID...

I am starting to come around to the view that some sort of capabilities mechanism is`needed because it is becoming the case that the RLV API number doesn't solely determine what a particular viewer does or does not include. The RLV API number sets the minimum coverage of the viewer but it's seeming now that other viewer maintainers are adding extra commands, whether it's as part of an alternative blacklist implementation (eg Henri's) or anything else.

There's an issue brewing here about how rigid the RLV API is or should be. It's one thing to say that returning a certain RLV API number means that all commands to that API level are implemented, but does it, or should it mean that no other commands exist either. If the answer is that other commands could exist then a capabilities mechanism is needed to expose them.

If anyone wants to follow up on this capabilities/RLV API meaning discussion, please fire up a new Issue so that this one can stay focussed on the blacklist

Technical note.. the return from the proposed @getavailablecommands=2222 would probably overflow the 1023 limit, or soon be in danger of doing so when unfiltered. Something like this should allow a single command or a list of commands to be passed in so that the query can be kept down to one command and one reply.

[Satomi Ahn]

@chorazin: I disagree about orthogonality. As I proposed it, @getavailablecommands asks for commands which will really work, i.e. implemented commands minus blacklist. So it depends on the blacklist. I did not even think about the nice side effect that it would also list commands that are not in the official API.

The philosophy behind my proposal was to answer the question "what do we actually need to know?". The answer is "we need to know whether commands I want to send will actually be executed". Getting the full list of all implemented commands would achieve no purpose (if not combined to knowledge of the blacklist, to achieve the same result at greater cost).

Maybe an even more direct approach which would also get around the message size issue would be @getwilltheywork:<list_of_commands>=2222, the answer of which would be a vector of "0" and "1". The list of commands would only contain commands you actually need in this script, which is less likely to overflow the size limit. Maybe the answer could even be a vector of "0", "1" and "2" ("2" being for blacklisted).

By the way @getblacklist could also overflow the limit. This is not a problem which is specific to @getavailablecommands.

[Marine Kelley]

I like that idea. A script only needs to know about the commands it will actually use, so in a way, getting the version (for < 2.8) and the list of commands that works among the ones the script will use, should be enough. It's elegant because it wouldn't overflow at all. Whether to use indices like Satomi described or command names is personal preference for the scripter, but in the end this information is more useful because it is a list of capabilities. The script does not care much about what the RLV can't do, it cares about what it can do. Conceptually that's better.

[Satomi Ahn]

The use of indices has another advantage: it is extensible. Currently there are 3 useful values:

0: works 1: not implemented 2: blacklisted

But we can already propose 0: works 1: not implemented 2: blacklisted 3-e: reserved for future extensions f: won't work for another reason than 1-e

This code uses hexadecimal since it will make it easier to analyze the reply by applying bitmasks to the expression (integer)("0x"+viewerReply).

Also "0"/FALSE means "working" and non-"0" means non-working because it makes it possible, in a first approach, to use the viewer reply as cast to a single boolean, if you do not care about precise reasons something won't work:

if ((integer) viewerReply) DoNotify("Not working");
else StartRlvProcess();

But if we keep only 2 values, it's also fine to me: what really matters is knowing what will work.

[Marine Kelley]

0 means working ?! Eek ! The C ! It burns !!

Joking aside, I understand what you mean but it is contrary to the rest of the commands that send series of 0 and 1. Usually 0 means absent and 1 means present, so in order to stay consistent I advocate for making it this way :

• 0 : Command not supported
• 1 : Command accepted
• 2 : Command supported but blacklisted (so in practice, not supported)
• 3+ : Reserved

That way your example becomes :

if ((integer) viewerReply == 1) StartRlvProcess();
else DoNotify("Not working");

This code resembles a lot more the standard

if (NominalCase) ExecuteNominalCase();
else HandleException();

Looks healthier to me.

On a side note, this command would validate Henri and Kitty's @getcommand (maybe in a different way but the idea is the same), so I think it goes in the right direction.

[Satomi Ahn]

Yes 0 = working is counter-intuitive, I don't like this either ;). Problem is that doing it the other way removes the possibility of casting the whole string directly to a single boolean with a 1-to-1 correspondence working->one state, not-working->the other state.

But I am only throwing ideas anyway, hoping the best compromise will come out of this discussion ;).

[Marine Kelley]

The problem is that this approach (the C approach) allows only one reason for success, and N reasons for failure. But you could want to precise why a command is accepted, and maybe also to what extent (maybe in the future someone will need a "this command works but will be cleared when situation X occurs"). So if we need a "it's working because" and "it's not working because", the value 0 ceases to have a particular meaning. (*)

Besides, most SL scripters learnt to to program in SL, the majority of the rest were into Java, VB and Python before trying LSL, very few were into C (cause it's too kinky, y'know). That's why making 0 the value for success makes little sense to most people.

(*) If we go that route, then the digit solution is not really adequate, a better solution would be this :

• Request : "@getworkingcommands:showloc|shownames|detachallthis:clothes/shoes,testcommand=2222"
• Response on channel 2222 : "showloc=yes,shownames=yes_but_only_for_30_minutes,detachallthis:clothes/shoes=no_blacklisted,testcommand=no_unknown_command"

Something like that. It makes it clearer and more powerful, but it does take more script memory, especially if said script is Mono. A middle ground would be nice.

[Alan Glover]

I've just been thinking about this... how about a slight tweak on the proposal thus...

Make the @getworkingcommands call as in Marine's comment above this one, but the return changes...

If all responses would be yes, an empty string is returned. This allows the script to avoid having to parse through the response where in fact it doesn't need to prepare for any evasive action because every command it asked about is going to work. Parsing through an all yes response string would be a waste of the scripts processing time.

If any responses are no, a reply as in Marine's example is sent, including individual yes replies where they occur - this preserves the direct correspondence between the order of commands in the query and in the reply.

As for optimising the response, perhaps it only returns reason code numbers. That'll make it much shorter and there could either be another new command to query one reason code number or one to get the whole list. Alternatively, the reason codes will be detailed in the API, so having a runtime way of obtaining the textual meaning is optional anyway. (The precedent already exists for returning numbers alone - @getinvworn)

The issue about 0 meaning success can be avoided by semantics in the definition. If the command is documented as returning failure reasons for commands then 0 will mean that there will not be a failure whilst all other numbers mean there will be some sort of failure if the command is tried. Against that way of describing the command having an 0 return for a command that will succeed makes sense.

Now, at the risk of opening up another area for debate, how dynamic should the return data be? Should it be session based, ie only influenced by the blacklist, or should it be truly dynamic including return codes to mean a command is not possible right now because of some other restriction that's in effect. Personally, I feel that's probably a step too far, though it was hinted at by Marine's yes-but-only-for-30-minutes example which sparked this line of thought.

Note: the | separators in the example will have to be something else - using | would cause problems for this command in the relay protocol.

[Marine Kelley]

If all responses would be yes, an empty string is returned.

I'm not sure about that. To me, the response should always be consistent, hence include all the requested commands, even those which are accepted. My idea would be that the script queries the RLV on rez (or attach), just like it queries its version (hence my idea for @versionnumbl, which allows you to kill two birds with one stone, by querying both the version and the blacklist), and retain the response for later. Then, every time the RLV restrictions are to be updated (I personally do it in one function that I call whenever a change to the restrictions occurs in the script), just call a llSubStringIndex(query_response, "showloc=yes") and if the result is not -1, you're good to go. More processing time, maybe, but RLV restrictions do not change every tenth of a second, and this function is lightning fast on Mono.

As for optimising the response, perhaps it only returns reason code numbers.

Of course. Nobody wants long strings.

Now, at the risk of opening up another area for debate, how dynamic should the return data be? Should it be session based, ie only influenced by the blacklist, or should it be truly dynamic including return codes to mean a command is not possible right now because of some other restriction that's in effect. Personally, I feel that's probably a step too far, though it was hinted at by Marine's yes-but-only-for-30-minutes example which sparked this line of thought.

Oh it was totally a stretch, only to point out that there is no reason why we should have failure reasons, but not success reasons and conditions. The "30 minutes" one was just a silly example, I really have no clue what kind of success reason we could take into account yet. Nor if that's even needed in the first place.

Note: the | separators in the example will have to be something else - using | would cause problems for this command in the relay protocol.

Agreed. I didn't spend much time selecting a separator for this simple example.

[Satomi Ahn]

I was also seeing this as the kind of command you would send at the beginning of a session (rez time for worn devices, relay grab time for relay controlling furniture), so it was essentially for querying "static" reasons.

More dynamical aspects can have some uses but will never be 100% reliable (for instance, teleporting may fail for many reasons beyond the knowledge of the viewer). For those, the best practice is still to control the result of a command after it is issued, either with pure LSL, with a @get command after a delay, or using @notify.

Remark: yet another advantage of sequences of single digits: they do not need separators.

[Former user]

To be honest I think this is getting over complicated.

I have no problem with the blacklist, I won't use it myself.

I Know that when the strip command came out relays put in an option to ignore it.

To be honest I wont even check if my commands will work, If they have been blacklisted, then the toy is not for the victim.

The only thing I check for is a cheat out, so I can release the toy for use by someone else, eg: your online but not in the cage "CHEAT"., unlock cage.

So no objections to the blacklist, but i wont use it, i'm not going to modify my stuff on the reulsts from it