Protocols/MSNP/XMPP

From NINA Wiki
Jump to navigation Jump to search
MSNP Protocol
IntroductionTermsClients
Reference
Error ListCommandsRelying Party SuiteSpotlife
Services
XMPPHTTP GatewayTabsActivities
Documentation
Development ToolsMSNP Grid
PolygamyURLs used by MSN
Documents
Protocol Versions
Version 21
Version 18
Version 16
Version 15
Version 14
Version 13
Version 12
Version 11
Version 9
Version 8
Version 2
MSNC
IntroductionP2PObject DescriptorDisplay PicturesFile Transfer
Scenarios
Microsoft Messenger for Mac
MSNP on WebTV (MSNTV)

Microsoft implemented a XMPP Gateway in the early 2010s. It was ultimately discontinued.

Logs

Documentation

"Your app must support XMPP: Core functionality and, optionally, may implement the XMPP extensions we support."

Setting up

To connect to the Messenger XMPP service, either use Domain Name System (DNS) SRV records for messenger.live.com or connect directly to xmpp.messenger.live.com on port 5222.

Secure Sockets Layer (SSL) is required.

Your app must implement see-other-host. For details, see the "see-other-host" section in RFC6120: XMPP: Core.

We use X-MESSENGER-OAUTH2 Simple Authentication and Security Layer (SASL) authentication to get a user's okay, or consent, for your app to represent the user when signing in to the Messenger XMPP service. To do this, we use the OAuth 2.0 standard. To use our implementation, your app needs a client ID and an access token (and possibly other info, depending on your app type).

Sign in

After you have an access token, your app can sign in to the Messenger XMPP service on behalf of the consenting user.

As stated in the previous section, the Messenger XMPP service uses X-MESSENGER-OAUTH2 SASL authentication. Your app sends the access token as the SASL token for authentication, as shown in the following partial exchange of protocol info, where ACCESS_TOKEN represents your access token.

    < <stream:features xmlns:stream="http://etherx.jabber.org/streams"><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>X-MESSENGER-OAUTH2 </mechanism></mechanisms></stream:features>
    > <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="X-MESSENGER-OAUTH2">ACCESS_TOKEN</auth>
    < <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl" />

Remember that your code must first connect to the Messenger XMPP service by using DNS SRV records for messenger.live.com or by connecting directly to xmpp.messenger.live.com on port 5222.

Note: The Messenger XMPP service uses the user ID in the access token to sign the user in and to bind the user to the session. To do this, Jabber IDs that are assigned by the Messenger XMPP service use the format identifier@messenger.live.com instead of a Microsoft account user ID.

Messenger XMPP reference

The Windows Live Messenger Extensible Messaging and Presence Protocol (XMPP) service supports only the following extensions, as defined by the XMPP Standards Foundation. Partial support for some extensions, as well as unique usage notes, are listed here. For more info, see XMPP Standards Foundation - XMPP Extensions.

RFC6120: XMPP: Core

RFC6121: XMPP: Instant Messaging and Presence. Adding a contact is the only supported modifying operation; no other operations that modify the roster are supported. Chat is the only supported message stanza type. Presence probes are not supported. Note Applications should cache most recent presence for buddies and should avoid signing out and signing in again as a way to refresh presence.

XEP-0054: vcard-temp. The Messenger XMPP service supports fetching vCards, but doesn’t support updating vCards.

XEP-0136: Message Archiving. Apps that implement this extension can request a certain number of instant messages that were previously exchanged between two users. Apps can currently request up to the last 10 instant messages, but this number is subject to change. Availability of these archived instant messages depends on whether at least one of the two users has the Automatically keep a history of my conversations setting turned on in Messenger. If no archived instant messages are available, the Messenger service returns an empty response. Note In requests for archived instant messages, the Messenger service ignores user endpoint requests, paging requests, and any uses of the after element.

XEP-0172: User Nickname. Apps can implement this extension to provide an improved user experience when showing pending contact invitations to the user. By default, contact invitations in XMPP are incoming subscriptions from users who aren’t in the roster; these invitations provide only the pending contact’s Jabber ID (JID), which doesn’t show a display name. By implementing this extension, apps can retrieve the pending contact’s display name so that Messenger users have a better idea of who the corresponding pending invitation is from. Note that it isn’t necessary to support this extension for existing contacts, because their display names are available through their vCards. This extension is useful for pending contacts, because vCards are not available until after both parties have become contacts.

XEP-0203: Delayed Delivery

Additional usage notes

Adding Messenger buddies: To add a new Messenger buddy to the XMPP user's contact list, your app must add the buddy by using his or her Jabber ID (JID) and not by his or her Microsoft account ID. If your app does not add a buddy by using his or her JID, your app won't be able to display the buddy's presence info.

Here's an example of submitting a Microsoft account ID to the Messenger XMPP service and retrieving the corresponding JID.

    < <iq from='john@contoso.com' to='mary@contoso.com' type='get' id='id1'>
        <getjid xmlns='http://messenger.live.com/xmpp/jidlookup'></getjid>
    </iq>

    > <iq from='john@contoso.com' to='mary@contoso.com' type='result' id='id1'>
        <getjid xmlns='http://messenger.live.com/xmpp/jidlookup'>
            <jid>12345@messenger.live.com</jid>
        </getjid>
    </iq>