So here's the first mooR development status post... after three years of development. I quit my day job recently, which means I can finally write about what's been happening instead of just coding in the dark on weekends and evenings.
Working on mooR full-time is only going to be possible for me (for a bit) thanks to community support. If you find this work valuable, please consider sponsoring development to help keep this project moving forward. There's also an active Discord community where we discuss development and share ideas.
For newcomers: mooR is a MOO server written in Rust—a fully compatible rewrite of LambdaMOO, the pioneering 1990s text-based virtual world platform. (The name "mooR" is also an anadrome of "room," which is fitting since rooms are the fundamental unit of interaction in MUDs and MOOs.) Think shared interactive fiction where users can program and modify the environment in real-time—sometimes used to build gaming MUDs (Multi-User Dungeons), sometimes oriented towards socializing and community-building, and often a mix of both. Its key feature is that every part of the system is programmable by users, built on a live programming environment where everything persists as objects that can be modified on the fly. We're bringing it into the future with active development, modern architecture, and enhanced language features.
Beyond technical improvements, mooR serves as an authoring system for building dynamic online communities and collaborative games. It's designed to revive the promise of meaningful social interaction from the earlier internet era while taking advantage of modern hardware and offers a web-based interface that doesn't require a custom client.
What started in fall 2022 as what I thought would be a quick hack—maybe a couple months of weekend work—has turned into a rather surprising just-shy-of-3-years journey. The project has ballooned in scope, shifted direction a few times, but here we are in the final stretch leading up to a solid 1.0 release with capabilities far beyond the original vision. For more background on the project's goals and motivations, see the foreword to the mooR manual.
Moving to Codeberg
Before diving into the technical updates, I should mention that the project has moved from GitHub to Codeberg. This reflects my preference for supporting non-commercial, community-driven development platforms. All development now happens at codeberg.org/timbran/moor, though the GitHub repository remains as a mirror. To submit bug reports or submit pull requests, please use the Codeberg repository.
As part of this move, I've also taken steps to establish a bit of an organization—Timbran—as a cooperative around mooR's development, and hopefully for other projects in the future. It includes some people I've known in the MOO community for decades.
The "mooR book" has also moved from GitHub to Codeberg and is now at timbran.codeberg.page/moor-book-html/. I have been trying to keep the book up to date as major changes have been made to the language. However, I'm always open to critique or contributions, as it's difficult for me to keep this glued together as a cohesive set of documents. If you are reading this and have technical writing skills, please consider contributing to the book. I'm always looking for ways to improve it.
This post covers a particularly productive period from August through early September 2025, during which we tackled some of mooR's most fundamental architectural challenges and committed major new capabilities that bring us significantly closer to a stable 1.0 release.
Earlier This Summer: Major Architectural Advances
Before diving into the August-September object system work, it's worth noting the massive foundational improvements that happened earlier in the summer. June and July saw some of the biggest architectural advances in mooR's development:
- Lambda expressions: In one of computing history's great ironies, LambdaMOO—despite having "lambda" in its name—never actually had lambda functions (anonymous functions you can create and pass around like values)! mooR finally delivers on that promise with true lambda expressions and closures, enabling functional programming patterns like
{x, y} => x + yand functions that "remember" variables from their creation context - Complete web client rewrite: The web interface was rebuilt as a modern React single-page application, providing the foundation for the advanced editor features and mobile improvements discussed later
- End-to-end integration testing: A comprehensive testing framework was developed that validates the entire system stack—from database operations through the scheduler to client interactions—using real MOO cores like JHCore for authentic testing scenarios
These changes established the robust foundation that made the subsequent object system enhancements possible. The integration tests in particular have been crucial for ensuring that new features work reliably with real-world MOO databases.
Two Major Object System Features
At its heart, MOO is a kind of object database where everything—rooms, players, items, verbs, properties—exists as objects. Traditionally in MOO, objects are referred to by sequential numbers like #1, #123, or #4567. This development period focused on two fundamental enhancements to mooR's object system that together represent a significant evolution in how a MOO can reference and work with objects.
This gets a bit nerdy, so if this doesn't interest you, feel free to jump to the next section.
UUID Object IDs: Beyond Sequential Numbering
First, mooR now supports UUID object IDs (Universally Unique Identifier object IDs) alongside traditional sequential numbering. Objects can now use UUID identifiers like #000081-991048F540 instead of just #123. While this might seem like a minor change, it addresses a fundamental architectural issue with numbered objects. Traditional numbered objects create guessable, sequential IDs that consume "number slots" from a shared namespace. UUID objects make it clear which objects are part of the core system (numbered) versus user-created objects (UUID).
It's important to note that substantial portions of the UUID objects implementation came from contributions by bitMuse, whose practical needs for object segmentation in his own core drove many of the design decisions and who provided significant code contributions to make this feature a reality.
Implementing UUID objects required updating the entire object pipeline - from parsing and display to textdump format and database storage. Despite this extensive scope, UUID objects work seamlessly with all existing MOO features, including inheritance, property lookups, and verb dispatch.
The work also required adding the renumber() builtin, which was present in LambdaMOO but missing from mooR. Beyond filling this gap, the implementation was extended to support conversion between UUID and numbered objects, giving administrators flexibility in how they manage their object spaces.
Anonymous Objects: Automatic Memory Management
The headline feature is the implementation of anonymous objects. While ToastStunt has supported anonymous objects for some time, implementing them robustly in mooR presented significant architectural challenges due to our concurrent, transactional design. Unlike traditional numbered objects, anonymous objects are automatically garbage collected when no references to them remain, eliminating the need for manual object recycling.
Note: At the time of this post's publication, anonymous objects are still in pull request form (#487) and require extensive testing before being merged. Additionally, significant new content needs to be added to the mooR book to properly document and explain these concepts.
While anonymous objects aren't anymore "lightweight" than a regular numbered object, they behave more like object references in mainstream garbage collected programming languages, and enable a more natural object-oriented programming style. They participate fully in the usual MOO object system with properties, verbs, and inheritance, but disappear after use if left unreferenced.
The implementation provides automatic garbage collection through mark and sweep collection of unreachable anonymous objects. mooR's anonymous objects participate fully in the object system with properties, verbs, and inheritance - they're complete objects in every sense except for their automatic cleanup and lack of a number or identifier -- existing only as references in properties. They integrate seamlessly with textdumps, property inheritance, and all existing MOO features, with the new is_anonymous() builtin providing type checking when needed.
The implementation required solving some genuinely hard problems. The challenge was building a garbage collector that could safely reclaim objects in a concurrent, transactional system where multiple threads might hold references.
Mark & Sweep Garbage Collection for Anonymous Objects: The Technical Challenge
Building the GC system was the most technically complex work in this period. While ToastStunt has anonymous objects, implementing garbage collection in mooR's concurrent, transactional architecture required solving some genuinely hard problems. The challenge wasn't the GC algorithm itself, but integrating it safely with our multi-threaded, MVCC database design.
mooR's mark & sweep GC provides automatic memory management:
- Mark Phase: Full system scan to identify reachable anonymous objects
- Sweep Phase: Reclaim unreachable objects using bulk delete operations
- Reference Scanning: Tracks references in suspended tasks, object properties, and active transactions
- Concurrent Safety: Coordination with the transaction system to ensure consistency
The system does require brief pauses during the sweep phase - something I'm not entirely happy with, but writing a fully concurrent collector felt intractable given the constraints. The mark phase runs optimistically concurrent with normal operations, but during the sweep phase, new task submission pauses while the system reaches an idle state, performs object reclamation, then resumes normal operation.
Performance optimizations made the GC practical: the latest commits show major improvements in scan and delete operations, using bulk database operations instead of individual calls.
Performance Engineering Achievements
Beyond anonymous objects, this period saw multiple rounds of performance optimization across the system. The work focused on eliminating allocation overhead and improving the efficiency of common operations. Direct hashing for object/UUID combinations eliminated intermediate allocations that were showing up in profiling, while verb and property cache improvements reduced lookup times. The introduction of lazy loading for property definitions, values, and flags means the system only does work when actually needed.
Loop performance received significant attention, with optimized implementations for for x in (list) and for x in [1..5] constructs that are common in MOO code. The VM's suspend and commit paths were streamlined to avoid unnecessary round-trips to the scheduler, and branch prediction was improved throughout VM execution paths to reduce CPU stalls.
Object creation, which became more complex with the addition of UUID and anonymous objects, was optimized to reduce both the computational overhead and memory allocations in instantiation paths. The result is that despite adding significant new capabilities, object creation performance remained competitive.
While I don't have exact benchmarks to share in this post, the cumulative effect of these optimizations is substantial. The system feels significantly more responsive, especially under concurrent load.
Web Client: Major Editor & Mobile Improvements
One significant area of development that deserves its own section is the work on mooR's web client. mooR includes a single-page web application that integrates closely with the server via mooR's web-host component, which provides both a REST API and WebSocket server for real-time communication. Over 36 commits focused on dramatically improving this in-browser experience for interacting with the MOO world, transforming it from a basic text interface into something approaching a modern social platform with integrated development capabilities.
mooR's mobile web client interface, optimized for small screens and touch interaction
The verb editor received the most attention, with advanced code completion that resolves properties and verbs transitively up the inheritance hierarchy. This means when you're editing code, the system understands MOO's object model and can suggest not just immediate properties and verbs, but also those inherited from parent objects. The completion system works intelligently with object literals, this references, and system objects, making MOO programming much more discoverable for both new and experienced developers.
Syntax highlighting and code folding were substantially improved, with better support for MOO's unique constructs. A template system was added to provide scaffolding for common MOO patterns, while theme integration ensures the editor feels like a natural part of the client interface rather than a foreign embed.
Verb editor in the web client on a tablet-sized screen
Verb editor in desktop browser, in a floating window with minimap
Mobile use also received significant focus, recognizing that connecting to a MOO doesn't always happen at a desktop. The verb editor now works properly in split-screen mode on mobile devices, the login experience was optimized for small screens, and memory usage was cleaned up to perform better on resource-constrained mobile browsers.
Integration work ensured the web client could handle all the new server capabilities, including full support for UUID object identifiers and improved MCP protocol filtering. Enhanced djot and HTML links in MOO-presented content can now invoke verbs directly, bridging the gap between rich text content and interactive MOO functionality.
Significant accessibility improvements were also implemented based on a comprehensive audit. These include enhanced screen reader support with proper ARIA labeling and live regions for dynamic content, improved keyboard navigation throughout the interface, better focus management for modals and interactive elements, and support for high contrast and reduced motion preferences. The web client now provides screen reader-friendly descriptions for complex interactions and includes semantic HTML structure with proper landmarks, reflecting mooR's commitment to inclusive development tools.
Community Collaboration & Real-World Testing
One of the most encouraging developments has been increased community engagement. bitMuse has been doing extraordinary work on his own core, as well as testing his existing TorchShip DB against mooR, providing invaluable real-world testing of mooR's performance with a large, complex codebases.
His work and feedback from others revealed practical needs that drove important discussions and improvements. Docker build setups were enhanced to make testing and development easier for contributors, while source map support was added for frontend debugging to help with web client development.
One of the most valuable ongoing discussions has been about how to separate core MOO code from "user" code in databases, making core upgrades less of a hassle for MOO administrators. This led to the introduction of the dump_object and load_object builtins, which represent the beginning of a path toward better object migration and version control tools for MOO development.
This kind of real-world usage and feedback is invaluable. It's one thing to build features in isolation; it's another to have them tested against actual MOO cores with thousands of objects and complex inheritance hierarchies.
The Road to 1.0: What's Next
These developments represent major progress toward a stable 1.0 release. The anonymous object system brings mooR up to parity with other MOO servers like ToastStunt while maintaining our focus on concurrency and performance. The significant challenge was implementing this feature robustly within mooR's transactional architecture - requiring a complete garbage collection system. Combined with the UUID system, mooR now provides a fun and robust platform for MOO development.
The next few weeks will focus on polish, documentation, and stabilization as we approach 1.0. You can track progress and see what's planned in the issue tracker.
Some immediate priorities include:
- Critical Bug Fixes: For example, the task killing permissions issue (#254) that's incompatible with LambdaMOO needs resolution
- High Priority Issues: For example, type literals as assignment targets (#424) is a parsing bug that affects language compatibility
- Documentation: The mooR book needs updates covering new features, including anonymous objects, and better documentation for the web client.
- Performance Tuning: Further optimization of GC pause times and object creation costs
These are just examples—there are plenty more issues and enhancements tracked in the issue tracker.
Architectural Questions:
- Should anonymous objects eventually replace flyweights entirely?
- How should we handle object migration and version control?
Modern Core Development:
Perhaps the most significant remaining challenge is developing a modern "core" (starter database) that truly showcases mooR's capabilities. While mooR maintains compatibility with classic MOO cores like LambdaCore, we need databases that take full advantage of the new language features—lambda functions, enhanced error handling, modern programming patterns—and the web client's ability to present HTML and rich content instead of plain text.
There are currently two cores under development: my own would look more like a modern social media application or chat system that takes full advantage of web interfaces and rich content, while the other would be more familiar to traditional MUD users while taking advantage of some of mooR's new features.
Community Growth:
- Enhanced tooling to make mooR more accessible to MOO developers
- Better integration with existing MOO development workflows
- Documentation and examples for the new capabilities
Conclusion
This has been an incredibly productive period for mooR. Anonymous objects and garbage collection represent fundamental advances in what's possible with MOO programming. Combined with the performance improvements and community collaboration, mooR is becoming the thing I always wanted to build: a system that preserves the unique character of MOO maintaining backwards compatibility, while bringing it into the modern era and making it easier to extend.
If you're interested in MOO development or virtual world systems, now is a great time to get involved. The core functionality is solid, the performance is there, and we're building something genuinely exciting.
Thanks for reading, and expect more regular updates as development continues!
mooR is open source and available at codeberg.org/timbran/moor. The documentation is at timbran.codeberg.page/moor-book-html. Join the discussion on Discord or follow development through the Codeberg repository.