Script loading from SL servers to clients
AnneiLyranae Resident
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.
Log In
WolfGang Senizen
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.
Bleuhazenfurfle Resident
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).
Coffee Pancake
LUA without integration into the SL ecosystem and workflows will only result in shared experience breaking / nefarious use cases.
LL need to copy the policy page from Blizzard who use LUA for World Of Warcraft's mod ecosystem, starting with mandatory open & clear source code. They have a lot of experience with this and all their end user rules exist for established reasons.
AnneiLyranae Resident
I really think experiences are important because they function as a sort of digital signature. hell they literally could make it one if they want to RSA scripts downloaded as a security measure to make them immutable client side (easily done, the script is downloaded encrypted with the private key so the viewer has to use the public key provided by a linden server to decrypt). the big thing though here is code accountability, if someone does something malicious they can have their experience revoked by LL. a secondary benefit is it allows for proprietary clientside code. which is of some importance if you want to oh... say make a gaming empire based on this. oh the viewer is totally open source so it can be copy botted but still, it is a basic stop gap.
Journey Bunny
Agreed, I think it's an important extension of the client-side scripting!
Over in https://feedback.secondlife.com/feature-requests/p/client-side-scripting-via-viewer-api I had suggested that there's a sorta SL App store-like concept imitating mobile app concepts ("this app is requesting the following permissions" etc managed through the App host verifying the api calls, thereby ensuring a level of automatic transparency and vetting).
But that feature is missing the component of "the game region you have entered requires the following viewer extension scripts:" ... eg, giving experience/game creators a way to provide necessary UI and restrictions for an experience.
The suggestion here bridges that gap, giving experience creators the option to require vetted viewer extensions, users the option to opt-out, and land owners the option to either eject or to make users non-participants in a game (like Horizons Experience does).
Extrude Ragu
+1
My main interest is being able to do client side effects from games, and also being able to set gameplay constraints in experiences, such as things like hide minimap, prevent alt cam beyond a set distance, teleport or anything that might constitute cheating in a game I designed.
Players should be able to easily opt out of such experiences too. Perhaps one way it could work is permission to run Lua is grant from attachments, and lost when the attachment is detached. This way players can simply detach attachments that cause unwanted behaviour/leave the experience.