Select a language to translate this page!
Powered by Microsoft® Translator
We’ve previously talked about the principles that guide us as we strive to continue delivering the most convenient ways to chat with the people who matter the most to you. Today we’re taking another step, with the public availability of access to the Messenger network via XMPP, an open standard. This means that anyone can build innovative messaging clients—either stand-alone or built into their devices—that include access to Messenger’s 300 million active users.
This builds on our perspective that you should simply be able to:
We continue with our commitment to these principles, especially around enabling people to access Messenger from all of their devices by exposing an XMPP interface to Windows Live Messenger. XMPP is the Extensible Messaging and Presence Protocol which is an open technology for real-time communication used by a number of popular IM networks from Google Talk to Facebook Chat and now Messenger.
With the release of the XMPP interface for Messenger, any XMPP based chat client that can also support OAuth 2.0 for authentication will be able to connect to Windows Live Messenger to enable people to see which of their friends are online and chat with them in real-time and.
We currently support the following XMPP specifications
Developers interested in learning more about our XMPP interface can check out our code samples on GitHub along with the overview documentation on the Live Connect developer center. These should give you enough information to get started building integration with the Messenger network into your mobile apps, devices and web sites.
As you look over our XMPP implementation, please share your comments and feedback with us in the comments or on our developer forums. We always look forward to hearing from our developer community and improving the product based on your feedback.
Given that it’s the end of the year, I thought it would be informative to take stock of how what we’ve done so far to enable you to choose the device you want while continuing to enjoy our services. With this announcement, we now have universally available protocols for accessing all our major services. There’s OAuth 2.0 for Live ID, a REST API for SkyDrive, Exchange Active Sync for Hotmail, and XMPP for Messenger.
Thanks to these protocols there is universal access to SkyDrive, Hotmail and Messenger either using Microsoft-authored applications on mobile platforms like Windows Phone and iOS or using applications written by other developers such as HandyScan on Windows Phone and Hotmail for Android by Seven.
As we go into the new year, rest assured that we have more ways we plan to delight developers and our customers as we further our vision of enabling users to choose the services and the devices they want without compromise.
Dare Obasanjo
Lead Program Manager, Live Connect Platform
Does this mean that IM+ will get the windows messenger capability back?
this is potentially great news. Does it mean that we can expect to see Messenger integration with (say) the Skype client in the same way they have Facebook integration sooner rather than later? Right now I use a 3rd party messenger client because a lot of my friends are on Live Messenger but I'm not a fan of the UX (if I could pay to remove the ads and screen real-estate stealing functionality I would, but I'd much prefer to consolidate on Skype as my single messenger client)
I find myself of two minds: One one hand I'm really glad to see you embrace this standard. But considering that the XMPP standard is older than the 3rd-grade son, I can't help but think you're a bit late to this party.
On the whole, though, this is definitely a plus. You know what they say: Better late than never!
My only question is, does this, or will it soon support XMPP Server Federation. I'd love to be able to use Messenger on Windows Phone to communicate with my Google Talk contacts.
Dear WLM team! First of all, welcome to the XMPP world.
Now for the bad news.
1. For some reason you think all existing clients should be "upgraded" with your custom OAuth2 SASL method. That's not nice. Thanks for letting us developers reuse our existing work on XMPP clients, but don't you think it'd be even better if we and our users could log in with, let's see, some typical SASL method such as… DIGEST-MD5? Maybe even PLAIN?
2. I've tried two different and valid WLM IDs with Psi and iChat. One is @gmail.com, and one is @live.com. Both were rejected way before the authentication even began - that is, they were rejected as soon as they tried to direct the stream to="gmail.com" and to="live.com".
Since this is just the case of the client not knowing how to differentiate the email address domain part from the JID domain part, you should handle this better than transmitting the confusing and probably grammatically incorrect error message "Unknown To Jid in the open stream stanza".
Helpful as I am, here's the communication log between the client and the server, with the first two lines being client communication, and the rest of the XML being, naturally, the server's response.
<?xml version="1.0"?>
<stream:stream xmlns:stream="etherx.jabber.org/streams" version="1.0" xmlns="jabber:client" to="live.com" xml:lang="en" xmlns:xml="www.w3.org/.../namespace" >
<stream:stream from="messenger.live.com" version="1.0" id="357" xmlns="jabber:client" xmlns:stream="etherx.jabber.org/streams">
<stream:error>
<host-unknown xmlns="urn:ietf:params:xml:ns:xmpp-streams"/>
<text xmlns="urn:ietf:params:xml:ns:xmpp-streams">Unknown To Jid in the open stream stanza</text>
</stream:error>
It would show an immense amount of good will if you guys actually implemented the standards in a standard way. That is, if you provided authentication in a standard way.
Facebook provided DIGEST-MD5 authentication to make things extremely convenient for its users and allow use of existing XMPP clients. Why can't you guys do that?
This is great news. FYI, I already got this working in GNOME environement and is working just fine. However I think we have a legal issue: For the oauth2 authentification we need to provide an app ID and secret, but I don't think it is legal to publish the app secret as part of open source software, otherwise anyone could pretend being my app...
Google oauth authentification accepts "anonymous" app id/secret for this case. Any plan doing the same for live connect?
Regards,
Xavier Claessens
This is great news. Thank you for your work, we added Windows Live messenger in our app qiss.im chat for WP7. windowsphone.com/s .
I would like to point a bug in the server. I'm following doc from here: msdn.microsoft.com/.../hh278363
It says to do:
"""
POST https://oauth.live.com/token
Content-Type: application/x-www.form-urlencoded
client_id=CLIENT_ID&redirect_uri=REDIRECT_URL&client_secret=CLIENT_SECRET&code=AUTHORIZATION_CODE&grant_type=
authorization_code
But doing this returns an html with "service temporaly unavailable".
That exact same request works with the facebook oauth2.
Doing a GET instead of POST make it work, though.
@ Xavier Claessens, if its Restful, have you tried PUT verb?
this are great news. I have updated our MatriX XMPP library to support your X-MESSENGER-OAUTH2 Sasl mechanism. See also:
www.ag-software.de/.../microsoft-adds-xmpp-support-to-windows-live-messenger
@abm: with PUT I get a "method not supported" error message.
Now this is a step in the right direction. I like this idea
It's a good news but an other good news would be to have the official Live Messenger client on Linux platform !
@Popple3
This release enables clients to connect with the Messenger network. We've written previously on the difference between connecting and federation in our blog post at windowsteamblog.com/.../betting-on-connect-100x-the-im-engagement-and-no-need-to-re-spam-your-friends-with-more-invites.aspx
@ivucica
We have standardized on OAuth 2.0 as the authentication and authorization protocol for our services. We currently do not support or encourage non-Microsoft applications to collect user credentials. See adactio.com/.../1357 for more on this perspective.
Thanks for the feedback on the error message. I'll discuss this with the team later today.
@Xavier Claessens
We have an option when configuring your app that prevents you from having to place the client secret in your code. Please see msdn.microsoft.com/.../hh561319
I believe our OAuth 2.0 end point is correctly documented on MSDN. Can you confirm that this was not a temporary error?
@ OffBeatMammal read this it may apply to messenger aswell www.reddit.com/.../how_to_block_xbox_dashboard_ads
Hey!
When can you add support for Group chat(groups.live.com)?
Currently Windows is the only platform that supports group chat, even cannot do this with Windows Phone...
@Dare Obasanjo:
I don't understand where I can make an app without a secret key. And I need to provide the secret key to get the access-token, no?
The bug I mentioned is there since the first time I tried, was a month and a half ago.
FYI, I blogged about my work to get this in the GNOME desktop: blogs.gnome.org/.../msn-in-empathy-with-xmpp also explaining in the end of the post the legal issue with the client secret.
@Xavier Claessens We have a flow that enables mobile and desktop apps which does not require embedding the secret key in your application. The OAuth 2.0 protocol interactions in that case are documented at msdn.microsoft.com/.../hh243647.aspx (see step 8).
I've tried to connect to xmpp.messenger.live.com on port 5222 or 5223 (SSL on) using iChat on my Mac without success. I guess it's not as simple as that?!? Works with Facebook and GTalk though ...
:) Unforntunantly, I've not got much experience in this kind of stuff, but any chance this could lead to Gmail - WL chat?
@Dare Obasanjo: awesome, that works! Do you know if facebook has similar flow to not having to ship a secret key? My oauth2 code is shared for facebook and msn atm...
I hope XMPP Server Federation will be enabled in the future. Not only for corporate networks, but just increasing messaging service interoperability in general is a good idea.
Yeah, I saw that post before. I was just hoping this might have been a slight change in direction. The idea of being able to chat with any federated XMPP network from the messaging hub on Windows Phone just blows my mind though. It would certainly be a big selling point.
@Dare Obasanjo: So I have 2 questions about the future improvements:
1) Given that this is clearly targeted to mobile apps, any plan to add power saving mode? There is no official XEP for this, but both google and facebook have their own incompatible way (sigh) for clients to tell the server that the mobile device is idle and so server should avoid sending not important messages to avoid waking up and save battery life.
At least Nokia N900 and N9 are using that power saving mode, and it proved really useful.
2) Any plan to add roster management, to add/remove contacts, see authorization requests, etc?
For the info, here is how google power saving works: mail.jabber.org/.../000528.html
and the facebook power saving is "described" here: bugs.freedesktop.org/show_bug.cgi
@Xavier Claessens,
Thanks for the feedback on power saving mode. This is an important consideration for mobile devices and we'll keep this in mind as we plan future releases.
I have an account on live.co.uk which is "linked" with my yahoo account... so that I have nicely my contacts from both yahoo and msn in one client... using msn xmpp I had the surprise to get only my msn contacts... no trace of the yahoo ones... is this a feature or a bug?
can you please make TLS optional and not required? Yes making TLS required is a good thing for security. But many of your own Frameworks support no TLS on sockets, eg. WP7, Compact Framework or Micro Framework. So I am not able to connect with any of this Frameworks.