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.

