But how about chatting to people on MSN or ICQ from an IRC window? or AOL or Y! through an ordinary web page, nothing needed to download? That would probably be a bit more interesting.

Well, welcome to M-Chat.

M-Chat is a server (actually a group of servers working together) that allows connections through all of the already mentioned protocols, and more.

There are many many other chat servers out there, many good, and some of the good ones are even as free as M-Chat. There are also ways of chatting between some of these different services, or chat sites that come with HTTP and IRC already set up.

So why M-Chat?

There are a number of reasons. Most of the features you'll find in other chat systems, but not all in one place.

• M-Chat allows connections via a great deal more methods than any othe chat server I'm aware of. You can even log in with ssh and use a almost shell/filesystem way of chatting. It will probably get most interest from the curiosity and novelty factor, but the ssh port could be open when others are closed, and the shell-like system may be far more familiar to people.
• M-Chat is being designed to use language packs, every server message will be read from a language file, so only a file for another language be added to the languages folder for it to be available. You can then select this language from the config system. Or people in the chat can set their language, overriding the default. Note that you will also have to append to/alter/replace the commands file, or the alised commands file to allow commands in other languages. Future versions may include command name aliasing in the language packs.
• M-Chat is modular, and easy to overload. You dont like how something works? assuming you know a little perl, you can change it. Admin acocunts logged in and some tools will even allow you to make changes while the server is running.
• M-Chat comes with a variety of tools, including command line and gui (thanks to perl/tk) configuration editor (of course, the config file is in plain text, you can edit it manually if you so desire), a password re-encryptor, which will go through all the registered user files and change passwords to the new encryption code, an automatic update system, downloading files or groups of files and installing them, and even updating the currently running version, without need for a restart of the server.
• M-Chat uses a number of ports for many of the protocols, and allows secure (thanks to perl SSl ports) connections where desired. You can also easily find out the security of the connection path to other users.
• M-Chat has a number of ways of dealing with troublemakers, from not allowing them to talk or change rooms, to kicking or banning on IP, nick, host, browser, and other methods, up to limiting connections to only registered members, or even only allowing admin in.
• M-Chat is designed to have games running, from small anywhere games like black jack, up to entire MUDs within the chat, and any properly written game need only be put into the games directory to be allowed to run. editing the config file or running the config program is all that's needed to disable a game, without needing to remove the files.
• M-Chat will have server-to-server setup to connect to jabber and IRC servers, and possibly others. Note that users on another IRC or Jabber server will not be able to use most of the added abilities of the server, and some commands will nto work when used from M-Chat where another type of server is involved.
• M-Chat will have a built-in censoring system, word and message modifications (like bold and italics and colour changes), and filtering. Some types of flooding will be reduced or nullified by this, and if enabled, the server can even disconnect a user who it judges to be breaking anti-flood rules.
• M-Chat can use a variety of databases, or no database at all. Note that only long-term information is kept in databases, like registered user info, bulletin boards, game info and the like, all the info for current logins and room text is kept in memory. this may take more RAM, but should make the server significantly faster.
• M-Chat requires very little else, and will work on a wide variety of platforms. The only real requirement outside the files included in the project is a working version of perl with a few common modules installed. anything not common will be made available with the other downloads.
• M-Chat was developed on a 200MHz/64M RAM WinME system, and some work was also done on a 486DX 16M RAM Win95 system. Testing has also been done in cygwin on the 200MHz system. Future testing will expand the list of known-to-work systems, though any *nix boxes should take little adaption. The development in Windows was using ActivePerl, and MySQL. This chat server is one of the few which you can count on to work right on a windows system without any changes. It was also designed to work fine on lower end machines, though if your server is successful and ends up connected to several other servers and regularly serves thousands of active people, you're going to need a more serious system.
• M-Chat has a powerful configuration system, which comes with an easy-to-use perl/tk gui. you can set encryption settings, put maximums on connections to certain protocols, and select a number of ports for each protocol (in fact, M-Chat has nothing against using EVERY port. This is ill-advised, and will make the config file quite bloated, but if you want to do it, M-Chat will happily access all your available ports. Note: any ports in use will not be used, and if you're not root and running the server on *nix server, you probably can't use ports below 1024).
• M-Chat supports encryption and compression of data transfers, although you will need to use a client that can use SSL and inflate bz2/gzip/zip/rar streams (these four are the currently supported ones, and the system also uses tar for updates). Note that Activeperl on windows does NOT support secure sockets as yet, to run with secure sockets on windows you will need to build perl yourself, or build the relevant modules from CPAN, with an SSl package, such as OpenSSL.
• M-Chat is designed to be very easy to use, and very easy to change, which means that by the time enough work is done to allow it to properly work with the proposed protocols, it would be the work of a few minutes to build another protocol interface.
• M-Chat games will be designed modularly, and with common libraries, once the libraries are properly developed, building another game to work with them should involve only the cosmetic features, all the grunt work of programming will be provided.
• M-Chat comes with a built in level system, where people who prove to be impartial and ahve good judgement can be elevated to a position to watch over the less fair.
• M-Chat should eventually be able to access firewall/iptables settings to completely block access from locations where DOS attacks are coming from, or severely problematic people.
• M-Chat server-set is actually a tree-based network or individual servers, and any of the interface servers can be shut down without affecting the others (except, of course, that people on those wont be able to talk to people who were on the shut down server, and since more resources are available, other processes may speed up). It is recommended that all of these server-components be set up on the same computer, but this is not a requirement. you could run seven parts of the same server one on each continent if you had access to computers there. But if the connection is lost there will be a problem more severe than IRC netsplits, if one of the server parts is nto connected to the core of the server, it cannot continue on it's own. It should display a core server connection lost message and shut down until the connection is reestablished.
• M-Chat includes many many options for users, and even more for ops, increasing as you get to higher levels

• If you want a chat system that is built from the ground up with security in mind, you dont want M-Chat. this server runs on windows, anything that's capable of that you can probably judge to not be well defended.
• If you need something that will be stable and not crash, you should probably be looking at a commercial product. This server and related software is free software, released without any warranty, and can be expected to be filled with bugs and problems relating to the differences from one computer to the next. I'm designing it to avoid this as much as possible, but this software should not be trusted to be safe, stable or secure. If you still want M-Chat (as I hope you do), then you are best off using a stable release, or even better, a seasoned release. Seasoned releases are stable releases that have gone a long time without having seen any errors due to issues on the server side. These releases will be the most stable, but will be missing many of the newer features.
• If you want an IRC-like system, and that's all, M-Chat is probably not for you. being designed to be modular, use many levels of ops, keep the last however many lines in a room (usually around a hundred, this is needed for HTTP chat, but near useless for IRC or any other streaming protocol), and many other issues which will make it not the best choice for an IRC-only server. Even if you want all the features of M-Chat to connect to an ordinary IRC network, there will be a number of issues to be worked out, and settings to be adjusted. For best results, M-Chat should only have server-to-server connections with other M-Chat servers.
• If you just want a gateway between different IMs, there are far simpler programs out there you should use instead. This server is designed to be able to do a great amny things, not to do a few really well. Of course, if you think you may use some of the other features later, or if you just like the idea od M-Chat, you can of course use it.
• If you want the maximum usage of your CPU and RAM, you dont want anything written in perl. on the other hand, most languages have to jump through hoops in order to be able to do text processing and manipulation like perl can. And since chat systems like this are all text, perl seems ideal.
• If you want something that you can download, run one file, and have a running server, you have a problem. The default settings for M-Chat should work well, and the setup program should be able to figure out most of the configuration itself, asking simple questions where there are options involved, but there are some things that the admin will have to do themselves. Not only that, but it is recommended that the user customise the settings best for their requirements and system. If you think you're going to be hard pressed on hardware resources, there are a few things you can do, like disabling compression, turning games off, or lowering the maximum number of users allowed on (this only affects non-registered users, registered users and ops can log in even if the number of users online is above maxusers).

The history of this system.

If you haven't been to www.alamak.com and chatted there, it may be a good idea to, because this project started out a long time ago as just HTTP and IRC, to fix problems I saw at Alamak, and to improve the server the way I think would be best.

