The copyright situation for this article is unclear. It does not belong to the author of this site. Please see the copyright notice. If you have information about the copyright contact me!

Problems with mudlists

by Adam Wozniak

A brief and incomplete history

In 1994 Scott Goehring published the last "Totally Unofficial List of Internet Muds". Goehring's list was considered definitive. The last issue contained only 450 muds.

Shortly thereafter, I started "Doran's Mudlist". I made several attempts to contact Scott and borrow his code. This was largely unsuccessful. Any mail sent to him which had anything to do with the mudlist was immediately discarded. Scott, it seemed, had had enough. I wound up writing my own code, but modeled Doran's Mudlist largely after Scott's list, with muds broken down by server code base.

Bishop Doran

Bishop Doran and the Pope.

Around 1996 I lost interest. I had been booted off of two campus systems for running Doran's Mudlist, and generally didn't mud anymore. Publication became erratic. I had stopped mailing lists to people. I had had enough.

About this time there were over 1000 muds on the list, and several smaller lists had popped up which concentrated on specific server types, or specific role-playing themes. Lists like "Amberyl's Automated Mush List" dominated.

Soon after, Andrew Cowan started "The Mud Connector", built on the hype of a newly emerging World Wide Web. Today this list is arguably the most popular mud list today, sporting more than 1300 muds.

Personally I found The Mud Connector unsatisfying. I felt the site was too "frilly" and disliked its advertising. In addition, I felt it was incomplete because it only listed muds which had been submitted by their administrators.

In 1997, with the help of Indium, I revived Doran's Mudlist, this time with a web interface. With Indium handling the mundane database additions/corrections, and me doing code maintenance, it became interesting again. Soon thereafter Indium became pregnant. Between that and school, neither of us had time for the mundane database maintenance.

So I was stuck; left with a deep sense of dissatisfaction with the current state of mudlists on the Internet and nowhere near enough time to maintain a mudlist the "right way". A new approach was clearly in order. This is how mudlinks:// was born.
mudlinks:// design

The problems of running a mudlist can be broken down into four parts: enumeration (how many muds are there?), classification (what do we know about each of these muds?), organization (how do we tell people what we know?), and maintenance (how do we keep our data up to date?).

My lack of time and general laziness required that mudlinks:// cover all four of these bases in a very automated manner. The biggest problem for Doran's mudlist had been enumeration and maintenance.

How many muds are there? There are basically two approaches used to enumerate the muds on the Internet : active and passive. A mudlist with an active approach goes out and tries to locate new muds. A mudlist with a passive approach waits for mud administrators to tell them about their muds.

Arguably, a passive data gathering method leads to higher quality data. Mud administrators general know all there is to know about their mud. However, I did not want to simply duplicate The Mud Connector's efforts, and my general disdain for low mud counts drove me to an active method of data gathering.

The problem of efficient automated data gathering plagued me. Believe it or not, most of the time spent maintaining Doran's Mudlist was spent rejecting bad data from users. People constantly fed us outdated and inaccurate information. Active searches constantly yielded old information. Even today I frequently find data I published 5 years ago, often with someone else claiming copyright (*sigh*).

The fundamental unit in the database for Doran's Mudlist was "a mud", which consisted mainly of a hostname, IP, port, name, and type (other fields were added later). As it turns out host/port and IP/port are not very good unique identifiers for muds. A host on the Internet may literally have dozens of hostnames, multiple IPs, dynamic IPs, and even dynamic hostnames. A little known side effect of most telnet implementations even allows you to add multiples of 65536 to port numbers and still reach the same service. Some mud servers listen at multiple ports. Some hosts run multiple muds. Some mud servers even have IP tunneling/forwarding set up on multiple hosts across the Internet. Poorly maintained DNS entries (the system which maps human readable hostnames like foo.bar.com to IP addresses like 1.2.3.4) make the problem even worse. All these issues frustrate automatic data gathering schemes. Each and every addition to Doran's Mudlist had to be hand checked by a human (me or Indium).

For mudlinks:// to automate this, a new approach was needed. I discarded the idea of "a mud" as an atomic unit in a database. After much thought, I settled on "a URL" as an atomic unit. The popularity of the world wide web had made URLs of the form http://... ubiquitous. telnet:// URLs weren't much harder to find. URLs have a definite format, and can easily be parsed out of any text document. This vastly simplified the two problems of enumeration and maintenance. I could search the web and other sources for telnet:// urls. I could list http:// URLs for web pages containing telnet:// URLs, on the assumption that web pages which refer to a mud probably say something about the mud also. I could classify pages with a large number of telnet:// URLs as mudlists. I could write simple scripts which take a URL as input, and try to connect to them.

Maintenance is then kept to a minimum. Automated scripts can recheck the URLs on a weekly basis. Bad URLs are held for a period of time, and then discarded. URLs are also checked against DNS entries, and groups of DNS equivalent URLs are grouped together. Groups of DNS equivalent telnet:// URLs are considered to be "a mud".

This also eased my organization problem. The data gathered by connecting to the URLs is saved, and can be searched via a web page. mudlinks:// gathers web page contents and mud welcome banner contents. Various forms of regular expressions could be used to search.

The only problem left is classification. In Scott Goehring's day muds were classified pretty much as LP, aber, tiny*, or other. Tiny* muds quickly fractured into TinyMUCK and TinyMUSH. Diku came on the scene and spawned its own offshoots. Whole articles can be written about the growth of mud server code. Today things are even stranger. There are a number of LP style servers (DGD, MudOS and company), each of which may be running a number of freely available mudlibs (Nightmare, Heaven7, etc...). How should these be classified? Mudlibs even exist to emulate MOOs. What about LP drivers running custom mudlibs? A number of mud administrators who are running relatively stock code bases claim to be running "heavily modified" servers, and demand to be listed as "custom". The USENET newsgroup rec.games.mud.diku is filled with flame wars about this very topic.

In addition, the wants and needs of today's mudder are more sophisticated. They want to know if muds allow player killing, or charge rent, or have feature X, Y, and Z. The unfortunate aspect of all these classification problems is that no automated system short of a full blown artificial intelligence could ever hope to solve them. This data is best gathered in a passive manner. As much as I hated to admit it, I had to build in some sort of automated passive data gathering, at least for classification purposes.

An automated passive data gathering mechanism has several design problems to overcome. How do you know if the information is good? In several instances in Doran's Mudlist, players would send us information such as "Mud X allows multi play", and angry administrators would send us hate mail the following week telling us they did not. Whatever automated system we chose had to have accountability built into it. Email would not do. Simple email can be easily forged, and there is no easy way to automate management of public/private key encryption mechanisms. Web page submissions suffer from similar problems.

I also wanted to expand the range of what could be said about a mud. Doran's Mudlist had a list of features which could be check marked. As you can guess, we were constantly adding new features. This system was also limiting. For example, a mud was marked as either allowing player killing or not. There was no way to say things like "PK allowed but discouraged", or "PK only outside the main town". Whatever passive data gathering scheme I came up with had to be extremely flexible.

Another design consideration was related maintenance aspects. To automate this, the person who submitted information should be able to change that information, but not information submitted by others (even if the information is about the same mud).

The final solution to all these problems is elegant in its simplicity. As mudlinks:// scans for URLs, it keeps a special lookout for files named mudlinks.txt. These files, after a bit of reformatting, are imported wholesale into mudlinks:// and can be searched like any other data file mudlinks:// maintains. Part of the reformatting embeds the http:// URL into the imported copy of the mudlinks.txt file as an html comment. If a user or mud administrator finds an entry they disagree with, they can view the document source and find out where the information came from. mudlinks:// re-imports these files on a weekly basis. If you are a mud administrator, and you want to add free form text information to mudlinks://, all you need to do is create a file named mudlinks.txt on a web server somewhere, then tell mudlinks:// about it (via add URL, just as you would add any other http:// URL). mudlinks:// will then reread the information on a weekly basis and import it into its data files. If an administrator wants to update the information, they simply modify their local mudlinks.txt file. mudlinks:// will pick up the change within a week.

This brings me around to my final comment, or the real reason mudlists suck. To date only 3 muds have bothered writing mudlinks.txt files, out of 3,400 muds listed. While to some large degree this can be attributed to the young age of mudlinks://, I fear I will never see more than 1000 or so mudlinks.txt files. The Mud Connector only lists 1300 muds. The next largest list has just under 1000 muds. The strong differences between active and passive data gathering will always doom mudlists to either a little information about a lot of muds, or a lot of information about a few muds.

A truly good mudlist would have a lot of information about a lot of muds. To do this would require a rather large investment in resources; a human performing active data gathering. This is an investment which I don't think we're likely to see in the near future.

Adam Wozniak has been running an online mudlist for longer than most people can remember. "Doran's mudlist" was the first incarnation and now he runs mudlinks://.