This page describes the more technical and implementation-related details of the Distributed MUD. It will stop short of defining the data exchange formats, but should otherwise end up reasonably complete.
All the examples of commands and so on here should be regarded as being the equivalent of psuedocode, and are just to provide examples of how things might look.
A server is a program that will listen on a port that accepts connections from other servers and clients. In the context of the internet, it will be specified by a URL such as:
dmud://dmud.kallisti.net.nz/anteroom
Which provides the protocol, the hostname of the server, and the room. Each room on the server will have a unique identifier that allows it to be accessed by the client. Any security, such as ensuring that people always enter by a certain path, or ensuring that they can't get to certain rooms will be handled by the server.
Ideally there will be very little communication between servers. What will be necessary however is the establishing and removing of links, and verifying their status.
How link creation is initiated is up to the server itself. Probably someone with the required permissions will execute some command to tell the server they are on to form a connection. Assume that the person making the connection is currently at dmud://dmud.kallisti.net.nz/mainroad. This command would be something like:
make link to dmud://another.server.com/entrance
The server would then connect to another.server.com and ask it if it will allow a link between dmud://dmud.kallisti.net.nz/mainroad and dmud://another.server.com/entrance. If the remote server agrees to this, then a link will be formed. This will involve the exchanging of descriptions of how the link should be shown. This means that each server can provide a description of the link. Obviously, this could be overridden by the server at each end of the link. Note that this procedure will normally result in a two-way link, so that if an avatar moves one way through the link they should be able to return to where they came by following a link from the other end.
There will be situations where the remote server won't want a link to be made to the given location, but another location will be acceptable. To deal with this there will be a facility for negotiation between the servers as to where the link actually ends up.
The process for removing links will be similar, but there will be less need for verification as the remote end can't really stop the local end from removing a link. It will be accepted that servers won't be online all the time, so the best solution for this is to store the removal request for a period of time and retry it every so often.
When an avatar enters a room containing a link, the server will connect to the remote end and determine if the server is currently running or not. If the remote server is offline, then it will not be accessable to the avatar, probably this will be shown by giving a different description or something similar. For network performance reasons, this server status information should be cached for a period of time so that the connections aren't initiated every time someone enters a room.
The client will be in communication with the server holding the rooms that the user is in. As all objects the user is holding are stored in the client, there is no need for any other communication. Note: a future extension may be to establish user-proxies that mediate all the communications on behalf of the client. This would allow things like objects to be stored in a central location, and the user can use any client on any computer to access their data.
It will also be possible for a person to be in more than one place at a time. This can't be restricted between servers (i.e. there is nothing stopping someone from being connected to multiple servers at once), but it may be restricted within servers, at the discretion of the server administrators.
Typically a 'visit' consists of one constant connection between the client and the server. The server may wish to force all people connecting to a particular location, and they can navigate freely after that, or it may allow them to 'bookmark' any location within the server and the user can jump straight there. Another alterative to a constant connection to define a session is having the server generate a session ID that is provided to the client, and then given back to the server for each connection that is part of a session, similar to HTTP cookies. However as there will be both TCP/IP overhead, and authentication overhead for each connection initiation process, keeping one connection going as long as is possible is strongly recommended.
The bulk of the server<->client communication will be navigation of rooms, as the user moves around within the server. Typically this will be done by the room presenting a list of links to other rooms, in the form of dmud:// URLs that the user can select. This selection will generally be presented in the form of 'north, south, blue door' or some other directional or location terms.
As well as this, the server will provide data to the client on the objects that are here, other people that are here, and room descriptions. All communications between people in the same location will go via the server. While this allows the server operator to snoop on conversations, there will be the facility for public-key security at multiple levels of the system, making this less of a concern.
The client won't be a dumb text-processor as is typical for a simple MUD client. The data transfer will all be in XML, and so it will be required to take this XML and convert it into a form suitable for local viewing, such as a webbrowser does. It also must have a robust security model, and take suitable precautions such as treating all data from a server untrusted unless told otherwise.
When the user requests a connection to a server, using a dmud:// URL, the client connects to the server, receives the response, parses it, and presents it to the user.
Another main function of the client is to execute the code provided to it, if it is able to be run in a highly restrictive sandbox, or if the user has determined that the author is to be trusted.
Finally, the client will also maintain the authentication credentials of the user, providing verification to the server that the user is really who they claim to be.
In a system like this, there is quite a strong need for two types of security: preventing people from seeing data not intended for them, and verifying that people are who they say they are (and, an extension of that, people verifying that objects that they created haven't been maliciously modified by someone else). The use of public key cryptography provides solutions to both of these issues.
Every user will create a public/private key pair that identifies them. For the discussion here, it can be assumed that a key such as used by GnuPG or PGP is what's used. Everywhere the avatar goes, the public key will be available. This will be used to allow secure communications between multiple users on a server. It can also be used to create objects that only the designated recipients can access.
However, of more use will be the use of the key pair as a digital signature. This can be used to validate a user is who they say they are, and so provide access to restricted areas, special services, or whatever. A significant application of this will be in signing objects so that the end user can decide how much they want to trust the code embedded in it, based on the reputation of the author.
There will need to be a system created or found to allow the signing of XML in such a way that the XML can be transformed (within limits), and the signature remains valid. Ideally an XML stream should be able to be loaded into a parser, and then written out again, and still retain its signature. It would be even better if it could be validated from within the DOM. Note: some technologies to look into: W3C xmldsig, W3C XFDL, another XML signature thing.
An overarching security architecture will need to be designed with the following points: