Some rumors and myths that have recently been circulated about IMC2. Rest assured, they're just that these days. Rumors. They may have been grounded in fact at one time or another, but to my knowledge they are no longer an issue as of version 3.00. These are all phrased as questions and answers. #1: "Is it true one can gain access to your mud and take it over?" Absolutely. Can this be done using your IMC2 connection? Not very likely. Nothing on the internet is totally secure. #2: "Is it true one can hack the port and access your shell?" It may have been at one time, but no longer. IMC2 does not bind a listening port for one. For another, the Imail files which created the possible security risk have been removed since 3.00 no longer supports IMC Mail functions. #3: "Is it true commands have to be re-entered over and over after new code is added?" This was only ever true of Smaug based muds that relied on the tables.c defines to store their commands. Even in this situation it was only true if someone disabled the compiling of the IMC2 code. Version 3.00 eliminates the need to interface directly with the command tables and instead is parsed via a single hook early on in the interpretation process. #4: "Does IMC2 need an extra port? I only have 1 I can use." No. IMC2 no longer requires binding additional ports to connect. #5: "Could anyone just read what I am telling others over IMC2?" Not casually, no. As with email or instant messaging, your IMC2 transmissions leave the mud unencrypted. Anyone sniffing the routers along the pathways between the IMC2 hubs could potentially listen in. Unscrupulous router operators might also have debugging mode turned on when they shouldn't. Standard rule of thumb applies: Don't use IMC2 for anything you absolutely cannot risk exposing, like credit card numbers. #6: "Are there channels where more than one person can speak with me?" Absolutely. Though this will depend greatly on the network you end up connected to. There may only be one public channel, there may be several, but in general they should all have at least one. Otherwise what's the point? #7: "Can anyone get connected to IMC2 or is it for elitests only?" Anyone who wants to connect can do so, once they've filled out the application for connection. Which leads into..... #8: "Why does IMC2 require people to register for a connection?" Mainly so we know who is where for security reasons. The network is decentralized and as a result is managed mainly by individual hub operators. These people need to know how to get ahold of you if something comes up. None of the information is sold to anyone, nor is it given out. Most of the hubs are run by people who despise spam as much as anyone. [This issue is no longer valid. Connections no longer require pre-registration] #9 But this software is buggy! Don't you people ever test it? Yes. We do test it. It's been tested and run on every codebase that's listed as being compatible with it. And yes, for those of you who are asking ( I can hear you! ) that includes ACK!MUD as well. It's been tested and has NO LEAKS. If you're using it on some codebase we have not tested it on, then by all means let us know what needed to be changed. Rumors which began spreading after forked versions of the code began appearing: #10. I've heard that there are multiple versions of the client and that the developers are deliberately breaking compatibility with each other in an effort to try and force the use of one client over another. Is this true? Absolutely not. There is no effort being made by the MUD-Net team to break compatibility with any other client or with any other hub. If there are any such compatibility issues being raised it is because other developers are making changes to their code that are not compatible with the new features MUD-Net has added. Since these features were added in MUD-Net first, we cannot be breaking compatibility with anyone. You should make it known to other developers that breaking compatibility is not something you want to see happen. Creating compatibility problems is a Microsoft tactic. Lets not go down the road of locking people into one client/hub or the other. That's just not how Open Source projects are supposed to behave. #11. But what about all those bad packet keys you guys added? There is no merit to these arguments. There are no bad packet keys, only keys which other code doesn't support yet. The IMC2 client ignores keys it doesn't understand in the course of delivering a packet. The protocol is very much an extendable thing and arguments against adding to it are generally propagated by those who would prefer to let it stagnate. #12. But this other developer told me you guys are introducing security holes and unnecessary packets to the entire system on purpose. Why would you do that? There is also no merit to these arguments either. Security is very much on the minds of MUD-Net developers. Steps are taken to ensure that no breeches are introduced. However, no system is perfect. Flaws can creep in, and if properly addressed to the development team, they will be plugged. Packets introduced into the system have a purpose for existing, even if other developers may not realize what that is. Rumors which have surfaced regarding the AntiFreeze client: #13. I've heard that you guys named it AntiFreeze in an attempt to be derogatory toward another network. Is this true? Not intentionally, no. When the time came to pick a new name after the LGPL relicensing, discussion of all sorts of names came up. AntiFreeze was picked mainly because we felt the code kept things humming along smoothly, like the antifreeze in your car. Not too hot, not too cold. In coding terms, it was meant to reflect stability. Nobody ever thought about the implications regarding said other network until its administrator decided to make noise about it. #14. So I hear you relicensed this code under the LGPL. I was told this is illegal! Whoever told you that isn't in a position to make such claims. Since AntiFreeze was rewritten using Oliver Jowett's LGPL code as its base, it is perfectly legal. Also, according to several clauses in the LGPL license, it isn't virally attached to the rest of the codebase. Clause 5 of the LGPL states: "5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License." Take Diku for example. Diku exists as a separate entity. When following the IMC2 instructions, Diku can then call the IMC2 code. Diku is using the library. Diku falls outside the scope of the license. Rumors which are expected to surface regarding the IMC2 Freedom client: #15. HEY! You can't do this! You relicensed the code again?!? How do you justify this? Simple. We wrote most of this code to begin with. We took out the portions which were causing unnecessary controversy over the LGPL licensing. What was left was entirely our own work. From that base of work, new code was written to fascilitate the functions which had been removed. The resulting work is therefore free to be licensed as we see fit. Those people who contributed extra stuff to the AntiFreeze code gave consent for their work to be relicensed under the new terms. So this issue should now be dead.