Coding sandbox/playground

[DangerOnTheRanger]

This isn't something that will certainly be added so much as a proposal/RFC. The long and short of it is a sandboxed environment within which Maniwani users can upload code or static websites as part of an attachment in a new thread, after which other users can interact with them at some URL as long as that thread exists on the Maniwani instance. For a static website, the workflow would work something like this:

1. The user with the static website bundles it within a .zip file or other form of archive, and uploads it to a Maniwani instance. Thread tags could possibly used to indicate that Maniwani should host the attachment.
2. The archive is detected and hosted automatically on an subdomain/URL of the board administrator's choosing for as long as the original thread stays alive on the Maniwani instance.

For code, the process should work something like the following:

1. The user with the code that they want hosted uploads either a Dockerfile or a file archive containing assets and some form of build instructions, which could be a Makefile or some other relatively standard format. It is conceivable that this part of the process could be extended with tools like emscripten to allow non-web applications to be deployed to the sandbox and interacted with from the web browser, but this would be very language-specific. Again, thread tags could be used to denote the attachment should be built and run in a sandboxed environment.
2. A lightweight VM is spun up and runs the build instructions, and afterwards hosts the application while restricting network bandwidth and compute resources.
3. The VM is made contactable on a subdomain/URL of the board administrator's choosing.
4. The VM is destroyed when the original thread dies on the Maniwani instance. VMs could also be automatically destroyed after not being contacted for a certain period of time.

The primary motivation for this feature is admittedly more for the advancement of Futatsu rather than Maniwani in general (though other Maniwani installations could also benefit from it), as Futatsu's digital-maker-oriented culture would be greatly improved by a lightweight means of showing off working code/examples to others - that, due to the attachment system, others could download and examine for themselves.

I see three roadblocks/potential downsides to this feature:

1. This is definitely not functionality the majority of Maniwani installations would probably use; the plugin system that has been suggested from time to time would almost certainly need to be used for this.
2. This would be a fairly large undertaking - doing this correctly would result in a project unto itself that would take up its own separate Github project space and associated resources, in addition to the Maniwani plugin integration mentioned above. I cannot imagine this being usable in any way until about half a year's worth of development is performed.
3. Running the sandbox would be fairly expensive for the board administrator (in the case of Futatsu, me) since a single server/cluster of servers would be managing a fairly large number of VMs. Heavily limiting the resources used by each VM would go a long way in mitigating costs, but the bare-minimum, 1GB-of-RAM-and-1vCPU offering found at the lowest price tier of your average VPS provider would be less than sufficient. The sandbox would almost certainly need to be run on a machine separate from the Maniwani deployment, further complicating matters.

Ultimately, I believe the positives outweigh the negatives, but no matter how you slice it, this would involve a massive amount of effort.

Some additional things to consider:

1. There should probably be a way for the OP to update their own running VM without tearing down and creating an entirely new VM/requiring the OP to make a new thread, since it is reasonably likely that people would make errors in their code/deployment scripts, especially their first couple times using the system. Maybe subsequent archive uploads by the OP would be sent to the same provisioned VM.
2. There should be a way to notify the OP of any errors encountered while building the VM or running their code.
3. libvirt and libguestfs could prove very useful here.