~seanlynch/mooa

Lua + lubev + sandboxing
5c03ec5a — Sean Lynch 6 years ago
Save loaded packages for emulating require
c5db0f2a — Sean Lynch 6 years ago
Load SDL module
4f889169 — Sean Lynch 6 years ago
Complete syscall whitelist

refs

master
browse  log 

clone

read-only
https://git.sr.ht/~seanlynch/mooa
read/write
git@git.sr.ht:~seanlynch/mooa

You can also use your local clone with git send-email.

#About

Mooa is a work in progress. The ultimate intent is to create a multi-user, interactively and collaboratively programmed network server. Its inspiration is the original author's (Sean Lynch) experience with LambdaMOO, MUSH, and LPMUD, and ColdX/Genesis. Its primary application is intended to be a textual shared interactive environment accessed via web browser. Kind of like a chat server, but programmable entirely from within the environment.

#Requirements

  • Lua 5.1
  • libev
  • udns

#Building

There is not yet any autoconf or anything like that, so edit the makefile and then run "make". Hopefully you'll get an executable out of it.

#Running

Edit main.lua and put interesting stuff there, then run "./mooa". Something interesting will hopefully happen. For now you will have to read the source to have any idea what's going on. The APIs are in flux so it seems kind of pointless to document them, at least until I figure out how to automatically generate useful docs from the code.

#FAQ

These are questions that are frequently asked only in my head, because I am writing this before anyone has actually seen the software. And even after I put it up on Github, I doubt many people will see it except for bots that scrape Github looking for particular keywords and languages so recruiters know who to send their barely targeted generic emails looking for "rockstar X coders" to, completely ignorant of the fact that you have code written in 10 different languages among your contributions and your only code in language X is just a fork of another repo with only very minor tweaks.

#Why Lua?

I would have preferred Javascript, but neither V8 nor SpiderMonkey is really targeted at embedding. Both their APIs are constantly changing, they are poorly documented with much of at least SpiderMonkey's documentation being out of date, and V8 has a rather complex C++ API. The only C/C++ JavaScript implementation that's targeted at embedding is mujs, and its license is extremely restrictive.

Lua, on the other hand, has a stable, extremely well documented API, is specifically targeted at embedding, and is licensed under the MIT license, which doesn't require any mental gymnastics to call it "free as in freedom."

#You should use JS anyway

You're probably right, but if I use JS I won't be able to motivate myself to write the damn code. Complex, poorly documented, constantly shifting APIs directed at a completely different use case are not exactly enjoyable to use.

#Use node.js. It has a sandbox

That's not a terrible idea, but I envision high concurrency and low latency. Having separate processes that have to hang around even if the code running in them is blocked on IO or sleeping doesn't scale incredibly well. On the other hand, my approach will probably have more security holes. I will probably at least have trusted and untrusted Lua code running in separate processes in their own namespaces and sandboxed with SECCOMP, but it seems likely that I will have all untrusted Lua code sharing the same process sandbox, isolated only by not having any mutable shared state. I don't yet know whether that means separate Lua runtimes, however. That will require some experimentation.

#Something is broken

This thing is nowhere near being in a releasable state. Please feel free to report issues if you think there are fundamental design flaws or you think I should change how something works, but don't expect it to be actually useful for anything yet. So stuff like "you're doing this wrong" is fine, but "I can't use this for X" is not.