So, you're saying that you

can read the configuration and even during the runtime, you actually can rewrite your code to match, because configuration changes and you write like

straight code? Yes, it's like, imagine, we are all familiar with the concept of hot code loading for the mobile app, right? I know some app in some iOS app, and they submitted to App Store, but if they need to hard fix something, they usually, there is one approach that you can push through some hard fix, and really, hot reloading, you push the function from the server to the mobile apps. So, without re-supporting the app in the App Store again, so it's kind of a hot replying the some of your modules. So, the same practice applies to servers, right? We can replace some of the Alexa functions or modules, just from a remote century service.

Okay, so you would have some kind of way to load new configuration in that would get parsed and create the code that would, so your configuration would generate, would cause something to, would figure something to generate a new module. That module would be in charge of the permissions and configuration or whatever you want it to be, and then you'd have hot code reload, and that would re-fix it. Okay, interesting. Yeah, yeah, I mean, that makes sense. The only tricky part is to make sure that you don't generate a bunch of new atoms and other kinds of crazy stuff, right? I mean, there must be some dangers when you're doing something like this, right?

Yes, yes. The security is always a concern. So, to enable this, we have to be very careful. So, first thing is that this configuration coming from your end user or just from the developers. So, if from the end user, that's quite dangerous. And the if that is from our own developers, it can be slightly better, right? But we can still, we are not able to make sure that everyone is doing the right thing. So, to allow that and reduce the risk, I introduced some limitation or constraints in the library, we adjusted to have some kind of sandbox to run the code. So, there will be some security checks against the code and do a basically wrapping around the code to make sure that it can be not just not breaking the system. For example, by default, you can't send messages to any other process and you cannot for some dangerous kind of functions like exit or halt. So, there are some limitations. That's quite simple. And also, we can add some limitations when to executed functions. Like, you can control the memory usage and you can control the reduction, which is reflected the CPU usage. So, yeah, we can have some basic security checking around it, making it more usable. But still, yeah, they are risk-based. Like, as you said, if someone generated tons of atoms in it, yeah, that would definitely break the emergency machine.