Jamesp1989 Resident It will be both.

Peter Stindberg no it will not. yes there will be client side lua but that is a separate project completely separate to this one. this project is serverside lua byte code being used alongside LSL much like the jump to mono. lua will allow for faster scripts for OBJECTS. this is nothing to do with plugins or anything that changes how the client or UI functions

Jamesp1989 Resident Sorry for the brevity of my previous answer. Yes, it's two different projects. Still you will have server side Lua, and client side Lua. At seperate release times.

Gwyneth Llewelyn:

To Henri's implementation (and as mentioned in my longer response), it has not had widespread application, nor significant security testing. As harsh as this may sound, it's a neat concept presentation, but that's all (probably why LL chose not to simply adopt it into their viewer).

To your last paragraph there, it DOES stop MoaP from being generally useful in SL. Requiring confirmation, and many people turning off environmental MoaP out of the box, make it basically useless for anything other than TV's and HUD's, much the shame. I'd hate to see a similar thing happen to Lua client-side scripting. (Should also mention, they have acknowledged the need for a setting to turn it off — which means this is a distinct possibility.)

Bleuhazenfurfle Resident I wonder what exactly you mean with "client-side scripts that are only possible when paired with LSL as part of an object/experience".

Suppose, for instance, that someone develops a client-side plugin that allows the blind community in SL (yes, that's a thing, believe it or not) to get a better interface to the kind of devices they use to read the screen. Or suppose that someone has a way to capture hand gestures and translate them to mouse movement in-world. Not to mention other obvious things, such as integrating Grammarly or — why not? — Discord on the client side. How exactly would such things, which currently only make sense on the client side, be "paired" with a LSL script?

Granted, such a requirement could be made, and people would simply get a cute, nice HUD that would do nothing. Or maybe the client-side scripter would be extra nice and even make the HUD light up when the client-side script was running, just to give some visual clue. But I don't understand what would be the of that.

of the many reasons for pushing things to the client side is to limit the number of processes running simulator-side (where they affect everybody) and push them to the client (where they only affect themselves). Here is a good example: Firestorm's client-side Animation Overrider. AOs are not among the worst lag generators, but they're not exactly the most friendly, either (mostly because of the tight loop required to identify which animation the avatar is currently using, and override it within fractions of a second). By pushing the AO to the client side, it's one script less running on the simulator, and one source of lag less for everybody — with the extra bonus of also slightly lowering the avatar complexity of the FS user.

Now consider contemporary avatar attachments. Mesh Bento bodies and heads have of scripts inside. And so does hair, or self-configuring Bento-compatible clothes, which communicate with the body mesh in order to selectively turn alphas on and off — on layers. The same applies for anything that requires a HUD to make any configuration change to an item, and as of 2024, practically everything such a HUD. All of which, mind you, do use HTML-on-a-prim (which would at least make them much faster — the built-in browser were fast, too — which is actually true of version 7 of the official SL viewer, which, as you all know, only a minority uses). Instead, they endlessly load an infinite stream of textures, big and small, just to create a very complex, very well programmed interface (since end-users mess up all the time, so HUD developers have no other choice but to be extremely detailed in their programming). It's madness what you're supposed to be just to have an avatar that looks reasonable "contemporary".

And that's not even skimming the issues with vehicles, weapons, in-world games, and whatnot...

In essence, practically that requires a HUD these days — and some things that don't even require one, such as animation overriders as well as pose/dance balls, even those that are strictly PG — slowly migrate to the client-side, and would need to be running on the simulator at all. And many of those things do require any equivalent "LSL pair" in-world. I hate to be coming up with the Animation Overrider example — it's just that it's the example for the kind of thing that should have been done the client at all. Some things should simply run on the simulators at all, period.

Another good idea from Firestorm: you can edit-on-demand LSL scripts, i.e. link them to your favourite editor — where you have all your tools at your fingertips and lag to worry about — and when you do a change and a save, it automatically gets reflected on the in-world script. While I personally have some issues about the way this concept was implemented (but that's just me and how I actually do my scripting off-world), it's an awesome example of the kind of client-side functionality that you can have on Firestorm, which does place a burden on the simulator at all, but which extends and expands the "basic" functionality by leaps and bounds. Unlike the Animation Overrider, though, which at least has some influence on what experience from your avatar (they need to load the animations, after all), editing a LSL script remotely has zero impact on either the simulator or the avatars currently on the same region as you.

Also consider those fantastic tools that allow you to build an object with prims and then save them by sending their parameters to an off-world server, which will send you a mesh back — made out of the prims you used and optimised for SL — which you can then upload. This process is simple, sure, but it requires several steps. With client-side scripting, all you would need to do would be to select the prims and select a new entry from a viewer menu ("injected" by the client-side script), "Meshify" or something similar. Everything would then be automated, and your in-world group of prims magically replaced by a new mesh. Does that make sense to a LSL script somewhere...? No, not really; in theory, at least, no LSL script should be .

Think of the many "builder tools" that we currently have — scripts to link prims together, align them, make mirror images, and so forth. You could get rid of all of them and just develop your own tools on the client side, period. Why bother with any scripts at all, when all you need is to align textures with prims or vice-versa? the building abilities of the should require scripts to be running on the .

In fact, all client-side scripts to be paired with a "LSL equivalent" defeats the whole purpose of lowering the number of active scripts on the simulators. Even a script that "does nothing" consume resources!

I also don't understand why exactly you are proposing this "pairing". Is it to allow residents to figure out who is messing up with their client, by requiring a LSL script to be acquired in-world, since that will tell you who's the creator, in a way that cannot be "forged" or denied?

If that's your only concern, I'm pretty sure that you can do something similar to have Linden Lab sign the code of any client-side scripts that have been done from a special LL "scripting store". I mean, Apple has been doing that since 2008 on their Apple Store; and pretty much everybody does the same these days for browser plugins and all sorts of other tools. This is not really rocket science any longer...

Of course, there always be malicious agents trying to push "unapproved" scripts of all sorts, but, alas, we're supposed to be adults and inform ourselves about what is safe to run on our computers, and what isn't. The Official SL Viewer might even, by default, allow LL-approved scripts, downloaded from the official "SL Viewer Scripting Store", and you'd have to specially override it to get access to non-official scripts. But once you turn that option on, well, you'll be the only one to blame :)

Gwyneth Llewelyn: Wow, you write as much as I do. (Have been trying to actively trim my posts lately.) Unfortunately most of what you wrote is redundant.

I'm not blind to the plugin use you describe (pardon the pun), I just don't think they'll happen, or that this is a suitable interface for them, and I strongly doubt LL will curate anything, nor do I want them raising the premium prices so they can afford to hire a curation team (because they'll need to before long).