Since then it has gone from something I want to run so I have have a better server, to something that I'm going to actually give away, and hopefully be far better than any other free cxhat system, and most likely many non-free versions too.

As it developed, I have looked at other projects, not just chat systems, that may give me ideas or resources. Hopefully this server will provide features like SMS, a fully featured webmail system (think hotmail or mail.yahoo.com), homepages, NNTP news servers, and many other things. If you enable these options or not, and if you charge for them, is entirely up to you. if you make millions out of it, then good, and I'd like to know about your successes (and failures, they might help me change things for the better). However a donation to help work on the system, or just as a thank you, or whatever, while not necessary, would be greatly appreciated 8^)

The level system, as well as the rules, and commands, are based on those at Alamak, though improved on a great deal.

Notes/issues/points of interest.

This system may include some basic cryptology information and/or routines. It should not be an issue, but it is the responsibility of the people who download and use this software to ensure they do not break any laws, and any legal issues arrising are wholey and completely the responsibility of the downloader.

As soon as you start installing addons (including games) from other people, or working with different versions of software, you run a higher risk of having errors. I'd like to think that everyone who writes code that can be added to this project is competant enough to make good, portable code (and I expect that if people do, some of them will be a lot better than me), and that my code will be compatable across a number of version differences, but I don't think it's that likely. One or two releases difference and code from people who know the software well, I'd say is good, but the further from there you get, the higher the chance of problems.

System requirements.

• A computer with an OS, RAM, and storage. (HDD would be preferable, you should be able to fit quite a lot of perl code on a 1.44M floppy, but your registered users file will grow as you get people registered).
• A connection to the internet, and the ability to use server sockets (the first release of Win95 had issues there, though the activeperl docs told you to install it before perl).
• A working version of perl. This software was developed on activeperl, so that will work. It should also work on normal perl, and macperl (which will probably soon be outdated since MacOS X is wisely a *nix system).
• Certain common perl modules. If it's not in the activeperl basic install, I'll try to avoid it. Hopefully anything in activeperl basic install should be installed on any other perl, and if not, well, should be easy enough to install.

You will need to have the core of the program to use any of the other parts.

That should be all you need. really. Although it's not really a good idea to run just on that.

System recommendations.

The best thing to do first off is make sure you have the most up-to-date versions of all applicable software. OS, perl, database (if you use it), and parts of the server. This should be common sense.

Because some of the immature people who may get kicked off can get ahold of script-kiddie tools, the better protection you have against this sort of thing, the better. A properly configured firewall and virus scanner should really be requirements for any computer connected to the internet for more than a few minutes a day, and especially for a server. If you have a type of firewall that can discard packets depending on IP, port, info, and such, and the server can put information into it, you will be immensly safer, properly secured, the only thing anyone could do is a DDOS or DrDOS attack, there's not really any way of dealing with this at the server. Sorry.

It would be advisable to put your long-term info into a database. The server can use plain text files, but that's a bad idea. For security and performance. This server will come with interfaces to a number of databases, and developing interfaces (using CPAN/PPM perl modules hopefully) to more should be very simple.

The more RAM, HDD, CPU power, and bandwidth you have, the better. The more active your server, and the more system intensive things you do (like compressing data), the more computer power you'll need. If you get to the stage where you'd have to buy a more powerful computer, my opinion would be to get several cheaper computers instead of one powerful one (which would have more power combined for less price), network them, and have parts of the server running on different computers. On a small LAN, the chance of a netsplit-like problem is a lot lower than on the 'net, but still higher than on one single computer. When doing this, where possible due to performance issues, the core part of the server should be run on the most stable computer, as if any other part goes down, only one protocol goes down, but if the core does down, everything goes down.

If you use this software, or like it, there are some good things you can do to help.

Nothing here you have to do, but it would be nice, and it will help the development.

Make a donation. Money makes the world go round. You can specify what it's for if you like, if you are putting up the money, I'm far more likely to work on your favourite area. There's no garuantee though, but if you say it's only for a certain project, and I dont want to work on it, I'll return the money, Or get in touch about a similar idea or project I have.

