As I've retired my duties as GM lead and stopped being involved in development as well I think it's fair to note down some ideas that I think might be helpful in future.
I have worked on a proof-of-concept for this idea in python for a while and I think it can work with some tweaking.

The problem is following:
It is hard to judge whether two characters ingame are played by the same person or not. As GM you still can check whether the IP is the same, but as player you only can judge by the way they act with factors taking into account like speed of typing, spelling errors, usage of words, inside knowledge and so on. The later also only works if you know the two characters very closely.
As GM you often don't have this close view onto these characteristics; so if someone logs in with a different char and a different IP it's near impossible to tell for sure it's the same person or not.

This issue is the same for any application with identity being a critical factor, therefor approaches to the problem also are manifold:
- using the MAC address
- using other hardware characteristics like harddrive number, CPU and such
- using unique accounts that are sold in RL
- registering accounts by creditcard number
- registering by making a payment via money transfer (paypal, etc)

Any of these measures however can be circumvented, are massively intrusive into the user's privacy and don't even tackle the issue directly - to identify the user while they use the product.

The idea now was to use what's already there: the typing of the player when they play the game.
For this all keystrokes are recorded client-side as a pair of (previous_stroke,current_stroke), which are used as keys for a dictionary to record the according timing and the number how often the combination was entered.
If the combination is entered again, the timing is adapted either by averaging or using a weighted term.
Every now and again the whole dictionary client-side is read out and put into the form of a list sorted by timing (fast combinations first). All combinations that were entered only once or few X times are left out.
This sorted list is sent to the server, where a similar list is recorded for any account and adapted each time a client reports back.
The sorted list provides a form of frequency distribution that gives insight into which combinations of keystrokes are trained best by the user, which is a unique feature which can be used to distinguish one player from another and also who is using a bot and who doesn't.

I have used python with Tkinter to make a prototype for this, which worked quite well in the first tests I ran.
To reduce the load on the server it might be possible to identify the combinations used in English most often and use this as base for the distribution and then take a discrete function to describe each user's unique typing-fingerprint (utilizing fast Fourier transformation for example).

I ran into some issues while attempting to update the mediawiki software for pswiki.xordan.com. I hope to have these resolved by tomorrow.
Backups of the DB and files are kept, so our butt should be covered if all fails.

Greetings, if the title includes [YES] we are recruiting, if it includes [NO] we currently need no new members so try back later.

Beyond that message we would like to take a few moments to explain the process, why we are recruiting, what we expect from all our applicants and what you can expect from us.


The Process

The starting point of an application to be a GM is simply contact one of our current GMs. The best methods are by private message (PM) on these forums, on IRC or in game. That GM will give you further details on the application and answer your questions regarding it to the best of their ability. They will also request you to send them a PM giving a short written summary of:

1. Basic information including your real name, country and time zone, age
2. Previous GM experience (if any), also meaning moderation of forums or any kind of game
3. Time playing Planeshift (when you started, how much you play during the week)
4. Why you want to be a GM (this is very important)
5. Proficiency in English
6. Roleplay experience (tabletop, fantasy novels read, other MMOs/RPGs played)
7. Any additional qualifications you think may be relevant (experience with computers, social jobs, etc)

The next step (if you are deemed suitable) is a 'hot-seat' interview, this will comprise 3 or more current GMs interviewing you on IRC to decide if you are to be allowed through to the final step.

The summary and logs of your hot-seat will be posted on the private GM forums and discussion will then take place regarding your suitability. Once a consensus has been reached you will be informed of the decision. If it is positive then you will be asked to make yourself available for a one-to-one interview with Kerol, the GM team leader. If the consensus is negative, you will be informed of the decision, and we will endeavor to explain to you our concerns.

After your final interview with Kerol, he will make a decision and you will be informed at the earliest opportunity if you have made the grade.
If so, you will be trained in the arts of GMing for a probation period on GM level 1.


Who We Are Looking For

Requirements:

The first thing is you must be aged 21 years or over.

You must have a good level of written English and be a good communicator. You must be a team player, we work as a team, so sometimes decisions will not go the way you might like, you will sometimes just have to say your piece and then follow the team's decision if you like it or not.


Currently Seeking:

We are currently aiming to recruit more women to create a more balanced, community reflective, team. Also, we currently need more GM Team applicants from Australia, New Zealand and Eastern Europe and Asia. We can have some problems covering certain times of the day (all  those in those locations who complain about never catching events? Now you can do something about it ;op) which is why we require people from these locations in particular. Please by no means let this stop you applying if you are not from these locations or of the 'correct' gender, your application will be considered in exactly the same way as those who do fulfill these encouraged groups.

The ideal situation would be for 10 - 15 active Team members around the world, aiming to have about 5 per block (America/Europe/Asia) capable of running events in game.


