Show HN: I rewrote the 1990's LambdaMOO server

[cmrdporcupine]

I got my start on the Internet in the very early 90s playing with, authoring in, and programming on LambdaMOO (https://en.wikipedia.org/wiki/LambdaMOO) and similar systems. Shared virtual social spaces, with a persistent object oriented authoring / scripting language. They can be classified as MUDs (depending on who you talk to) but the focus is social, creative / authoring, and shared programming not RPG gaming.

I've always wanted to see this kind of thing modernized and further developed. Over the last 25 years or so I've worked on similar but novel & improved things, but never finished.

So I decided to just re-implement LambdaMOO and use that as a base, instead and keep compatibility as a goal, but build it out on a more modern foundation that takes advantage of multiple core machines, newer network protocols, newer connectivity methods, uses MVCC transactions for the shared database etc.

LambdaMOO is a somewhat extensive system in that it is composed of compiler, a virtual machine, an object database, user permissions system, network runtime. In some ways it's kind of like a shared, text-based Smalltalk image/runtime... So quite a bit to implement and get right before it all works together.

The big challenge throughout has been slavishly maintaining backwards compatibility so existing "cores" (databases) work.

It's not done, but it's darn close. Would like for people who are into this kind of thing to check it out, and maybe even help.

Many of the technical aspects here are still provisional, but this is the start. Constructive assistance welcome.

(Yes, it's a rewrite in Rust, but that's not really the point, even though that's a cliche that's fun.)

[NelsonMinar]

Wow neat! LambdaMOO was such an influential thing for. MUDs in general had a lot of influence, both in social media and gaming. And then LambdaMOO had the specific brief of being a social media experiment. Neat to see the tech reborn!

Pavel Curtis is still out there, LinkedIn says he recently left his job at Microsoft after 20 years. He also runs a puzzle shop: http://www.pavelspuzzles.com/site/

[sshumaker]

I talked to Pavel about taking a role in my team earlier this year (I ended up leaving Microsoft myself since). He was passionate about making the developer experience excellent - code quality, clean APIs, etc. Thats a tall order for some parts of Microsoft with 30+-year old codebases. He mentioned he was interested in rockets so I hope he found a gig doing that.

[skulk]

I love seeing projects like this! I have one too, but it completely throws away compatibility and is very simplistic. I opted for a lisp-like language instead of a lua-like language (https://github.com/sid-code/nmoo but don't look at the code, it's embarrassing).

I have some questions:

  - Does each verb call create a whole new world state that it mutates, and later commits to the database? That's the impression I get from reading the code. Does this come with a lot of overhead?
  - What is that emacs mode you're using to edit verb code?

[cmrdporcupine]

I've done the "whole new thing" before, too. 20ish years ago, tho I only have a few fragments of what I worked on back then: https://github.com/rdaum/mica being one of them I found on an old drive. Not complete.

But sticking with compatibility has allowed me to enforce development discipline, basically. And then I'll move it onwards from there. I have many ideas. And a product concept (if I could find an investor...). But I felt it important to start with a thing with existing foundation and use cases before doing the exciting stuff/changes.

Re: world state / transactions -- yeah, basically all I/O and mutations happen in a transactional context, and then at commit time conflicts are resolved; if they're not resolve-able, the transaction is retried in a new state. As for overhead, yes potentially maybe a lot, but it's also a solvable problem; this is how an MVCC SQL database (like, even Postgres) works. TLDR it's likely inefficient now, but I believe I can make it efficient. And I think it's the best way to solve the shared world state problem and still meet user's expectations of consistency. Original LambdaMOO had a global interpreter lock and only one user was mutating the world at a time, in their given tick slice. Not gonna scale.

Re: the MOO client, it's `rmoo.el`: https://github.com/lisdude/rmoo -- it's been around for a long time (25, 30 years?) and it and/or MOO.el (another emacs one) are how/why I learned emacs in the first place. I had to minor patch my local copy to make it work with emacs 29.1, though I don't know elisp well enough to say whether my patch is the right thing to do or not, so...

EDIT: I just re-read and saw you asked whether each new verb call creates a new state, and actually it's not that. It's each new command or network transaction, which can in fact lead to a chain of verb (method) calls. Recall a MUD has a command loop, so basically a transaction begins at command entry, and commits when all the invoked methods/verbs provoked from that complete.

[branon]

There's a great book about the original instance of this software, https://www.amazon.com/My-Tiny-Life-Passion-Virtual/dp/08050... fun old internet flamewars and a lot of discussion about the gender spectrum and how it's expressed by individuals online.

[cmrdporcupine]

"I was there, Gandalf, 3000 years ago"

From "A Rape In Cyberspace: "no hate, no anger, no interest at all. Just…watching. Others were more actively unfriendly. “Asshole,” spat Karl Porcupine, “creep.” But the harshest of the MOO’.. "

I was Karl Porcupine. Quite young then, though.

[fzzzy]

There's a fork called stunt / improvise that implements hashmaps. I'd love it if the list syntax was changed to use square brackets, and then if the hashmap syntax could be curly braces.

I've also wanted to give each object an isolated environment (make each one an actor), but I haven't thought too deeply about how exactly that would work and look. I've been planning in the back of my head to do this at some point in the next year, and was planning on implementing on top of the original codebase, but if there's a rust version, I'll use that.

I know it wouldn't be compatible with existing cores, but I'd be using it as the backend for a graphical ui anyway.

How did you go about converting the code? Did you just read through it, or did you start with a c to rust tool? I always thought the programmers manual and codebase were quite concise and readable.

One last thing, there were patches in the 90s to add journaling on top of the checkpoint system... Did those ever get merged into the main codebase?

Thanks for doing this! I'm excited!

[cmrdporcupine]

"How did you go about converting the code?"

Mixture of approaches. No automatic translation. After bringing over the AST and opcodes, etc most of it I wrote without reference to the original code, with the functionality in mind. Where MOO was doing something a bit funky, I often wrote code with a second window open to look at how they were doing it. But in general it came down to running a core over and over again and finding how it broke. MOO has some unexpected behaviours in spots that grew over time. If I were to start over with this, I'd invest the energy in ripping out parts of MOO and turning them into a library and then write tests that run them side by side through the same opcode sequence and compare output. But MOO was built quite monolithic, so that's hard.

Re: maps, MOO's value types are immutable/copy-on-write. So while I want a map type, a typical HashMap may not make a lot of sense, as it would be doing a deep copy on each addition. Some kind of functional persistent map would probably be appropriate. Syntactical sugar for maps would be nice, and I will probably add it later. But I'm also not as concerned with the MOO language itself, as I see it as only one language among potentially many to run on the system.

"I've also wanted to give each object an isolated environment (make each one an actor)"

Maybe related; I intend on reworking the object reference system such that object numbers and $sysobj-references are a form of published capabilities. That is, I will be introducing "private" objects with some sort of signing & publishing & capability style references, and slowly deprecating object numbers. But that's all post 1.0 stuff.

[fzzzy]

I see after reading more that it has a modern concurrency and object database implementation. Really cool!

Websockets and utf8 as well. Lovely.

[trollied]

Hands up if you know what tinyfugue is :)

[cmrdporcupine]

I almost used it in the screenshot, but the live editing of code with emacs is way hotter :-)

