I've always been into MUDs since the mid-90s and every now and then I get this idea to write one from scratch (again) and I get pretty far and then I lose interest.
The new one is browser based.
The mud engine runs in a web worker and takes advantage of some of the modern web tricks to do stuff. For instance, data files (think: area files that don't change often) can be stored remotely and then cached with a service worker. This allows the MUD to run offline. But that's only fun if you're playing solo.
IO between the UI and worker is handled by message passing.
Multiplayer is handled by the MUD opening an outbound connection (probably websocket) to a connection collector host. Other players would then connect to that host and have their IO routed appropriately. The host can even be smarter: it could be a specialized Discord client, allowing users to play from there. Firebase may also be involved. I don't know.
The important bit is that this is still basically message passing, so the engine won't need to know the difference between the local user and a remote user.
The MUD database would be an IndexedDB. Probably. I haven't thought as much about that yet.
I am sure all of this is theoretically possible, at least.
YES! Another MUD programmer! I started writing one in Meteor about eleven years ago. I don't even know if Meteor's still a thing anymore... I've had a few projects in Rust that were mixtures of roguelike and MUD models, conceptually. I usually got aggravated with the models I created, though.
I really like your multiplayer idea. That sounds really clean and flexible.
The new one is browser based.
The mud engine runs in a web worker and takes advantage of some of the modern web tricks to do stuff. For instance, data files (think: area files that don't change often) can be stored remotely and then cached with a service worker. This allows the MUD to run offline. But that's only fun if you're playing solo.
IO between the UI and worker is handled by message passing.
Multiplayer is handled by the MUD opening an outbound connection (probably websocket) to a connection collector host. Other players would then connect to that host and have their IO routed appropriately. The host can even be smarter: it could be a specialized Discord client, allowing users to play from there. Firebase may also be involved. I don't know.
The important bit is that this is still basically message passing, so the engine won't need to know the difference between the local user and a remote user.
The MUD database would be an IndexedDB. Probably. I haven't thought as much about that yet.
I am sure all of this is theoretically possible, at least.