AOL Instant Messager

[Compwiz]

Does anyone know the commands that AIM uses when connecting and receiving? I want to make and emulator but I dont know the commands to do it, although I am investigating.

------------------
Tom Young, 14 Year Old
tyoung@stny.rr.com
ICQ: 15743470 (http://wwp.icq.com/15743470) Add Me (http://wwp.icq.com/scripts/search.dll?to=15743470) ICQ Me (http://wwp.icq.com/scripts/contact.dll?msgto=15743470)
AIM: TomY10 (http://www.aol.com/aim/aim30.html)
PERL, JavaScript and VB Programmer

[clefus]

Email me the results...

Thankx.
In christ,
Ben

[Compwiz]

Me again, I found the following document in the Tik (Linux version using Tcl/Tk) documentation:

[quote]# Copyright (c) 1998-9 America Online, Inc. All Rights Reserved.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

Version: TOC1.0

This document describes the protocol between TOC and TOC clients.
The protocol is built on TCP. Framing is done by SFLAP,
described at the bottom of this document. Inside each
SFLAP frame is a TOC command.

The TOC protocol is ASCII based, and special attention
must be placed argument separation. The separator and
the rules of separation are different for messages inbound
to TOC and outbound to the client. The rules of separation
are described in sections below.

The TOC server is built mainly to service the TIC and TiK clients. Since
the TIC client is a Java applet, and downloadable, TOC will NOT support
multiple TOC protocol versions at the same time. Therefore, TiK
users will be forced to upgrade if the protocol version changes.
TOC sends down the protocol version it expects the client
to speak and understand. Note, the protocol version is a string.

Important Notes
===============
* TOC will drop the connection if a command exceeds the maximum
length, which is currently 2048 bytes. So the client needs to
spend special attention to im, chat, and config message lengths.
There is an 8k length maximum from TOC to the client.

* No commands should be sent to TOC (besides toc_signon) before
a SIGN_ON is received. If you do send a command before SIGN_ON
the command will be ignored, and in some case the connection
will be dropped.

* Initial permit/deny items should be sent after receiving SIGN_ON
but before sending toc_init_done, otherwise the user will flash
on peoples buddylist who the user has denied. You will probably
want to send the toc_add_buddies at this time also.

* After TOC sends the PAUSE message to a client, all messages sent
to TOC will be ignored, and in some cases the connection will
be dropped. Another SIGN_ON message will be sent to the client
when it is online again. The buddy list and permit/deny items must
be sent again, followed by the toc_init_done. In most cases the
SIGN_ON message will be sent between 1-2 seconds after the
PAUSE message. Therefore a client could choose to ignore the
PAUSE message and hope nothing bad happens.


Client -> TOC
==============
The commands and the arguments are usually separated by whitespaces. Arguments
with whitespace characters should be enclosed in quotes. Dollar signs,
curly brackets, square brackets, parentheses, quotes, and backslashes
must all be backslashed whether in quotes or not. It is usually
a good idea just to use quotes no matter what. All user names from clients
to TOC should be normalized (spaces removed and lowercased), and therefore
are the one exception to the always use quotes rule.

When sending commands to the server you will not get a response
back confirming that the command format was correct or not! However
in some cases if the command format was incorrect the connection
will be dropped.


RoastingString="Tic/Toc"

toc_signon <authorizer host> <authorizer port> <User Name> <Password>
<language> <version>
The password needs to be roasted with the Roasting String if
coming over a FLAP connection, CP connections don't use
roasted passwords. The language specified will be used
when generating web pages, such as the get info pages.
Currently the only supported language is "english".
If the language sent isn't found, the default "english"
language will be used. The version string will be used
for the client identity, and must be less then 50
characters.

Passwords are roasted when sent to the host. This is done so they
aren't sent in "clear text" over the wire, although they are still
trivial to decode. Roasting is performed by first xoring each byte
in the password with the equivalent modulo byte in the roasting
string. The result is then converted to ascii hex, and prepended
with "0x". So for example the password "password" roasts to
"0x2408105c23001130"

toc_init_done
Tells TOC that we are ready to go online. TOC clients should first
send TOC the buddy list and any permit/deny lists. However toc_init_done
must be called within 30 seconds after toc_signon, or the connection
will be dropped. Remember, it can't be called until after the SIGN_ON
message is received. Calling this before or multiple times after a
SIGN_ON will cause the connection to be dropped.

toc_send_im <Destination User> <Message> [auto]
Send a message to a remote user. Remember to quote and encode the
message. If the optional string "auto" is the last argument, then the
auto response flag will be turned on for the im.

toc_add_buddy <Buddy User 1> [<Buddy User2> [<Buddy User 3> [...]]]
Add buddies to your buddy list. This does not change your
saved config.

toc_remove_buddy <Buddy User 1> [<Buddy User2> [<Buddy User 3> [...]]]
Remove buddies from your buddy list. This does not change your
saved config.

toc_set_config <Config Info>
Set the config information for this user. The config information
is line oriented with the first character being the item type,
followed by a space, with the rest of the line being the item
value. Only letters, numbers, and spaces should be used. Remember
you will have to enclose the entire config in quotes.

Item Types:
g - Buddy Group (All Buddies until the next g or the end of config
are in this group.)
b - A Buddy
p - Person on permit list
d - Person on deny list
m - Permit/Deny Mode. Possible values are
1 - Permit All
2 - Deny All
3 - Permit Some
4 - Deny Some

toc_evil <User> <norm|anon>
Evil/Warn someone else. The 2nd argument is either the string
"norm" for a normal warning, or "anon" for an anonymous
warning. You can only evil people who have recently sent you
ims. The higher someones evil level, the slower they can
send message.

toc_add_permit [ <User 1> [<User 2> [...]]]
ADD the following people to your permit mode. If
you are in deny mode it will switch you to permit
mode first. With no arguments and in deny mode
this will switch you to permit none. If already
in permit mode, no arguments does nothing
and your permit list remains the same.

toc_add_deny [ <User 1> [<User 2> [...]]]
ADD the following people to your deny mode. If
you are in permit mode it will switch you to
deny mode first. With no arguments and in permit
mode, this will switch you to deny none. If
already in deny mode, no arguments does nothing
and your deny list remains unchanged.

toc_chat_join <Exchange> <Chat

[1buddylee]

[Compwiz]

Did anybody do this at all?

[BoB]

hey im going to make one now this is going to be cool its going to be called x-rade im but see im going to custise it

[Compwiz]

Can somebody please help me with this SFLAP and FLAP stuff?