Chat Gateway Protocol

The chat gateway is a text protocol on™ that was deprecated in 2005. It has since been disabled entirely; sending the protocol byte for this protocol causes the server to disconnect the client. The information below is retained for completeness and historic purposes.

Getting Started

To signal the server to use the chat gateway for communicating, the user must send 0x03 as the first byte after connecting. All subsequent messages from here use human-readable text terminated by an end-of-line character sequence (0x0D 0x0A, also known as \r\n).

The normal SID-style messages from the game protocol (0x01) are invalid here, the user will be disconnected and temporarily IP-banned for violating the protocol if the client transmits game protocol messages over the chat gateway.

Key Facts

The chat gateway does not create or join games.

Users of the chat gateway protocol are assigned the Chat icon and product id. Anyone using the chat gateway will always have the flag 0x10 (known as the UDP Plug) because they do not use UDP.

The chat gateway is restricted to the following channels:

All other channels are restricted, including Blizzard Chat.

In the chat gateway, user flags are printed in padded 4-character hexadecimal numbers (ex. 0010). They are not padded to the full length of the UINT32 flag field (ex. 00000010).

Channel flags are not received and they cannot be retrieved, but it is assumed channel flags would follow the same format as user flags since they reuse the same field on the game protocol.

All product ids in the chat gateway are seen as their normal UINT32 field. As an example, a user may receive a 1001 USER message with the product of STAR. This is identical to the product ids in SID_CHATEVENT, with exception to that they are not reversed (ex. RATS). The same applies for every other product id. Statstrings are unavailable when using the chat gateway.

Handshake Messages

The purpose of the handshake process for the chat gateway protocol is to authenticate the user and put them into chat.

After the protocol byte (0x03), the user should send 0x04 terminated by end-of-line to signal the login process.

The server will send the following to signal the user to enter their credentials:

Enter your login name and password.

After the user sends their username terminated by end-of-line, the user should receive:

Username: the-username-entered

The user should now send their password in plaintext terminated by end-of-line, then the user should receive:


There is no character after the colon symbol (:), not even a space character.

The server will now verify the user's credentials, and will send a success or failure message.

The server will transparently convert passwords to lowercase before verification. This is to adhere to the game protocol login process, where the games do the lowercasing instead.

Login Failure

The following is received if the server rejected the user's login credentials:

Incorrect username/password.

This message could be received if the user does not exist or the password does not match the one on the server.

The server expects the user to repeat the login process by submitting their username again, skipping the transmission of 0x04.

Login Success

The following is received if the user's credentials were verified and the user has logged on:

Connection from []

The example value represents the user's IP address as seen by the server.

This message is followed by message ids 2010, 1007, 1001, and then 1018 respectively.


When the user sends a message after handshake, the server will interpret it identically as the text field in SID_CHATCOMMAND and every message is subject to the same restrictions of that game protocol-style message.

When the user receives a message from the server, they follow a specific formatting. That formatting is detailed further below.

The general idea of the specific formatting is as such:

<id> <name> <message-data>

Each field in the message is separated by a space character. The name accompanies the id, and can safely be discarded for parsing. The message data may have additional spaces. If there is no message data, there is also no space character after the name.

Message ids are padded 4-character decimal numbers. They closely resemble user flags' formatting, but they are not hexadecimal.

Ids in the range of 1000-1999 are assumed to be reserved for chat events, and they follow the same base set of ids as the event ids of SID_CHATEVENT.

Ids in the range of 2000-2255 are assumed to be reserved for normal SID-style messages that have been converted to text-style, such as SID_ENTERCHAT (known as message id 2010 here).

You can get a better idea of how these ids work by reading further below.

1001 USER <username> <flags> [<product>]
1002 JOIN <username> <flags> [<product>]
1003 LEAVE <username> <flags>
1004 WHISPER <username> <flags> "<message>"
1005 TALK <username> <flags> "<message>"
1006 BROADCAST "<message>"
1007 CHANNEL "<name>"
1009 USER <username> <flags> [<product>]
1010 WHISPER <username> <flags> "<message>"
1010 WHISPER your friends <flags> "<message>"
1018 INFO "<message>"
1019 ERROR "<message>"
1023 EMOTE username flags "<message>"
2000 NULL
2010 NAME <username>

This ends this section and covers all of the messages that the chat gateway sends and receives.

BNETDocs Staff TODO: Clean this part up.

After you have logged on successfully, anything you send is a message or command followed by an end-of-line. If you do not add an end-of-line to your message, it is appended to your last message. So for example, let's say I entered "123" without an end-of-line then entered "456" with an end-of-line, I would of just sent "123456" to the channel, instead of "456."

Telnet's flags are the same as the regular user flags seen everywhere. The only difference is that Telnet's flags are kept to 4 characters instead of 8 characters or a binary UINT32 and the flags are displayed in hexadecimal (ex. 0010 UDP would be 0016 UDP in decimal). Also, flags are prefixed with zero's if they are not equal to 4 digits.

See the related documents for more information about flags and ID's. Telnet uses the same "values" as described in those documents. If you noticed something, SID_CHATEVENT uses the same event ID's as Telnet uses, except for 1013, 0014, and 0015, which are not used in Telnet. Another irony is the packet ID's in Telnet are 4 digits, just like the flags are, so maybe a UINT32 in Telnet is actually 4 text-digits.

| Edited: Caaaaarrrrlll



Looks like you are missing some. 1016 and 3000 were also Event_Info (duplicates of 1018 or perhaps they were used for something else?).

In addition, 1013, 1014, and 1015 were used. When a channel was full, you would receive 1013. If you could not join a channel from being on the restricted client, you would get 1015, and if you did a /whois of a channel that had 0 users, you would get 1014.

And... Telnet still exists, just to Blizzard employees only <a href=",17597#msg179291">according to Ringo</a>.

From my old bot: (they match 0x0F, save for "Event" instead of "EID" -- also looks like there is no NULL packet from 0x0F)
Case 1001: Event_SHOWUSER
Case 1002: Event_JOIN
Case 1003: Event_LEAVE
Case 1004: Event_WHISPER
Case 1005: Event_TALK
Case 1006: Event_BROADCAST
Case 1007: Event_CHANNEL
Case 1009: Event_USERFLAGS
Case 1010: Event_WHISPERSENT
Case 1013: Event_CHANNELFULL
Case 1016: Event_INFO
Case 1018: Event_INFO
Case 1019: Event_ERROR
Case 1023: Event_EMOTE
Case 2000: Event_NULL
Case 2010: Event_NAME
Case 3000: Event_INFO

EDIT: Also, there were two commands that were CHAT commands only, beep and nobeep.
/beep - enable audible notifications
/nobeep - disable audible notifications

As far as I know, you could /beep <username> and if they had it enabled, it would make their computer beep.


/time also works.

Remember that you have to be on the server.


Whoops, forgot to add that back.


Telnet still works on the W3DM Server. You have to use the name "Anonymous" with no password since there are no account capabilities. Only the following commands work:
/? -- /help
/whois -- /where /whereis /whois
/friends -- /f