mooR

mooR is a network-accessible, multi-user, programmable system for building online social environments, games, and collaborative spaces. Think of it as a virtual world where participants can not only interact with each other, but also program and modify the environment itself.

mooR is a modern, from-scratch rewrite of LambdaMOO, maintaining full compatibility with existing LambdaMOO 1.8.x databases while adding significant enhancements.

Which version should I use?

Use the stable 1.0.2 release, the v1.0-release branch, or the published ghcr.io/timbran-project/moor:1.0.2 image and Debian packages for running worlds and evaluating mooR. main tracks 2.0.0-dev and contains active next-version development work.

Exception: Cowbell currently tracks main and requires post-1.0 runtime/compiler features. Use main if you want to build and run Cowbell through the bundled setup scripts.

See the Status section below for the branch policy.

📖 For comprehensive documentation, see our mooR Book.

Repository migration (July 2026): Development, issues, and pull requests have moved back GitHub (from Codeberg), but into a new timbran-project organization. Here's why. The 1.0.2 release was the final release built using the previous hosting and repository layout. Its release artifacts have been mirrored from Codeberg to GitHub along with the 1.0.0 and 1.0.1 releases.

What is a MOO? And Why?

A MOO (Multi-User Object-Oriented) is a network-accessible, multi-user, programmable system for building online social environments, games, and collaborative spaces. Think of it as a virtual world where participants can not only interact with each other, but also program and modify the environment itself.

MOOs offer a unique digital experience through:

• Collaborative storytelling where participants build a shared narrative
• Live programming - modify the world while you're in it
• Community-driven development through persistent interactions and relationships
• Rich interaction that engages users through both traditional command-line and modern web interfaces
• Complete customizability - everything from objects to commands can be programmed

What mainly sets MOOs apart is their emphasis on live programming and community-driven content creation - imagine if Minecraft's creative mode, Discord's community features, and a code editor all lived in the same space. (Or for the more nerdy, imagine if a system like Smalltalk or similar could be connected to by multiple people in real time, each contributing to a shared codebase.)

mooR is a modern, from-scratch rewrite of all of the above. It will happily import an existing LambdaMOO (or some ToastStunt) database, but offers significant enhancements and modern conveniences and is intended on bringing the whole experience into the future.

To see a live running instance, visit our demonstrator community at "Timbran Hotel".

Key Features & Enhancements

Runtime improvements:

• Fully multithreaded architecture for modern multicore systems
• Web frontend client
• Directory-based import/export format for version control integration
• Modular architecture for easier extension

Language enhancements:

• UTF-8 strings, 64-bit integers, binary values
• Proper boolean values (true/false)
• Maps: associative containers (["key" -> "value"])
• Lexically scoped variables with begin/end blocks
• List/range comprehensions ({x * 2 for x in [1..5]})
• Lambda functions: anonymous functions with closures ({x, y} => x + y)
• Symbol literals ('mysymbol) like Lisp/Scheme (optional)
• UUID object identifiers (optional)
• Anonymous objects with automatic garbage collection (optional)
• Lightweight immutable objects ("flyweights") (optional)

Modern infrastructure:

• Fast, durable, transactional database
• Support for multiple client protocols (web, telnet)
• Easy deployment via Docker

Status

mooR 1.0.2 is the current stable release. The core runtime and database formats are stable for the 1.0 series. It successfully runs databases imported from LambdaMOO with real-world workloads and has passed extensive stress and performance testing.

Branch policy:

• v1.0-release branch: stable 1.0 release line for bug fixes, stability work, and patch releases
• main branch: 2.0.0-dev feature development
• Bug fixes land on main first, then are cherry-picked to v1.0-release when safe
• Stable release tags, packages, and published images are cut from v1.0-release
• Database formats and APIs are stable on the 1.0 release branch

Repository: The primary mooR repository is github.com/timbran-project/moor. File issues and submit pull requests on GitHub. GitHub hosts the stable 1.0.0 through 1.0.2 releases and their package artifacts. Codeberg retains the repository history from before the migration, but new development takes place on GitHub.

mooR is now a monorepo. The Rust server and tools live under crates/ and tools/, Cowbell lives under cores/cowbell/, the Meadow clients live under clients/, and deployment assets live under deploy/.

Quick Start

The easiest way to get started and see what we've made is by using our quick-start scripts. These scripts handle Docker setup, resource isolation, npm workspace dependencies, and feature flag configuration.

Try out mooR with a Core

Choose one of the bundled, pre-configured cores to explore:

• Cowbell (Modern core with web-native features; requires mooR main):

  ./scripts/start-moor-cowbell.sh
  

• LambdaCore (Classic LambdaMOO core, with slight modifications for a better experience in mooR):

  ./scripts/start-moor-lambdacore.sh
  

By default, these scripts use a higher performance release build. For a faster initial compile during mooR development (but slower runtime performance), you can use the --debug flag:

./scripts/start-moor-cowbell.sh --debug

Accessing the System

Once started, the services are available at:

• Web Client: http://localhost:8080
• Telnet Interface: telnet localhost 8888

The system isolates runtime data for each core in its own directory (run-cowbell/ or run-lambda-moor/), ensuring you can switch between them without database pollution.

---

What the services are

This starts two containers:

• moor: The combined backend, telnet host, web host, and embedded curl worker
• moor-frontend: Web client served via nginx on port 8080

Connect via:

• Web: http://localhost:8080
• Telnet: telnet localhost 8888

The server comes pre-loaded with an extraction of LambdaCore, providing a ready-to-explore virtual world.

For more detailed setup instructions, see the Docker Compose Setup section in the mooR Book.

Alternative: Frontend Development Setup

For frontend development and testing, you can run the single-process moor server and web client without Docker:

npm run full:dev

This starts the moor single-process binary and web development server, accessible at http://localhost:3000. The moor process runs the daemon, telnet host, and web host together while Vite provides hot-reloading for frontend development. See the in-tree Meadow documentation for details.

Deployment Options

mooR provides multiple deployment configurations to suit different use cases:

Development & Single-Process Deployments

The root docker-compose.yml is designed for development and single-process deployments. The backend runs as one moor process, with nginx serving the Meadow frontend.

The recommended way to start this setup is via the core-specific scripts, which handle all environment isolation and permissions for you.

To start in the background:

./scripts/start-moor-cowbell.sh -d

(Any additional flags like -d are passed directly to docker compose up).

Data for these deployments is consolidated under core-specific directories (e.g., ./run-cowbell/), keeping your project root clean.

Testing Clustered Configuration

The deploy/clustered/docker-compose.tcp.yml file is an example configuration that demonstrates TCP-based communication with CURVE encryption. It runs on a single machine but shows what a multi-machine clustered setup would look like:

docker compose -f deploy/clustered/docker-compose.tcp.yml up -d

This uses TCP with CURVE encryption and enrollment tokens for host authentication. It's useful for testing the clustered setup locally before deploying across actual separate machines.

For actual multi-machine production deployments, use Kubernetes (see future documentation) or deploy Debian packages on separate servers.

Production Deployment Configurations

The deploy/ directory contains deployment examples:

• single-process/basic/: Combined backend with telnet, embedded web API, and curl worker
• single-process/web/: Combined backend plus nginx serving Meadow, with curl worker enabled
• clustered/telnet-only/: Split-process telnet setup
• clustered/web-basic/: Split-process web deployment with HTTP
• clustered/web-ssl/: Split-process web deployment with HTTPS/TLS support
• debian-packages/: Native Debian/Ubuntu packages with systemd (no Docker)

Published container images are available from GitHub Container Registry. The ghcr.io/timbran-project/moor image contains the backend binaries and compiled Meadow assets; ghcr.io/timbran-project/moor-frontend provides Meadow in nginx for deployments that need a standalone frontend image. Version and latest tags are multi-platform for AMD64 and ARM64.

See each deployment's README for specific setup instructions. If you run into problems with these scripts, please file an issue on our GitHub issue tracker as they may fall out of date with the latest changes.

For testing the current state of these deployment scenarios:

cd deploy
./test-all.sh  # Test all deployment configurations

For Developers & Contributors

mooR offers several opportunities for contribution. For detailed contribution guidelines, see CONTRIBUTING.md.

Core Development (Rust):

• Server architecture improvements
• New builtin functions
• Performance optimizations
• Protocol extensions

World Building (MOO language):

• Creating new cores and experiences
• Porting existing MOO content
• Building modern web-enabled interfaces

Documentation & Testing:

• Expanding the mooR Book
• Creating tutorials and examples
• Stress testing and bug reports

Getting Involved

• Issues: Check our GitHub Issues for current needs
• Discussion: Join our Discord community
• Experience: Visit the Timbran Hotel and explore and code
• Development: See the mooR Book for architecture details
• Support: Consider sponsoring the project to help with ongoing development

Bug Reports

Found a bug or have a feature request? Please file an issue on our GitHub issue tracker. Bug reports from main are welcome, but if you're running a world or evaluating mooR for stability, use the 1.0.2 release or the v1.0-release branch.

When reporting bugs, please include:

• Steps to reproduce the issue
• Expected vs actual behavior
• Your system information (OS, Docker version if applicable)
• Version number and commit tag/hash
• Relevant log output or error messages

Resources

• 📖 Complete Documentation - The comprehensive mooR Book
• 🏗️ Server Architecture - Technical overview
• 💻 MOO Programming Language - Language reference
• 🚀 Running a Server - Deployment guide

License

mooR is licensed under the GNU Affero General Public License v3.0. See LICENSE for details.

mooR is intended to be run as a networked multi-user system, not only as a local program. For that reason, the project uses the AGPL rather than the GPL: if someone modifies mooR and runs that modified version as a service, the corresponding source for those modifications should remain available under the same terms.

Running your own database, world, MUD, or MOO on top of mooR does not transfer ownership of that database or its contents to the mooR project or its author. The relevant copyleft obligation is about modifications to mooR itself, or reuse of mooR code in another project, not about ownership of the world data or creative content you host with it.

This applies to the main mooR software in this repository. Documentation in book/, core database content in cores/, and separately published client and schema libraries in clients/ and crates/schema/schema/ have separate licensing terms; see those directories for details.

If your intended use of mooR requires different licensing terms, contact Ryan Daum, operating as Timbran Consulting. Alternative licensing arrangements may be possible on a case-by-case basis.

Contributions are accepted subject to the contributor license agreement in CLA.md. The CLA does not change the project's open source license; it is there so contributions can be included in mooR while still allowing case-by-case alternative licensing arrangements where agreed. See CONTRIBUTING.md for details.