This is hoped to someday become the cononical source of unencumbered information on the AIM/OSCAR protocol suite. So far, it may not live up to that goal, though at this point it is canonical for the sole point that it's the only one.

To the lay person, this all may seem pointless. And, really, it is. This whole effort is really necessary for two reasons 1) legality, 2) the ego of AOL. It really is not maximally efficient to design a protocol and not release the specification, forcing some users to attempt to reverse engineer your work. This is not a problem that's associated with just AOL, though, so you shouldn't blame them specifically. The morals of the AOL company were forced upon them by the rest of the industry. Since already we've left the scope of this document, I shall not exit further by discussing that topic in detail.

To everyone else, I'm sure the reason for this work is perfectly clear. We would like to be as efficient as possible. Using a Java client to do such simple things as this protocol is insanely stupid. The Java version of the AIM client is notoriously buggy wastes alot of it's users' time with it's idiotic crashes and moronic error messages. Personally, this work is to let me escape from this Client of Doom.

Globally, though, this will actually promote the use of the AIM service. AOL has provided very nice clients for the Windows and Macintosh platforms, but has left it's UNIX(tm) users with a horrible "solution". Exposing this protocol will allow third-parties to develope nice, stable clients for other platforms, generally supporting the idea that "rewritten work is always better than the original". Through repetition, we can make the world of cross-platform real-time messaging a better place.

I must note, though, that this is not the only service of it's kind. The Mirrabilis ICQ service is in some peoples eye's superior to AIM, and is definitly more widespread usage-wise. This protocol dissection was inspired by all the hard workers that freed the ICQ protocol from the grips of it's beholder and let the user decide what they wanted in a client.

Generally, the whole purpose is so that anyone can write an AIM client, and if they desire, an AIM server.

Everything from here has so far come from interpretation of AIM/Oscar packets coming straight off the wire. There's been NO dissassembly of any code. It appears at this point, that that will never become necessary in the near future. The critical points of the protocol have been decoded and everything appears to be working happily using the current methods. I'm guessing that disassembly would involve far more effort than simply decoding packets, and not much more information could be obtained anyway. Also, it's more legally acceptable to avoid disassembly.

There are two authors of this document: Adam Fritzler and Scott Werndorfer. Scott is helping maintain the existing protocol information and adding anything else he uncovers, while Adam goes off and does other things, occasionally popping in to make a comment or two whenever he's least wanted. Additionally, various people have discovered things and told us about them. If you are one of those people and would like to be listed here, let us know.

Before you take any action on the information giving herein and throughout this document please make sure that you are aware of what you're doing. The best way to do this is by reading the AOL-published document entitled AOL Instant Messenger(tm) Registration Agreement. This will let you know where they stand on the subject of what went on to publish this specification. Also, none of the author's of this agreement shall be held liable for any legal action taken towards you by AOL or other parties. We'll also not be held responsible for your use of this document, either in it's intended purpose or otherwise. You're on your own (as are we).

Adam Fritzler may be contacted at mid@auk.cx.

Scott Werndorfer may be reached at smw@ceruleanstudios.com

The main source of this document if you ended up here in different manner, is www.auk.cx/faim/protocol/.

There's also two mailing lists associated with this document. The first, libfaim-aim-protocol, is for discussion of client-/platform-independent discussion of protocol issues. The second list, libfaim-devel, is dedicated to the discussion of libfaim-related issues. Instructions regarding how to subscribe to these lists are available here.