Dealing with bugs. If you find a bug, please let me know. Or, if it is related to coding that someone else has done, like games, mod packs, or even if someone else becomes a developer on the core, then you should make sure you talk to the right person. If they think that it's an issue with the programming in the main part of the program, they can bring it to me.

Reporting bugs. If I get an email like "this server crashed. what's wrong?", I wont even reply to it. If you're reporting a bug, include info on your computer, CPU, RAM, HHD, versions of perl and database software, what parts you have installed, what version of the server and other parts you have, what alterations you or others may have made, when and where the bug occured, if it's a constant thing, or if it only happens some of the time, and most important of all, HOW TO REPRODUCE IT. If I can make it happen on my system, I'm most of the way to finding and fixing it.

Bugs and Versions. If you have a bug, and you're not running the latest version in your choice of distribution (stable, dev, or raw), upgrade all parts to their newest version and see if the bug is still there. It may well have been fixed, even if it's not in the changes or bugfixes info. Note that this does not apply to seasoned releases, as any release that's been declared seasoned should be completely stable. The only issue here is if an old version that did work no longer works with a newer version of perl or your OS or whatever. And Games and addons and such may well require some of the features in the newer version, although the software SHOULD detect this, issue the error, and not use the addon. Also please check first to see if the bug is already listed. If it is, and you have more information that is listed, please let me know that it's more info on an old bug, so I can easily work the onformation together. Having several bugfixes on the same bug may end up being counter productive.

Best reaction to bugs. Reporting a bug with all the relevant information would be good, actually looking into it, finding the problem, and maybe coming up with a fox would be far better. If you email me with the information about a bug, and how to fix it, the fix is likely to go into the code immediately rather than when I get to it. People reporting bugs will get a mention (unless they ask not to) in the documentation, the more work or harder the problem, the more prominant the thanks. And who knows, if enough people make donations or pay for support, I may be able to offer rewards for bug fixes some day.

Support. If you want support beyond fixing bugs and portability, you may not have much luck. If I think it's an issue many people may come up against, I'll probably write some info on a web page or make a small tool to deal with it, but even then it may take some time. If you need help right now, you probably need paid support. The more work there is, the more it will likely cost, unless it's something I wanted to work on anyway, in which case it will be far cheaper (as you're paying for me to do it sooner, rather than just to do it).

So, you think that this as an awesome project, and can't wait to start using it. Or you think that a few of the tools included may help you with something else. Where and when can you get it?

Well, where is easy. This project is on sourceforge.net, and is likely to stay there. If need be, the project may be moved, and the sourceforge site made a redirect page.