What You Can Expect From Us

We will handle your application in a fully professional manner. Any information, decision made, or discussion will NEVER be made public. It will only ever be seen by a few members of PS staff.

If you are chosen to join the team you can expect to be received in a friendly manner by the current members, trained in the protocols, commands and rules you will be required to understand while being a GM. The learning curve can be steep sometimes, but you will (nearly) always have someone around who you can ask if a problem arises and you are not sure of how to handle it. However, should something happen and you don't know what to do and have no one to ask, just step back and leave it alone, its better to do nothing than make a situation worse.


Let us take this opportunity to thank you for reading this information, and also to encourage you to have faith in yourself and apply, you have nothing to lose, the worst that can happen is you won't become a GM, but you aren't one now ;o)

-The GM Team

JosePhoenix gave me this link and I think this should be a mandatory read for all (not that I can force anyone to click a link but one still is allowed to wish...)

http://headrush.typepad.com/creating_passionate_users/2006/12/how_to_build_a_.html

Enjoy reading! Hope to see the PS community continueing to grow in a positive way just as it did and does 

It took time, effort, friends and Talad for the OK, but finally it's ready.

The PSWIKI.

From now you are allowed, no called on to edit the Quickguide, the Players Guide, the FAQ and the ingame help directly in this wiki.
The goal is to improve those documents. To make the quickguide even quicker, Players Guide more thorough and better, the FAQ more complete and up to date, and finally the ingame help to include everything a player might ask while keeping it as simple as possible.

Please keep in mind that those documents are official and will be reused in the way they are being used now. That means:
- They are under the PS license, so don't copy&paste them in other contexts just like that.
- If you plan to do major changes on one doc, please discuss them beforehand, here on the forums - a seperate thread on a specific doc seems most appropriate to me; But please do so! Don't hold back your ideas!
- If you see a typo or some strange grammar, go on and correct it directly in the wiki!
- Keep in mind that those docs should be understandable by 9 to 99 year old people - KISS (keep it simple and stupid)!

There is no deadline on editing those docs, but I like to give you a timeframe. I will give those docs to Talad in about one month, for reviewal and to decide whether it was worth the hassle or not. So don't feel pushed 

Thanks in advance to everyone who helps in this important matter!

Edit:
Fixed link.

After the CS conference I thought about the structure of PS (thinking of the more or less detailed presentation by Talad) with the different layers and having a seperated psserver and psnpcclient. The fact that psserver needs only a tiny bit of ressources and that npcclient doesn't have to be on the main machine and also isn't limited on one npcclient makes the network the actual bottleneck.
The question wasn't answered how much network traffic PS causes, but I think it can't be little.

A few thoughts and possible solutions:

1. In the past I already suggested to rebuild the chatsystem by making it a client-to-client system (for instance with a modified jabber client built into PS), thus halving the latency for chat communication and also reducing lost chat packages caused by too heavy traffic on the line to the server.
The biggest problem there is the possibility to circumvent chatcontrol by GMs/devs and possible faking of chat messages (if /report sends the incoming chat to the server, for instance). This could be solved by signing the chatmessages and validating.
As I guess that (my favoured) solution will probably not be implemented, I suggest an alternative.
A QoS (quality of service) heading in message-type packages. As far as I know (I'm no network engineer) this can be implemented pretty easy with an IPv6 compliant client.

2. For the far future when different levels in yliakum will be implemented, I suggest to have a server for each level seperately. For "world-wide" communication, the message could be send from one server as broadcast to the other servers, that broadcast to the players.
This system actually could also be implemented for huge areas with a lot of NPCs and players. Communication that requires the servers to communicate inbetween will be slower, but the network load on one server will be lowered a lot.

3. One thing that could help now already is to have the client load all and evey char related data from the server on startup (everything that would require a server-query on event like opening a window like guildwindow, stats/skills) and make the server send updates only on changes of those data (only the diff). That would eliminate the latency when opening a window and minimize the need for server queries during runtime for those events. The initial loading of this non-essential data to the client could be done with a low priority in the background while the client already is up and running, thus also not requiring a longer startup for the client.
This could also be done with /who. Loading the list when the client fires up and after that, only update the clientside if anything changes, and not requiring the client to query the server. This would also eliminate the spam effect when repeating /who a dozen times while keeping the client always up to date.
Entering /who would show the list that already is on the client side, and would has no effect on the server.

A good implementation would work here with transactions and maybe with periodic checksum checks.

4. Make the client calculate space in which the graphics would actually not show an entity and send back that data to the server. If there are entities in that space, don't send location updates for those entities to the client. I would say to have this space-calculation and exclution of location updates only on space which is very far away (which won't be shown by the client's graphics at all for a long while) and when the player has not left a defined cube for a longer while (for instance when moving only minimal, in circles or standing about). The cube would be updated on the client every 5 sec and check if the player has left it. If not, do the calculation of excluded spaces and send it to the server. When the player moves out of the cube, usual location updates resume.
Actually this method would only need a little bit more CPU by the client, for the cube and the calculation of excluded space. Effort on the server to check if entities are in that space is minimal, the reduced network load shouldn't be underestimated, though. I always thought it stupid that I got lag by looking in a direction where many people must be standing, but I have not seen anyone. This method would minimize that lag.

As GM, one is confronted all day with improper names, just silly stuff and other appearant violations of the naming policy. Most people however overlook that the naming system itself is getting more and more inadequate for the growing numbers of players and characters.
This post is how to improve the name system itself, NOT the naming rules.

The alphabet has 26 characters. A good forename has about 5 characters. 26^5 = 1188376 possible names (not regarding the forbidden names, repeating characters, unpronouncable names etc.). At this moment we have 246262 accounts on laanx. This number * 4 (possible chars per account) = 985048.
By that simple calculation, leaving out all the restrictions, limiting the number of "good" names considerably, it is more than obvious that the current naming system is getting towards it's limits.
As PS grows each day in numbers of new players, the need for new names grows. With this system it is only doable to increase the number of allowed names by increasing either
- the number of possible characters in the alphabet
- increasing the length of the names
- allow formerly forbidden names (by changing the rules)

The first cannot considered seriously as it is not easy to type foreign characters on european keyboards, for instance.
The last is not an option as it is unlikely that they will be changed. Besides that, allowing banned names would only have a minor impact on the number of valid names.
So only the second variable is an option. This however is not limitless. In RL, a name with 8 characters or more is simply not practical.

A reworked system would have to increase the number of valid names by a linear factor or even exponential.

I propose following changes:

1. allow multiple same forenames by adding a (I), (II), (III) after the forename in /who and buddylist, indicating the registering of the names in the time flow.
2. allow middle name(s). Two or more forenames seperated by space could be handled as one internally. It would show up in /who and buddylist as one big forename,
but name completion would only complete the first forename.
3. to have a possible "location field", similar to medieval names like "Fred of the field". One could implement that in the CC (charcreation) by giving a list of possible locations in Yliakum and letting the player choose the location of birth. If a location was chosen, it may show up as addition to the name in the chardesc (not on the label, see below), but as additional information for the players by /who for instance, and the system, in order to allow multiple forenames, but with different birthlocations and keeping names unique.

I also propose a change in the naming system that won't multiply the number of valid names, but won't affect the number of valid names either and will probably solve the ever ongoing question if one should have a birthname as name on the label or whether nicknames for labels are allowed.
The solution is to have both, a birthname as required unique identifier and an optional nickname that mustn't be unique.
As stated above, the birthname may be pretty long, including birth location, multiple forenames or even a latin number as counter for the occurance.
If that all were implemented, it would be overkill to have all that in the labels. That's also why I propose to have a nickname that will be shown in the label.
As implementation, there could be an optional nickname-field in the CC in which the player may initially enter his wished nickname, apart from the birthname.

The above may be sufficient for solving the problem with the number of valid names and also solving the nickname-birthname problem. Related to that, but not about the problem above is my following proposal about the buddylist (BL) system:

A long wanted feature is a mirrored file containing the BL that is being stored on client side, not only on server side. Initially, those two files must only contain the birthnames as identifyer.
The birthname list on the client gets synched with each login.
The file (or another file, refering to the mirrored file) on the client side may contain the initial nicknames.
The BL shows only the nicknames in that file. Rightclick on a buddy may open the option to change the shown nick. Changing the nickname that way would only affect the local client. However, there could be a built-in routine to check each time a new label pops up if the player is already in the BL and if yes, then show the custom nickname also on the label.

This way it would be possible to modify the nicknames offline, have custom nicknames with each character/installation but not having the disadvantage of a client-side only BL. This solution wouldn't require additional space on the server neither.

I hope I wasn't too confusing

I worked out this minigame idea for PS the last few days with help by some friends (Seperot, Kanalal and Nilrem, mainly).
I tested it out myself and made the rules clearer and simpler, but it still needs a lot of testing.

However, I talked to Talad and he was positive about this little project (otherwise I wouldn't post this here).
The infrastructure for minigames is in development recently, so there's a chance that this idea is included ingame sooner than later.

If you have friends, family to play with or just want to take a look at it and test out by yourself, feel free to download it

Here you can download the rules and board (the board jpg isn't as clean as it could be, but it shouldn't be a problem):

http://66.83.137.5:27967/chessrules.r6.pdf
http://66.83.137.5:27967/octarchchess.jpg

Thanks to Rerogo for hosting the files ^^

If you find any problems, uncertainties, typos or only want to send me a strawberry, just  pm me