A more technical description with implementation details is here, but read this page first for an overview.
The thought here is of a MUD/MUSH style system, where each participant may run a server application on their system, which forms part of the world. Initially, at least, the design isn't concerned with game-play aspects so much as the ability to provide a distributed world. The idea here is somewhat inspired by things such as the Metaverse idea in Neal Stephenson's Snow Crash, among other things. Here I describe my basic thoughts of the mechanics of this, with minimal regard to the usage. Ideally, this system could be host to a wide range of things simultaneously; standard MUD type games, an interface into system, virtual meeting places a la IRC but with a physical mimicry aspect, whatever. A goal is to have the applications only restricted by whatever the server admins can implement.
The server a person runs represents their own customisable space. In order to link this, they make the server form a connection to another server. At the remote end, a reverse connection is also formed, allowing sensible two-way travel. Beyond this, there is no need for a logical geographical layout. While any initial incarnation of this will be text based, the long term potential for a graphical implementation may require some type of thought of layout.
There are three major things that need to be considered: the world, people, and things. Before these, however, we need something to tie them together.
All things in the environment are data objects. Most of the information is simply a list of things, what a person looks like, the URI of a room, and so on. However, there will also be the facility for code to be included in this. This allows people to create objects that have a use, rooms that register the people who walk through them, or whatever. This raises some security implications with will need to be dealt with. Most of the communication will be between a users client and the server that hosts the location that they are currently in. It will generally consist of data objects, such as room descriptions, objects and descriptions of other people. The client will handle and store all things relating to a person, such as their avatar details and items carried, so that it remains between sessions. It will also deal with executing code contained in objects, if need be.
The servers take care of providing the 'shared experience'. They are notified when a player enters a room, and handle the presenting of information to that player. They may also (if they choose) do such things as provide a list of the items and other people in the room. Obviously, the data actually presented may be constructed in realtime by the code in the rooms data object, and may vary depending on the player it is being presented to, the objects they carry, or whatever. Servers rarely need to connect each other, and only will when they are checking the status of links to other servers. This will usually occur when someone enters a room that has a followable link to another server.
The world is defined by the rooms, the links between them, and the links between servers. A group of rooms on a single server is defined by the admin of the server. The idea is that virtually every user can run a server, and the system will be able to withstand the going on and offline without any trouble. They can then personalise this server, setting it up as their 'home', or provide virtual buildings for everybodies use, assuming that they have a server that is online virtually all the time.
At the lowest level of the world, there is a room. This room can contain avatars and objects. The room has descriptions (people can request a detailed description or just a summary), and it has exits. Exits may lead to rooms within the same server, or they may be links to rooms in other servers. Note that there will be a system in place so that room authors specify that a particular room can or can't be linked to, to prevent other server admins linking to just anywhere.
In the specification for a room, there may also be code which allows the description of the room to vary based on any factor, such as the user that will be seeing it. Any code in a room will be executed on the server, and the results presented to the client in some standard form.
The layout of a given server is defined by however the admin lays it out. There is no restriction on it being sensible or Euclidean, but adding a GUI (perhaps a vaguely Falcons Eye like system) would be a lot easier if the layout was consistant. It would also make it easier for people to remember the layout.
Avatars are the representation of people. They are effectively a bundle of data that allows a server to know who they are, and to present other users with that information. As the user moves from server to server, the client provides the representation to that server. This same representation will also be provided to the other clients by the server in appropriate circumstances, such as when they are in the same room. The avatar will contain all kinds of information, including the facility for user-defined data to allow (for example) a vCard or a PGP key to be attached. The avatar is a dynamic object, and will come with a list of appropriate things, such as items carried. This will in turn allow server-specific features, such as having someone carry a key that gives them privileged access to somewhere.
There will be a facility to allow avatars to be cryptographically signed for authentication verification. By using a system such as PGP's digital signatures and web of trust, we gain the ability to ensure that people are who they say they are. This will also be of use when dealing with objects.
Note that it will hopefully be quite feasible to have programs ("bots") having avatars and performing certain functions. You could, for example have a dog that follows you and picks up anything that is available for passers-by to collect in rooms.
Objects are simply data objects that are controlled by whatever happens to contain them at the time, whether server, avatar, or another object. They will generally be represented as physical objects. It is important to avoid tying too closely to real-world concepts, and keep in mind that will be totally reasonable for objects to be freely duplicated and modified. However, with the use of crytographical signing, it will allow us to ensure that a given object is in-fact unmodified, or allow it to work only when it is being carried by a particular avatar.
This aside, objects are simply a collection of information, and possibly code. For example, you could have the latest Project Gutenberg release in the form of an object that can be copied and given to other people, and it comes with a bit of code that allows it to be saved to your hard disk, or to be read on screen. Then, assuming you wish to allow this code to be executed (ideally this means that you have looked at it yourself and know the code isn't going to mess up your system, or you know and trust whoever signed the object to not write nasty code), you can freely use the functions carried in the book object.