To be frank, regarding your play on disability, I actually agree, it'd be great to see stuff like that — I also think it's nothing more than wishful thinking. I did concede perhaps plugins could be a thing too (in a suitably half-hearted manor), but I get the distinct feeling they'll be so locked down, as to be not possible, or at least, virtually pointless, and worse, end up just being a security/privacy nightmare — then everyone will just turn off client-side scripting for safety, right out of the box (like we do with MoaP), and the whole thing will just slink away and die, utterly ignored. (Also, requiring a dialog to manually accept each and every client-side script — either will make it all DoA.) Of note here, Henri's Lua implementation differentiates between "system plugins", and "user scripts". This is the right way to do that, I'm just not sure that is the right thing to do — among other things, it weakens the security barrier presented to user scripts.

The main other realistic draw (and the part I'm whole heartedly endorsing) seems to be decent custom UI and such, for which we need it to operate similar to LSL, and which _can_ be heavily restricted and locked down, an yet still be greatly useful — alongside other scripts as part of an object. This use case still has great benefit even with zero access outside of a very strict sandbox.

The next section of your response about shifting processing client-side, I already fully agree with, and is completely compatible with the object-bound scripts I'm pushing for, as a companion to LSL — and is a major part of what I'm hoping to see happen. Client-side scripts could even render to a canvas, and use that as a texture, or construct mesh, and so-forth — whether I want random objects in my environment loading client scripts into my viewer (like each of the 250 notice boards at a club, or random attachments people are wearing), I'm a little uncertain, and I don't see them being able to render textures or mesh for anything that anyone else can see, if they don't. It may also be of concrete benefit to vehicle control, being able to do low-latency filtering of inputs, and pass only the useful bits through to the LSL-side scripts. BUT, as I noted, I expect it's utility will be limited by people not wanting to put their business logic on the client side — which can not, ever, be fully locked down, and any significant attempt to do so by LL will lead to a horrible mess for most people (as has been seen time and time again in the games and media industries).

Again, to be clear, when I said "Paired with LSL", I did not say "equivalent" — my intention was to exist alongside and complementing with LSL script functionality; paired more along the lines of Lua scripts being object inventory just like LSL scripts are, and drawing resources from the object they're contained within, and with their primary functionality being an extension of that object — they hopefully won't need to literally be paired with an LSL script, though doing so to begin with will allow LL to spend more time focused on what's actually unique client-slide, rather than rushing to shoehorn all of LSL's features in as-is, rather than properly re-architecting it to actually suit the new environment. I am okay with keeping client-side almost exclusively for the things that can't be done with LSL, and only migrating over the bits as they find they're constantly being done by shunting messages back and forth. All those client-side huds, are likely still going to be attachment objects with inventory resources — that is still the most sensible container for functionality in LSL. (And Lua likely isn't going to be receiving LSL-side events anyhow, so literal pairing with an LSL-side script will likely still be common, just not specifically required.) And of course, a client-side HUD will probably still want to have it's business logic nice and safely tucked away in an LSL-side script (for which I hope linked message works, or, that we get something more purpose-built along the same lines).

I have absolutely no idea what you were on about with the script editing thing — that seems to already be a thing. Script editing has no impact on the sim, only the compile step when you save it, which will still be a thing. I'd hope Lua scripts are at least being checked server-side, and I think if they were compiled server-side, and delivered back to the viewer in byte-code form (ie. the viewer never touches the source itself), I actually think that could be a good thing. LL could even punt that off to it's own server, so it doesn't bother the sim at all (they've hopefully done the same with LSL already — have a dedicated server just cranking out bytecode, and sending it off either to the sim, or now the viewer as well, as appropriate; there's zero reason the sim itself must be the one compiling LSL scripts, either).

To the last part, I do strongly feel Lua needs to be linked to in-world. I do not want a wholely external marketplace of Lua scripts — Apple and Google likely have more people working on their app stores, than LL employee's in total, so expecting LL to provide a curated store of plugins is ludicrous. (And I sure as heck don't want an UN-curated store of Lua scripts with (potentially) unfettered OS access…!) Henri's implementation has not had wide-spread testing, being confined to a single minor viewer, as it is. We do not know of any security implications their implementation may or may not have (Henri's skills not withstanding, third-party audits and security research are a thing for a reason, the same reason book authors have proof-readers and editors), and so it can not be used as a yardstick here in a useful fashion — it's more akin to someone pacing out a distance and giving their approximation of it.

All that said, LL appear to have a have a fairly clear plan in mind, which they seem to still be keeping under covers, so most of this is speculation anyhow. The puppetry thing had Python plugins intended for such things as what you describe there, so it's not out of the realms of possibility, but … I just don't yet see a path for it working out usefully, and many of these same concerns were raised there, too (although it was squarely in the plugins camp).

Woolfyy Resident: I had missed that one … and it doesn't fill me with confidence.

A of people are eyeing Lua as an alternative to HUDs, and especially those horrible llDialog's, and replacements thereof are a point of discussion. (Among with a whole raft of things that are perfectly good, but LSL my it's nature simply can not realistically allow — including the things I mentioned above.) That summary seems to basically be saying that what so any of us hope for, won't be a thing (at least for the foreseeable future). The part that worries me, is I'm not sure the makers will care; we've been finding workarounds for LSL's limitations, for as long as LSL has been a thing, and I doubt this will be any different. The reason I want to see Lua explicitly placed as a companion to LSL, is so that we don't find ourselves in the situation where every single shop is also pushing a "Lua bridge" that they expect you to install so you can participate with their products, in turn leading to everyone eventually walking around with literally hundreds of Lua plugins (as you often see mods in games, be it a moddable game or otherwise), and all of them running various nasty hacks to facilitate communication with the scripts. My best hope should LL try to keep a wall between LSL and Lua (and that summary suggests such any such wall is already broken), is that someone will make an open bridge that manages to capture enough popularity, and eventually makes its way into the TPVs, leaving us merely with another RLV. Worse, though, it would incentivise LL to not even approach a whole range of really awesome capabilities that we've been hanging out for, and Lua is perfectly placed to facilitate. That said, I think I heard the term "yet" muttered in that context, and a lot of these hops come from comments that have been made in the meetings, so, there's still hope, I guess…

Those comments about Rust feel a little … disingenuous. Rust requires a higher degree of programmer awareness, but it's not a one-sided trade — the most efficient memory management in existence, is no memory management at all, and the owner-borrower system at the core of Rust is a very popular method of achieving that (should note, Rust is not the first to use it, Rust was just the first to figured out how to make much O/B vaguely palatable as a mandatory feature, and gain popularity despite it).

I have also been wondering for a bit now, if part of this might be the hope to use it in place of Python should they get Puppetry going again.

Woolfyy Resident: It seems fairly plain that Lua is just Puppetry Mk2 — not in terms of function, but in terms of reason to exist.

Puppetry was a gamble to capture attention from Meta(verse), which fizzled just like Puppetry. Coincidence, or cause and effect?

Lua, is a gamble to capture Roblocks attention. We'll have to see if it too flashes past like a shooting star, the way Puppetry did.

I'm hoping not, because Lua be so very much more, if they position it right. LL just … well, their track record is more one of "adequate, with regrets". 😞

Woolfyy Resident, I'd argue that "Puppetry is not dead", it's just that LL placed too many expectations on picking up the burden of implementing it :-)

role was to enable a plugin functionality. That's what LEAP (their codename) does. This they've done.

role was to actually those plugins, including (but not limited to, as they say) the Puppetry plugin. For the latter, they even provided us with some "boilerplate code" to give us a hint on what to do and how. Sadly, nobody picked it up; thus the "lateness" in announcing Puppetry or anything else working over LEAP.

Lua, or Roblox's variant of it, allegedly will be used to add functionality (programmatically) on the user-facing client-side of the viewer UI. Its scope will be (allegedly, again) much more limited, e.g. adding new menus & special effects, or new buttons, or drastically changing everything — such as, say, replacing the inventory browser with something much better, or the chat window(s).

There is obviously some overlap in the two techs, but according to what I read on the SL Wiki, LEAP is more about "triggering things in-world", while Lua will be more about changing how the user interacts with the viewer. But I might be mistaken...

Gwyneth Llewelyn: Isn't that reply better addressed to Woolfyy? You're telling me a bunch of stuff I already know, hence why I wonder if part of this is an attempt to un-stall it, also. (Should add, part of the sense that puppetry is dead, is there were a bunch of parts to it that haven't materialised, and don't appear to be being worked on, either.) I still see Lua mostly as a shift in which additional user base they're chasing (to be clear, I don't have a problem with that, they are a business after all, and will only remain so so long as they can keep getting new customers).

As for how they're positioning Lua, yes, that's how I read it too — and I believe it to be another in a long line of "missed by _that_ much" mistakes, due to not having enough people-time to devote to figuring out how to actually do anything properly (which is what I hope this forum is intended to help with), and just pushing out what they can manage to throw together in between other tasks, and hoping they can fix it later (which in LSL's case in particular, they most often can't because of not breaking stuff). I'm deeply hoping that hint of a "yet" at least means it's next on their list, right after "get it working and into peoples hands". My concern, as I said, isn't so much what they want it to be, but what it'll be, especially once people get their hands on it — every creator knows the two are rarely properly aligned.

Anyhow, this sub-thread seems to be spinning in a circle, so, till there's more actual information to talk about…

Bleuhazenfurfle Resident — my apologies, you're absolutely right, that was a reply intended for Woolfyy Resident. Corrected!

Woolfyy Resident: One language can cover all lacks. That's why we have as many languages as we do (and the venerable XKCD have done a couple posts on the topic). But more to the point, there are a whole host of things that simply feasibly be done on the sim — due to memory restrictions, latency, bandwidth, etc. — but can readily be done client-side. Whether that's LSL or Lua, is mostly immaterial, the limitation is often simply "on the sim" (and the reverse holds true, also, there's things LSL scripts enjoy, which would be impractical to move to the viewer). Adding some kind of client-side scripting, is simply the way to even approach "cover all lacks".

I will add, from what I recall, HiFi was running their scripts in the viewer (JS, wasn't it?), with users owning land having to arrange for land-based scripts to run somewhere (pretty much how I planned to do it, too, Philip was just a couple years ahead of me with LL having been incorporated the year before — or you may possibly have had as your benevolent dictator… just imagine horror! ). He may well have brought that experience with him when he came back… (Is all rather reminiscent of Mr Jobs…)

That comment about those office macro's, is an issue I've raised several times pretty much from the moment I heard the very first utterances of Lua with regards to SL (to be fair, these thoughts go back quite a few years, in the in-world groups, and I raised some of them again with Python for Puppetry, too) — I put it in terms of MoaP. And it is one of my greater concerns; users will just say, "ahhh, nope".

Woolfyy Resident I would ever-so-slightly disagree on the issue of "LSL being similar to Lua". If you mean that the syntax has some resemblance, sure, that's no coincidence: both languages are inspired by the C/C++/C#/Java/JavaScript school of conceptual syntax, and obviously there are common concepts to all of them.

But one thing is saying that they visually share a similar syntax (even though I would argue that LSL is closer to JavaScript than Lua). The other thing is that they accomplish similar things. In that regard, I have to disagree.

LSL is a "programming language". It's, well, a . There are some very interesting comments on LSL made by the developer of , a complete command-line linter for LSL, which mimics exactly how the compiler actually works, and gives the same syntax errors as LSL does, but with a twist: it actually explains there are errors, , as a bonus, checks for wasteful things like defining variables that are never called (often due to a simple typo) or referring variables from the wrong scope (which is not always obvious to catch).

But he also struggled a lot to get the many tweaks, hacks, and Band Aid mess that is LSL to be successfully parsed (or parseable).

What LSL shares with both JavaScript and LSL is that all three are , meaning that they will all run inside a virtual machine "inside" the host application. JavaScript, of course, was meant to run inside a browser. LSL is a bit irregular since it is edited locally but handled "remotely" on the simulator servers, but, since it cannot run "on its own" as a stand-alone application, it's fair to classify it as an "embedded language".

Lua, well... Lua was to be embedded in other applications and provide whatever the developers need to do. It's a general-purpose language with several compilers. It is "JavaScript done right" — with that I mean that JavaScript was to be a browser-embedded language, but, with successive revisions, it aims to become a rival to C/C++/Java/C#, both in complexity and in he way it can tackle almost any kind of task — at the cost of, well, having started as a humble, simple, easy-to-learn, very limited (but nevertheless tremendously useful), browser-based scripting language (hint: PHP has suffered from the same issues as JavaScript as well, although, to the best of my knowledge, nobody uses PHP as an "embedded language", while there are tons of examples of JavaScript being used that way).

Lua approaches things from the other side: it is, and always was meant to be, a general-purpose language, and, as a general-purpose language, provide a general-purpose base type (the ) which can be interpreted as being an object, an array, a database access, a module, whatever you wish to implement. And is was also designed from scratch to allow the developers to extend Lua with external libraries, written both in Lua itself as well as specific, compiled-in libraries, tailored and fine-tuned for certain tasks.

JavaScript's engines can certainly be tinkered with to do all the above and more, and possibly even more efficiently than Lua does — I haven't checked. The point here is just that JavaScript to be able to support the kind of things that Lua has . It is arguable that, once JavaScript achieved a certain degree of maturity, it out-paced Lua in everything that Lua does well, so Lua became redundant. I cannot really argue against that, especially because I have no experience in 'extending' JavaScript as an embedded language, while doing that in Lua is a trivial exercise.

As for LSL... well... personally, for me, it has a huge advantage: it's a strongly-typed language, and I'm fond of strongly-typed languages, mostly because, unlike, say, JavaScript, you don't need to spend half your time code-checking if the arguments are of the 'right' type and handling all possible error cases (it doesn't help that JavaScript allows variables to be in several distinct, but conceptually similar states — from 'undefined', to 'uninitialized', 'assigned', and so forth). Thus, TypeScript :) (a similar case is being made for PHP as well, which is lazily typed these days, but types are getting enforced more and more with each successive major release, with the purpose of getting far more efficient just-in-time-compilers than we have today)

Lua suffers from the same issue of type-less JavaScript, as is common on most languages (LSL being actually a notable exception!), but it handles these issues of figuring out a variable's type much more gracefully than JavaScript. Not to mention, of course, that you don't have a line-by-line debugger for LSL, while JavaScript has one embedded into browser these days, and Lua, of course, was designed since day one to do the same.

My whole point here is that I still think that, between Lua, LSL, and JavaScript, client-side scripting would be better handled by Lua. The similarity between the syntax of the three programming languages means that it's not hard to switch among the three. JavaScript benefits from having a much larger user base; Lua, thanks to its adoption by popular environments (Roblox being perhaps the largest one in terms of users, but it's by far not the only one, nor necessarily the example), might also have a considerably large user base — a tiny fraction of Lua's, of course — when contrasted with LSL, which, well, has a handful of experienced programmers :)

LSL is also too specific to SL. Obviously you could extend it to address client-based programming. The problem is that some concepts don't translate easily. For instance, consider the huge library of functions provided, as a block, by LSL. Each has an ID (which used to be well-known, and is still listed on the LSL Portal wiki, at least for the older ones). There is no concept of having different libraries for different tasks — you get the whole package, which is built-in, and neither replaceable nor extensible (except, of course, by LL). Scripts are independent units which are not meant to be linked together (as in including each other), except through library-specific functions (i.e. sending linked messages). And although there is this concept of the "LSL library of functions", it's by no means a "library" in the sense of what the other contemporary programming languages offer: a lot of interact, and are dependent upon, — something that should have been abandoned in the early 1960s.

Consider, for instance, the very basic event. To trigger it, you use a library function. But that library function assumes that the programming language has a kind of event that is triggered when the system has incoming text to be captured. If you need something very similar (say, capturing directly-sent Instant Messages), then you need a mechanism — a different library function to initialise the system, and syntax construct for a event handler.

Event handlers are not uniform. Each has their own parameters and is handled differently. While I appreciate the originality of the design, it is a nightmare to extend. For instance, you can define new states, but you cannot pass any parameters to it — only via global variables. You can use several different event handlers, covering roughly all possible interactions — but you cannot have your set of event handlers, such as you have in JavaScript, Lua, and pretty much every

other programming language in the planet.

Thus, obviously, LL implemented client-side LSL, since the kind of events to be processed would be different, they would have to provide a set of library functions from scratch.

But here is where one of the problems resides: functions need to be retained — such as, say, the String or List manipulation routines, as well as what we think of as the Math library, because all of those will continue to be useful, and are not directly tied with the running environment at all — they would have to be independent. While, on the other hand, clicking on the might trigger a special new kind of event — which would not have anything to do with "buttons" as shown by the renderer. Thus, LL would have to provide a LSL library only for client-side clients. Which, in turn, would require at the very least the ability to "swap in" different libraries — which is currently impossible, by design — and, well, give users a completely different set of functions & language constructs (for new sorts of events), so... it wouldn't be the same LSL2 we know, but something different.

Not to mention the confusion that would arise from residents not quite understanding which "version" of LSL they were supposed to get, from, say, the SL Marketplace — even if such different "versions" might be clearly labeled as such, there be a certain degree of confusion between both.

That said... why bother having all the trouble of creating from scratch a brand-new programming language that would only be used by a very small group of people (compared to the global Internet population)?

In truth, to be honest, I never understood why LSL was invented at all. Lua has been invented in 1993, and by 2001/2 (during the alpha/beta testing of SL), it was mature enough. The Lua compiler is only about 240KBytes in size (and has no need of increasing in size over the years, as the language itself is stable enough); contrast that with the smallest embedded JavaScript interpreter I found, [](https://github.com/cesanta/elk). It's only 20KBytes in size. Granted, you will have to forfeit the following language constructs:

... which seems quite a lot to give up, but remember, is a bytecode compiler (unlike LSL or Lua) but purely interpreted.

What would make much more sense, to me, would be to progressively move from LSL and a different programming language. Similar to what LL announced (but then never implemented) when it decided to replace their own virtual machine & bytecode, and moved to Mono instead, which, in turn, support many other programming languages, but never did. Some OpenSimulator compilers, in the past, did try to support different programming languages, but I guess that this concept was abandoned due to lack of interest (and possibly because @Ubit Umarov introduced a much better LSL2 compiler/VM, which became the compiler/VM)

Anyway, to be honest, I'm a bit agnostic about whatever programming language LL picks for the client-side scripting, so long as they implement sort of client-side scripting :) While I would naturally prefer a popular, well-designed, well-known, robust and mature programming language (both JavaScript and Lua would fit most of those requirements), if LL wants to extend LSL2 for some reason... go for it.

And among the many Lua dialects, I'm agnostic as well. The choice of Roblox's Lua dialect, with its attempt to turn Lua into a typed language (which makes lots of things much easier), is actually a quite good one, and definitively the way to go for the future of Lua.

(That said, I actually prefer to do programming in Go, so I'm seriously biased — Lua has lots of interesting syntax features that Go adopted as well. Integrating both is a breeze, and there is even a native Lua compiler fully written in Go, although my guess is that most programmers embedding Lua in Go use the "official" Lua compiler & VM, which is written in ANSI C, and then just call it via Go's C API — an extra step, but one that provides a faster Lua compiler. But I digress. The point is that Lua's a neat little programming language that is easy to learn and even easier to integrate everywhere.)

/me raises the "strawman" flag!

Just because Microsoft "killed" client-side scripting (or made it much more limited) doesn't mean that LL should also "kill" that tech in their viewer. The things are not correlated :)

A better comparison would be how browsers run JavaScript and can be modded using themes and extensions/plugins.

Woolfyy Resident ah, if only LL had developed the viewer to be independent from the viewer ...

I wrote a proposal https://feedback.secondlife.com/lua-viewer-alpha/p/please-consider-your-security-model-carefully that shows how arbitrary code can be run securely while still having full utility.

It is because of the fact that Client Side Scripting will break the shared experience policy, that it should not be added to SL. Not to mention the enormous can of worms it stands to open by people passing around "Plugins" for the SL Viewer that will further complicate peoples lives, and potentially have bad actor code in them. This is a TERRIBLE idea top-to-bottom. The fact that it's LUA based just makes it worse.

Care to share a case where you think a client side script will cause a problem?

Extrude Ragu The ops example of a "total rlv extreeeeem" was a good one. we have already seen a desire for that cause users to install questionable software, lock themselves out of their accounts, and more.

To be useful the client side script system must have deep reaching capability, or it's just a toy and no one will find use it.

If that capability is deep reaching then the potential for abuse is very high.

Security is always a huge concern, especially if that scripting is leveraged by closed source plugins installed from random corners of the internet.

There is a very long list of RLV command ideas we tossed in the trash because of the abuse aspect.

Coffee Pancake Having an official way of doing client-side scripts would prevent exactly the kind of "lols install our special totally-not-ransomware viewer" scenario you're scared of.

People will do what they want, and if they want turbo-RLV and can only get it by downloading dodgy viewers, then they'll download the dodgy viewer. Better to provide a "safe" way of controlling a client, than to continue with people installing questionable software because it's the only option.

Polymath Snuggler Client-side scripting doesn't conflict with the shared experience policy. There are already a billion things we can do clientside... interact with RLV, change your sky/water, play animations locally and change their speed, derender objects/avatars/clothes, turn off local lights and materials, the list is endless. Not to mention a TPV already having this implemented, along with bot clients.

Wulfie Reanimator, you're totally correct.

Vincent Nacon we hope your suspicions are correct :)

Woolfyy Resident Oh well, I still look forward to it. :D

Woolfyy Resident, close enough :)