As for when, well, considering current progress on the servers themselves is going (some of the time I'm working on extra tools rather than the servers), there probably wont be a real release for some time yet. The first release will probably have a working core server, and either IRC or HTTP, with a few basic tools, and database access. Once that is out, I'll work on getting more databases supported, more servers, increase the stability and so forth. I'd like to be able to release a huge number of games, but the work to make good games libraries will take a lot, and will have to be done after the rest of the framework is in place.

The first working server release may, or may not, happen this year. Yes, it may well be 2004 before the first release is out. Because of the way I want to write this, I can't do a partially complete release for testing, the first release will have to be a fully working version of the core and IRC or HTTP, with database access, and config support. Right now, the design of the server and the communication between servers is still open to alteration, current plan is for a extended IRC numbers system, which will help with IRC communication, and the number system will make it easier to use lang packs.

Until the theory is worked out, not a great deal of programming can go into the core, the most anyone else can do right now would be to get in contact with me and talk about this, especially if they have experience with IPC, perl, chat servers, IRC (on the coding side), or the other supported protocols. But anyone who has ideas and no experience at all outside of using chat servers can no doubt help, so feel free to contact me. Once there is a bit of an interested community, mailing lists could be used for everyone to discuss ideas.

Once the theory work is done, there may be some work other perl coders can do themselves, but as I would rather write the first release myself, it would be interfaces to other databases, or helping test ideas and code on other systems, and the like. Of course, anyone who can translate language packs will be welcome to help there, the (Australian, since that's what I speak) english lang pack will be there as a reference. However, until the first release, you can expect the structure to change, and their help will most likely still be needed. Also likely to be used will be small graphics, possibly gifs, but png would probably be a lot better, anywhere where they're still under patent, people using them can be charged for displaying them on their website.

Once the first release is out, anyone will be able to start making addons, games, mods, database interfaces, other protocol interfaces, and anything else. Although until the release of a reasonably developed gaming framework, not too much can be done there.

Assuming this project is still on sourceforge when the gaming framework is released, I plan on having a new project registered, for the people who wish to develop games, so they can do so without my interference. Hopefully they'll want to discuss ideas and protocol and such with me, but if they dont, then so be it. If I think games and/or gaming libraries are good enough, they will be made available as part of the main system.

Information on how M-Chat update servers and version control work will also be made available to those interested (and quite possibly be improved on by some people).

Once it is out, which version/distribution should I get?

The newest version, from the main server, of course. The update script which comes in the toolkit can check the update server, finding out which modules have a newer version. Eventually it's my hope that the updater will become as sophisticated as PPM for activeperl, and be able to use a number of update servers, as the main one will not carry much in the way of alterations/mods/games.

As for which distribution, that's more an issue of personal choice. At the moment the plan is for 4 distributions, seasoned, stable, dev, and raw. Raw will include all the newest features, things being worked on, anything that's alpha-test quality will probably be here first. If you want to be testing and expect your server to fall over often, this is the distro for you. This is about the quality you get when you download nightly tarballs or cvs code. Every now and then all the work on the server will be put together and made into a dev distro. This can be considered beta release, most of the bugs should be worked out, but only most. This should be where the majority of testing occurs, and any problems fixed. Once we're confident that the bugs are out, a stable release can be made. If you want to run this as a chat server, as opposed to a test server, this is the distro for you. Once it gets into a stable release it should all work, and be forward and backwards compatable as much as is possible, working with previously designed mods. Unless you require a distro that wont fall over or have any issues left, this one should do you. Once a stable release has been out for a while, if no problems are found, and it seems to work fine, it can be made into a seasoned release. Seasoned releases will be the most stable, but will be out of date compared to current code. Hopefully seasoned releases of core should roughly correspond to seasoned rleases of other server parts, to tools, and games, meaning using seasoned release on all parts (and config only allows you to use one distribution type) should not cause too many, if any, version incompatability issues. Any found should be listed, if not listed, please let the developer know so they can put it on the web for other people to read. Do not expect any problems you find in seasoned releases to be fixed, if there are any they are probably fixed long since in more current distros, the msot that will happen with a problem in a seasoned release is that it's taken down or a warning put on the relevant web page.

How do I keep it up to date? And once I have the files, how do I message all users, shut down the server, upgrade, and reboot the server?

All you need to do to keep the server up to date is to run the update tool, once properly configured, it can run automatically. I should even be able to be run in batch mode, so simply setting cron or task scheduler to run it in batch mode during the quiet part of the day should be sufficient.

The updater tool will also replace old files ( you can keep them in a backup directory if you wish, and restore manually in case of a problem) with the new ones, meaning the next time the server is run, it will be most current. The updater can also, if enabled, access the running version and overload the modules that have been changed. This means that apart from a short slight drop in performance, there should be no decrease in service. Please note that this very cool idea may not work too well on all systems. Before you do this, it would be nice to log on as an admin or with the control system and do a system-wide broadcast that an update is occuring, and if connections are lost, the server will be up again momentarily. If a problem occurs doing a hot update, or has in the past, let us know with the rest of the relevant info (see reporting bugs), and do a cold update. Use the control interface to (preferably) let people know an upgrade is in progress, then shut the server down, run the update tool, and re-load the server. If you still have problems, revert to an older version by replacing the new files with old, and let somoene know of the problem and relevant info.

What about updating games, or addons, or other files?

Assuming they have the right files where you can get them, you can just add the URL to the updater and it can check them too.

Anything I haven't covered? Questions? Comments? Want to help? Let me know.

This project hosted on , using Activestate's ActivePerl port of Larry Wall's perl.