Check out blightmud. It's kind of tinyfuge-the-next-generation.

[blipvert]

Now that is a name that I’ve not heard in a long time …

[tromp]

I spent a good fraction of my years of MUD playing time on writing ever more elaborate tf macros to automate as much MUD play as possible.

    $ wc ~/tfrc
    878    6634   53336 /Users/tromp/tfrc

[kevinsync]

TinTin++ over here

[erikarn]

yup, and someone's looking after it, and i'm submitting fixes and new features to it in 2023.

https://github.com/ingwarsw/tinyfugue

-adrian / erikarn

[stavros]

MUSHclient or nothing.

[VadimPR]

Mudlet represent :)

[rhinoceraptor]

I do some maintenance for a pretty old LambdaMOO instance that runs enCore, which gives it a (very 90s) web UI, along with a browser-based telnet client. Of course, that telnet client was a Java applet, so I replaced it with a websocket console, and a websocket server that proxies telnet to LambdaMOO.

One of the bigger challenges with the web UI is that HTTPS isn't really optional anymore, and the enCore database has a ton of `http://` links. So it requires a reverse proxy in front that can rewrite those, luckily in Nginx it's possible to use a small Javascript program to do it.

[smirya0]

Very cool! Is it still using cooperative multitasking? My understanding was MOO verbs/tasks run until the verb does suspend/fork or an input() call happens or something like that, or until the verb runs out of "ticks" and is killed by the VM. How do you do it?

Does it use async I/O / is it one thread still?

You might find this conversation interesting about multi-threading in LambdaMOO: https://groups.google.com/g/moo-talk/c/omF68ZM9rZc/m/B3f-jj4...

[cmrdporcupine]

It's multithreaded with multiversion concurrency control over shared state. Each command invocation is a new thread, in a new transaction, and the database attempts to resolve any shared state conflicts at commit time.

There's still ticks and time limits, but they're there to impose time / resource limits, not used to control access to shared state.

Tick-based time-slicing to the database is one reason why LambdaMOO (and its offshoots like toaststunt, etc.) has intrinsic scalability limits. (In the 90s, LambdaMOO-the-actual-MOO used to lag like a son of a bitch under load...)

(This is not to say the actual impl of MVCC I have right now is ideal. It's a work in progress. I just defer to RocksDB's conflict resolution, and it is built on assumptions of "single writer, multiple readers" at its foundation, which isn't ideal for what I'm doing... )

[nrr]

This makes me smile a lot. Whenever I pick up a new programming language, one of the first projects I tackle is writing a port of a similar MU* server because of the same breadth of concerns, so it's very nice seeing someone else recognize the complexity and take it on as a worthy challenge. (Though, this goes the extra mile and modernizes things; I've seldom accomplished that.)

I hadn't looked at doing this in Rust yet, so it'll definitely be interesting to give the code a read, particularly with the focus toward modernization.

[Shekelphile]

Good luck. As someone who used to work on a lambda-derived MUD it's great to see a little life left in that community. The original server was horribly outdated even 20 years ago.

I also found this project randomly on github at one point, not sure how far along it got to being usable: https://github.com/verement/etamoo

[cmrdporcupine]

Yes it's funny I came across that one only a couple weeks ago -- I may have had wind of it before but it didn't sink in -- and it's basically what I'm doing (well at least the first part of what I'm doing)... but in Haskell. It looks like the author got pretty far along, too. But no new commits in some time.

If I'd seen that a year ago, I'm not sure I would have started. Hard to say.

I admire Haskell, but I could never really grok it.

[clouddrover]

To see the original LambdaMOO in action:

telnet lambda.moo.mud.org 8888

[tromp]

Is there still a connect-4 game somewhere in a games room?

[fleeno]

Is there anything else new or interesting going on in the Moo/Mu* space right now?

A while back I wrote a MU*-style system in Ruby, using js as the scripting language. It has a web based tool that gives object owners a URL for each object, which lets them edit the attributes and code in a better way than just line oriented editing. It also lets external services call back to that object to trigger actions.

I never did anything much with it though.

[jonmarkgo]

This is very cool! I have a MUD (that still has a fairly active playerbase) written in straight-up C. Been working on it 20+ years now, and always had some curiosity about rewriting it.

[zellyn]

I'm so happy someone did this. Rewriting LambdaMOO was on my long-term (mostly not going to do before I die) TODO list of project ideas! https://zellyn.com/page/projects/todo/

Very fun. I expect the parallelism will also be strikingly better with a modern design and implementation!

Very nice!

[mindcrime]

I've always wanted to see this kind of thing modernized and further developed.

I've had similar thoughts, so let me say "Congrats, this is awesome"! It definitely warms the cockles of my heart to see work like this. I just wish I had the free cycles to work on something similar (or even contribute to your project). But there are too many demands on my time right now. :-(

[gilmore606]

How are you handling concurrency/multithreading? I wrote a lot of MOOcode back in the day and often explicitly relied on the fact that property values couldn't change out from under me during a verb's runtime.

[cmrdporcupine]

Like a database (because it is one). MVCC. Full transactional isolation. Nobody sees your changes until successful commit.

This is what MOO was effectively mostly doing already, through a big ol' single threaded interpreter we all took turns on. Only one task was running at a time (sort of, you could suspend() and return later, and then all bets were off on consistency). It's just... that doesn't really scale too well.

[cpeterso]

Suggested alternative names: “rooms” or “rumor”.

[thelibrarian]

For a name, how about LambdaROOM? Adds an 'R' for Rust, and is also a reference to the concepts of rooms in these games.

[worthless443]

Personally I wouldn't make one part of the name linked to the underlying development language, we make software for the users, and the source is often not part of something users have to deal with. Just as is sounds good in my opinion.