mooR 1.0 Release Candidate Track Begins
The last post here was on January 1, 2026, when I pushed out beta7 and said we were heading for 1.0. Then I went quiet for a while.
If you are new here: mooR is a platform for building online games, communities, and collaborative spaces where the world itself is live and programmable by the people inside it. The point is that the environment is not a sealed product: users can build, script, extend, and reshape it while it is running. I care about this because I think the old dream of participatory online spaces was right, and I want to rebuild it on top of modern hardware, modern networking, and clients people might actually want to use. For existing MOO and MUD people: yes, this is very much in the lineage of LambdaMOO and related systems, it is fully compatible with LambdaMOO and compatible with substantial parts of ToastStunt as well, and part of the point is to carry that tradition forward without freezing it in amber.
The reason is simple: I had to go get a new day job. That cut way down on the amount of time I had for writing public updates, even though work on mooR kept going. (Don’t worry, the day job is Rust, too, and it keeps me sharp and also not starving.)
And in any case, weekends and evenings became a bit of a flurry of changes because I apparently could not leave well enough alone, and there have been a lot of improvements. I’ll get into some of those below.
But now, I finally cut a v1.0-release branch to drop the guillotine and force the final feature set at “code complete” for 1.0, and we’ll do a tagged 1.0 release as soon as that stable branch has had some time to percolate on the small number of projects that are working with mooR.
Forward-looking work can still happen on main, but the release branch is for getting this thing over the line. Assuming nothing ugly shakes out in the next week or so, I expect to push 1.0.0-rc.1 after it has had a bit of real-world time on it.
Mostly the main reason I finally felt comfortable doing that is performance. Because we frankly sort of kick ass on that front now. And I should say that Jules, in particular, kept pushing me on the optimization story and not letting me hand-wave around it.
For a long time, mooR had the architecture to scale across cores, but there were still enough concurrency problems and coordination overhead in the system that it was not actually scaling the way it should. Adding more threads added more throughput but not as much as it should have. Over the last week or two I finally managed to clobber a lot of that problem.
mooR 1.0 now scales much more like it was always supposed to, especially on read-heavy workloads. Give it more useful cores and threads and you get a lot more throughput instead of just a little bit more. And the part I care about most is not the benchmark chest-beating by itself, but the real-world consequence: under the kind of concurrent load where a classic single-threaded server like LambdaMOO would start lagging for connected users, mooR can keep spreading that work across cores instead of turning into a line everybody has to wait in. On the benchmark I have been staring at most recently, mooR pulls ahead of LambdaMOO once concurrency rises and ends up around 1.8x faster at the high end of that run, while also bringing everything else mooR was built for in the first place: multithreading, durable transactional database, a better extension story, richer data types, web integration, and a less archaic overall architecture.
If somebody were to deploy mooR on a nice large Graviton instance in production and host thousands of active users (oh, dear reader, please do that!) I feel confident in its ability to handle the load.
In any case, beyond performance, there’s also some other things that got improved and features added despite me saying I wouldn’t do that.
In response in part to Jules Iaccarino’s needs when building out game-loop style behavior in his own work… I added task_send() and task_recv(), which give MOO tasks mailbox-style async messaging. That makes it much easier to structure multi-step workflows and cooperating tasks without resorting to ugly hacks. It plays much better with mooR’s optimistic serializable transaction model than bashing on shared properties, and it’s also really useful for things like running LLM agent loops. And you can now build a nice “actor framework” (for those who know about such things) in mooR.
Blake Oliver added the TOTP/HOTP support and related helpers, which is useful both for straightforward account security work and for world-level flows people may want to build for themselves.
At the same time, the web side of the project got less messy, and I think more forward-looking.
The in-repo web client that I have been working on since the spring was split out, renamed to Meadow, and is now its own repository. This was done partly to separate the release cadence, and partly to force a cleaner boundary at the API level. The shared TypeScript pieces became a proper published web-sdk package instead of just being internal client code. The web host API also got cleaned up properly: versioned /v1 routes, a real OpenAPI spec, better content negotiation, stronger OAuth2 support, and the FlatBuffer schema published to npm. And on top of the new web-sdk I threw together a new LLM MCP client which can be used by Claude Code, Codex, OpenCode, etc to do in-MOO authoring remotely over the web (the agent becomes a programmer or wizard in your world like any other).
Meadow itself has also had a lot of independent work done on it, and a lot of that has been about UX rather than plumbing. There has been work around richer HUD-style presentation for rooms and related context, styling changes, improvements to link and presentation handling, and Timbran Hotel (my demonstrator public MOO) and Cowbell have been evolving alongside it in the same direction. Cowbell (my nextgen core for mooR) is now something I extract/export from the Timbran MOO from the work that happens there.
And there was also a separate Flutter client spike, mainly because the mobile experience still clearly has room to improve.
But also because I became frustrated with the accessibility story in terms of making Meadow on the web work nicely with screenreaders (it mostly does, but there are some ongoing frustrations). Accessibility as a first class feature of Cowbell + Meadow is extremely important to me.
So while this project on the whole is mainly about the server side, the broader picture is that the client and core experience have both kept moving too because my longer term goal is to take on the disgusting social networking landscape which continues to absolutely enshittify in the real world.
I would like mooR + meadow + cowbell + your creations to be the antidote to that.
Finally that brings me to another thing that changed, which is the license. mooR is now AGPL.
The reason is not complicated. mooR is server software. People run it for other people over a network. Under the plain GPL we were using, somebody can modify the server, run that modified version as a service, and never share those changes as long as they do not distribute the binary. For this project, that is the wrong outcome. If mooR is being used over the network, then the copyleft should apply over the network too.
And honestly it’s not that I’m afraid of some large corporation actually using mooR and stealing my work, I’m much more concerned about the pieces of work I’ve put in all over the place as infrastructure inside mooR which have been my blood sweat and tears for 3+ years now: a high performance in-memory transactional database, a very fast sandboxed interpreter, etc. I feel this work has merit even outside of mooR.
Most importantly: This does not mean the project claims ownership over anyone’s world, writing, or database content. It applies to modifications to mooR itself.
And also if somebody has a deployment or commercial situation that needs different terms, those can be negotiated separately with me through Timbran Consulting.
I’ll end with two things:
-
An important warning for anyone trying the current release-candidate work who worked with previous releases: there is a final breaking binary database migration here because of the move to Fjall 3.0 and some related internal format cleanup. If you are coming from beta7-era binaries, you should expect to export to objdef, wipe the binary database, and re-import. I do expect this to be the last incompatible break before stable 1.0.
-
It’s worth pointing out that Timbran Hotel is part of the shakeout process for this release branch, but it is not the only thing going on anymore. Other people are now building their own mooR-based projects as well, and some of those should be public soon and I hope to be able to say more about them before too long. That matters. It means 1.0 does not just have to work for my own demonstrator. It has to work for other people’s actual projects too. And it also excites me because there’s stuff happening, people are using this project, and you should, too.
So that is where things stand.
I have a day job again. The pace of public posting slowed down. But the project kept moving, the scaling story finally got much better, I couldn’t stop adding features but will now, the release branch is cut, and barring surprises the next step is RC1 and world domination.
And if you want to help, now is a very good time.
Run the release branch. Try migrating an existing world. Beat on the web APIs. Use Meadow. Connect to Timbran Hotel and see what feels rough. If you are already running another MOO and are thinking about a move, I especially want to hear from you. And if you want to contribute code, documentation, testing, client work, or just bug reports with real reproduction steps, that is all useful right now.
And before I stop here, I should say thanks to a few people.
Blake Oliver contributed the TOTP/HOTP work, which is one of those additions that is both practically useful and the sort of thing people will immediately build on once it exists.
Jules Iaccarino has continued to do piles of testing via his fallMOO project, which is exactly the sort of real-world pressure that exposes problems I would not reliably find by myself.
Norman Nunley Jr. has continued fixing bugs, contributing code, and generally being one of the people who helps keep the thing honest.
Robert Pate II has continued helping with project-management advice, testing, and serving as a sounding board, which matters more than people sometimes realize when a project is at the stage where the hard part is no longer invention so much as getting the thing actually shipped.
And on the Timbran Hotel / Cowbell / Meadow side of things, bscross has been absolutely invaluable for accessibility testing and feedback, along with plenty of other practical help. If people want some outside context for why that matters, there is a good interview with him here: Accessibility interview: bscross, which also includes a callout to mooR.
Links: