Hello, and thank you for your detailed feature request regarding script loading from SL servers to clients. We appreciate the thought and effort you put into your suggestion. However, we have identified that a similar request titled 'Signed Client Scripts / Client Script Repository' already exists. To ensure all feedback and ideas are consolidated, we will be merging your post with the existing issue. You can follow any updates and further discussions on this topic here: Signed Client Scripts / Client Script Repository. Thank you for your understanding and continued support in improving Second Life.

The post that this was merged into is: https://feedback.secondlife.com/lua-viewer-alpha/p/signed-client-scripts-client-script-repository

I think this is , if client side scripts are to be installed by users. But I also can't see how it could possibly work. I also don't want this model, at all, it is most of the paths to the dark side — but the hints I've heard so far, is that it's what we're getting, so…

Lua(u) be sandboxed to make running untrusted scripts safe — it's kinda what it was made for. And, LSL does that already, all day, every day. That does come with the caveat that we won't get everything we want, but I think we know that already.

Henri's application of Lua had a "not sandboxed" mode intended for plugins; I think that kind of feature would need it's own on/off switch, and even then, I for one would flatly refuse to install on that side unless I had the time and inclination (and that's as someone who have the skill) to go through the entire script validating it for safety (also implies the code is open and readable), unless it was written by LL themselves. No amount of "good standing" (which works, any site ever with the 5-star rating system is proof of that, they get gamed, accounts get taken over, etc.) will change that. And LL would have to triple their current size just to hire a large enough team to review all the scripts if official vetting is the option you go with (and I don't see any other kind of vetting being viable).

Merged in a post from AnneiLyranae Resident:

Title: Script loading from SL servers to clients

Details: I would really like this to be more tightly integrated into the existing sl ecosystem so products can be made that use. My suggestion would be to create a new file type in sl for lua files that is basically notecards except they can be saved with an experience. If a lua file is saved with an experience and provided to a user they may choose to run that script client side and such scripts provided from server to client with a saved experience functioning as a digital signature get one more permission client side, they can read and send chat messages on all channels (not just public). Along with this I would like to see one more function added to LSL that allows a script saved in an experience to load a lua file saved with the same experience for the user. With such a system we could actually make an entirely new era of huds and other products for SL. Along with have some level of security and accountability for any bad actors.

Any client side scripts should have viewable source. It doesn't need to be modifiable in-place. ie. Cannot alter the client side script an object wants to run, but you can see and copy the source code it wants to run.

Closed source client scripting will breed distrust even if there is little apparent harm such scripts could cause. For something this different to the fundamental aspect of SL to gain traction, not feeding reasons to mistrust it would be nice. :)

I think I prefer a more repository or signed scripts style system

Where some clientside lua scripts get "approved" and scripts in sl can request that you have one of these clientside scripts installed, which the viewer could then prompt you to either install from the "repo" or accept the script becuase it is signed by LL.

This would maintain shared experience, but let people still have create custom stuff if they wish, it just has to be done manually.

I would like the clientside lua functionality to be quite powerful, this would require either an extreemly granular and involved permission system that will just result in users "clicking yes anyway", or having a "approved" client side script mechanism.

There could for instance be a popular "hud script" that accepts some form of markup to create a hud, thus allowing an lsl script to create a custom hud, without every sl product running arbritrary awful lua code on your client.

I'm totally for LUA script being fetched from object inventory and run by the viewer, I think it's the only thing that makes any sense… (Could have a llRunLuaScript command, making it a push from SL, rather than a pull from the viewer, too — should also provide for setup parameter passing, and so forth.) Likewise, being bound to an experience wouldn't be a bad thing, it offers some sense of attribution (though, maybe should additionally require a group policy flag to allow such scripts to be run by viewers other than the creators).

but… Client side scripts are never going to be secure. Even if it's compiled on the server and delivered as encrypted bytecode only, as we've already seen with every other asset type that touches the viewer (and pretty much every software security measure out in the rest of first life, too), once it's on a users system, it can and will be read (copy protection in every case only hurts good people, it merely briefly slows down the actual pirates).

So, there's really no good reason not to keep LUA scripts open and readable. In practice, this simply means that the "business logic" will remain where it is (sadly), and the LUA portion will be constrained to taking messages from the LSL scripts and rendering them to the screen, or other tasks that require reduced latency (handling controller input, for example).

We also know that if LUA has access to anything LSL doesn't, then people will simply shove LUA "bridge" scripts into everything they make to give their scripts access to all the new stuff (we've seen a little of this already with RLV, and certain viewers do it in the opposite direction).

Merged in a post from WolfGang Senizen:

Title: Signed Client Scripts / Client Script Repository

Details: # In Brief

If a client side scripting solution is decided on, I would suggest either some form of official clientside script repository, or a way of scripts being signed to run clientside so that the script could be removed, or signature can be revoked incase of abuse.

There is a huge desire for products in sl to be able to load a script into the viewer for increased functionality. See this request

There is also a desire for the client side scripting to be very powerful. (For instance RLV like control of inventory may be an almost minimum level requirement desired for clientside scripting)

These 2 desires cause 2 main problems that this proposal could resolve to some degree.

Without a solution to this we could see a rejection of clientside scripts as they are regarded as unsafe and or unwieldly with further fragmentation of experience as users do or do not have certain scripts installed if there is no way for an LSL script to guranree a clientside script is loaded.

For security we would need a very granular permission system, which will inevitably result in people either refusing them because they don't understand, or just clicking yes because they don't understand/care. Which are both bad outcomes....

This is also assuming that nobody finds some exploit to escape whatever sandboxing will be done on clientside scripts. And as scripts being signed/ in repo, can require them to be full and cleanly open source, some level of abuse can be prevented / inspected from the start.

A permission system would still be very desirable, but less critical and less of a problem if scripts that can run in a default setup are vetted somewhat in advance.

For shared experience, we could end up rapidly devolving into "Script only works on X viewer because that's what I designed it for" kind of products.

With this solution an LSL script could prompt for a known good clientside script to be running/installed on the users viewer with user approval, and get expected functionality from it, Consistently across viewers as there would be little incentive for a TPV to break what is available to these scripts.

A form of script signing, or official repository, managed by LL or some approved user group, would solve most of those problems.

This would not prevent people from running custom clientside scripts, but allow LSL scripts to interact with "known good" clientside functionality provided by scripts.

I would also suggest to prevent people just telling others to "go download this zip and extract it here" that this signature/repository source, be enforced by default.

Thus lsl could run something like and get a response from the viewer once the script has either been loaded (installed and loaded or if it already running etc), or the user declined the script.

This would require anyone wanting new functionality for a general sl audience to either get their script approved, or get their functionality added to an existing project that's in good standing. Though this could still be faster and easier than getting desired features included into current viewers.

To alleviate the above somewhat, I would suggest some form of "Good Standing" where once added, a source (be that a project or individual) can update their script with less manual oversight.

It adds some extra continuous workload to LL or whatever user group. is decided to be in control of approval.

Opinionated decisions will likely be a problem, with some features being deemed inappropriate by some and not by others.

To allow for the creation of scripts and tinkering by power users, I would suggest the viewer needs to be launched with some sort of flag to disable the signature/repo requirement. With some clear warnings to less experienced users as to the risks this may entail.

Any client side scripts should have viewable source. It doesn't need to be modifiable in-place. ie. Cannot alter the client side script an object wants to run, but you can see and copy the source code it wants to run.

Closed source client scripting will breed distrust even if there is little apparent harm such scripts could cause. For something this different to the fundamental aspect of SL to gain traction, not feeding reasons to mistrust it would be nice. :)

I think I prefer a more repository or signed scripts style system

Where some clientside lua scripts get "approved" and scripts in sl can request that you have one of these clientside scripts installed, which the viewer could then prompt you to either install from the "repo" or accept the script becuase it is signed by LL.

This would maintain shared experience, but let people still have create custom stuff if they wish, it just has to be done manually.

I would like the clientside lua functionality to be quite powerful, this would require either an extreemly granular and involved permission system that will just result in users "clicking yes anyway", or having a "approved" client side script mechanism.

There could for instance be a popular "hud script" that accepts some form of markup to create a hud, thus allowing an lsl script to create a custom hud, without every sl product running arbritrary awful lua code on your client.