Server-Side Embedded Scripting

I'm starting to look very hard the corresponding server-side analog to the Emissary, the Coordinator, or Implementer or some other $10 word to be introduced in the future.

I'm pretty much committed to writing my own V8 wrapper on the browser --- I really don't think I have much choice there, but I'm not sure I need to go that way on the server side (though I did discover that the v8.net wrapper for .net seems to run fine in .net core).   Though I think I can use MicroSoft ClearScript on the browser side.  But on the server side I don't have to do this.  I've been looking at alternatives and node.js is pretty much out.  It's just kind of hot mess sandbox-wise.  It assumes it has full user-level system access, like any piece of code on the metal would.

However, I am looking very hard at deno.   It has the ability to be run as a secure sandbox (you must enable network and disk reading/writing explicitly), and I think I can extend it to do what I need to.   It was scale up and out as needed in the cloud.

Basically, it needs to be able to load and implement gRPC (and protocol buffer) bindings to the Emissary.  Also I think there needs to be able to load multiple "Coordinators" in each V8.  Maybe it's light enough where I can limit a v8 to only one manufacturer.  I know I can't get a way with this on the browser side just yet.  Anyway, it has to be able to call the API for that server level to implement the business logic for that type of server (kudo, world, entity, avatar--also world and avatar servers are also entity servers depending on their role in the scene).

Also, it does seem like it works just fine with wasm, which is where I ultimately want to go.   They're making lots of use of typescript, which is also where I want to go (if I must do JavaScript like coding), and with Rust, and so maybe I want to look harder at that.  I may have to write the bindings in Rust, but we'll see.

...

The more I look at this, it may be impractical to directly add what deno calls "bindings".  Perhaps this can be done via gRPC or AMQP with the network layer turned on.   In this case, each docker images would be pre-created and perhaps constrained with iptables, since we should know what code we need to handle -- we can roll this out and handle versioning by just shifting to a new docker and have the old one stand down after it goes idle.   At least we can start with this.   The API layer should be nicely abstracted so we can change how it works.

Looks like I seriously need to up my TypeScript game.

...

And after even more looking, deno isn't quite ready for prime time yet.   I think for initial implementations, I'm being a little paranoid.   Ultimately if it implements the API it can be run, and it can be sandboxed pretty well in docker.  Be it in node.js, or in python, or whatever.  True sandboxing perfection we can work on over time.