KMess uses the MSN Protocol internally to communicate with other clients connected to the MSN Network, like Windows Live Messenger (shortened to WLM).

An MSN client actually implements two distinct protocols:

  • a server protocol for all standard features (chatting, managing the contact list).
  • a client-to-client protocol for additional applications within a chat (file transfer, emoticons, winks, etc..)

This page discusses the server protocol. For the client-to-client protocol see: MSN Peer to peer protocol details.

Note beforehand

It's not mandatory to understand the MSN protocol to become a KMess developer. There are other parts you can help us with as well, like improving the user interface.

Most knowledge about the MSN protocol has been reverse engineered. There is no official documentation about how things are supposed to operate and how clients should respond in certain situations. That's why we apply various debugging practices.

More detailed information about the MSN protocol can be found at This page is meant as summary for new developers.

Protocol versions

The server protocol version is defined by the four letters 'MSNP', meaning "Microsoft Notification Protocol", and a number which identifies the protocol version. Therefore, "MSNP13" identifies the MSN protocol version 13. When a MSN client connects, it informs the servers which protocol versions it supports. The server has a final say here, as it will confirm the protocol version which will be used for the connection.

New message types are only made available in newer protocol versions, so existing clients won't break. To receive the 'personal message' from other contacts, a client needs to support at least MSNP11 for example.

KMess 1.5 uses MSNP12, which was introduced with MSN Messenger 7.5. Windows Live Messenger 8.5 uses MSNP15. We've kept KMess 1.5 at MSNP12 because MSNP13 and beyond introduce rather heavy changes in the communication methods. Instead of new efficient space-separated commands, MSNP13 introduces more XML syntax and the commands for the contact list got replaced with SOAP calls to a central passport addressbook. We couldn't afford such heavy changes yet, and decided to focus on the client-to-client protocol instead.

Command structure

The protocol uses plain text messages. There are two types of messages:

  • a simple one line command.
  • a payload message.

Simple commands

When a client sends a command, it's echo'ed back by the server. For example:

>>> ADC 50 FL N=name@domain.tld F=name@domain.tld

<<< ADC 50 FL N=name@domain.tld F=name@domain.tld C=b54cae02-dc8a-447c-8407-f38595ccaba0

This is actually quite a nice design, because it fits the model-view-controller pattern very well. The server is the "model" in this case, and the client implements the "controller" and "view". When a client sends such command, it just waits for the echo to perform the actual update. It also allows the server to send a command asynchronously. The client just performs the action requested by the server.

Payload commands

A payload command is announced by a simple one line command like MSG. This command indicates the size of the payload to receive.

Payload commands are used for:

  • profile data
  • typing notifications
  • plain text chat messages
  • data announcement messages
  • person status messages
  • p2p protocol messages.

Plain text messages are transferred with the MSG command, which carries the data in MIME format. A simple chat message in blue font looks like this for example:

MSG My%20name 124

MIME-Version: 1.0

Content-Type: text/plain; charset=UTF-8

X-MMS-IM-Format: FN=Arial; EF=; CO=c55c00; CS=0; PF=0

fine :D

The payload commands are also used as container (wrapper) for the messages of the client-to-client protocol. Therefore you'll see a flood of MSG commands in the logs when a contact has a new display picture.


There are several types of connections each client makes. For the server protocol, there are three possible connection types:

  • notification server (NS). This is the primary connection.
  • switchboard server (SB). This is used for chat conversations.
  • SOAP webservices. This is used for authentication for example.

Notification server

The notification connection is the primary connection. All standard commands are sent to the notification server. Clients receive updates about other contacts, and invitations to a chat. When the notification connection is disconnected, you're disconnected with the MSN Messenger service. The connection is kept alive by regulary sending PNG commands. This way NAT routers won't drop the connection either.

The switchboard server

When a chat is initiated, a connection is made to a switchboard server. Both contacts enter the same chat session (chat room). The switchboard room operates as a broadcast channel. All chat messages are echo-ed to the other contacts in the chat session. Think of this as an IRC channel. Everyone participant receives the message you send.

Within the switchboard session, two participants can initiate specific client-to-client invitations with each other. Before MSN 6.0 this was handled by MIME messages, nowadays this is done using MSNP2P, see MSN Peer to peer protocol details.

SOAP webservices

The protocol relies more on SOAP webservices nowadays.

To login to the MSN Messenger network, the passport login data is transmitted to a special authentication server. As of 'Passport 3.0', this is a SOAP webservice. The login results are used to authenticate the user at the notification server.

Offline messaging is also implemented using SOAP. The other contact receives a notification at the NS, and uses SOAP to access it's "mailbox".

Other connections

The client may also establish other connections:

  • a MSNFTP connection for file transfer with pre-MSNP2P clients (before MSN Messenger 6.0).
  • a direct connection for file transfer with newer clients.
  • a webcam connection
  • ...

More information

For more information, see the following online sources for now: