OIMs (Offline IMs): The Next Escargot Undertaking


Hello guys! It’s been a long time since I’ve had an Escargot suggestion relating to MSN, with the last one being the first Escargot suggestion, implementing real Microsoft account usability (for those wondering if that’s still possible, it is still being considered, but @valtron needs more people who can undertake more complex disassembly and debugging, which will take some time), and the second one being a replacement MSN webcam server, which I still need to see if it’s still necessary to put out.

Anyways, I have figured out that OIMs (Offline IMs) are something Escargot can implement, after reading some documentation on it. Initially, I had thought that OIMs were possible already, considering my limited knowledge of TCP/IP, which I am still learning slowly almost by the day. But now that I’ve come to my senses, I decided to pitch in.

I have already addressed the innards of the OIM services on a GitLab issue I replied to, so I won’t go into too much here, but here’s a summary of what goes on with the OIM process:

Receiving OIMs

When you sign in, you will get an MSG MSNP command appended to the usual account settings MSG command that contains XML data holding your stored OIMs’ metadata.

MSN Messenger will retrieve each OIM’s GUID from their metadata XML nodes, then use each in a SOAP request to https://rsi.hotmail.com/rsi/rsi.asmx in which it will return the specified OIM in an SMTP-like format.

During an active Notification Server (NS) session, if an OIM is sent while you’re appearing offline, an MSG command is sent with a condensed version of the OIM metadata that only contains that OIM’s metadata. Then MSN will go back to the rsi.asmx service to retrieve the OIM’s actual message data.

If the total OIM metadata node count exceeds 25, the XML in the MSG command will be replaced with the string too-large. MSN Messenger will then send a SOAP request to https://rsi.hotmail.com/rsi/rsi.asmx to retrieve the metadata instead.

Sending OIMs

To send an OIM, MSN Messenger will send a SOAP request to https://ows.messenger.msn.com/OimWS/oim.asmx with the sender’s email and name, the recipient’s email, each OIM’s message type and body, and an MD5 hash of an internal value sent by the service that is manipulated by the client with the MSNP11 challenge algorithm (the Application ID used in the algorithm is also specified in the SOAP request).

If everything goes well, then a SOAP reply is sent with confirmation info.

Deleting OIMs

To delete OIMs, MSN Messenger will send yet another SOAP request to https://rsi.hotmail.com/rsi/rsi.asmx with any of the OIM’s GUIDs MSN specifies to delete the corresponding OIMs. If everything is successful, a response SOAP body is sent just containing confirmation info.

Back to the Notification Server (NS), an MSG command will be sent notifying the MSN client of the deletion of an OIM.


That’s really about it for OIMs. It will take some time to finish, but nothing too daunting. If you think that I am just the Yahoo! guy, you thought wrong! :wink:

However, I do need to arrange time for that, and it’s not necessary of a feature to look into, so actually implementing the thing will be sought after at a later date. :stuck_out_tongue:

Should WLM 8.5 fix voice calls?


wait this isnt discord

anyways yea thats pretty nice


So you’re also the Offline IMs guy as well?


LOL if you want to put it like that. :stuck_out_tongue:


I’m pretty excited for the feature. because everytime i tried to do that it showed a error. Just dont make it work for blocked contacts


Now that the Yahoo! frontend has been merged into the dev branch, I can finally get to implementing OIMs. :wink:


maybe fix dummydata.py since it got broken since 8.x


@valtron has already spiffied up dummydata.py to utilize a new algorithm for adding dummy users, and aside from another module definition I had to fix, nothing else is broken. :stuck_out_tongue:



So I was able to implement receiving and sending OIMs, both on the HTTPS and MSNP Notification Server side, so is that it?

No, unfortunately, because as I was debugging rsi.asmx, I found out that the t= token wasn’t sandwiched in between <t></t> as it would usually be (also includes the p= token, which isn’t used in Escargot auth, but whatever).


That basically means the service can’t authenticate the user at all in order to send/receive commands to the right people, like triggering events when sending OIMs (if the recipient is technically online, of course), deleting OIMs, and whatever results in an Notification Server command during the OIM services’ runtime. The most odd thing about this, however, is that the other OIM services have said authentication tokens supplied. I can only point my finger at @valtron’s MSIDCRL used for Escargot auth atm, so we may need to either implement the function used to supply the tokens for these services, or simply find a way to patch the original MSIDCRL DLL altogether.

I hope you can understand and hold on to that last shred of patience you contain as we get to the bottom of this mystery. :stuck_out_tongue: