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 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"
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.
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 188.8.131.52) 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.
June 1999 Imaginary Realities, the magazine of your mind.
© Copyright Information