Windows Live for Developers

We’ve moved developer posts to the Inside Windows Live blog

2011-07-19T21:59:56Z

I haven’t blogged here in a while, but that’s because I’ve started posting over on Inside Windows Live instead. You may have seen a couple of my blog posts there, explaining what OAuth 2.0 means for developers who want to connect their apps, services, and devices to Windows Live, and how just a few lines of JavaScript can connect your site to Hotmail, Messenger, and SkyDrive.

Because the Inside Windows Live blog already has a ton of interesting content about the engineering, architecture, and the technical challenges that go into building and updating Hotmail, Messenger, and SkyDrive, it just made more sense for me to blog there too. That way, developers who are interested in Windows Live can just follow one blog.

You may want to subscribe to the Inside Windows Live RSS feed so you don’t miss any more posts!

Dare Obasanjo
Lead Program Manager, Messenger Connect Platform

Announcing Support for OAuth 2.0

2011-05-04T16:28:25Z

Members of the Windows Live Team as well as other teams from Microsoft are down at the Internet Identity Workshop (IIW) this week in Mountain View, California, USA. This is the 12th gathering of some of the thought leaders in the internet identity space and it's where many open web standards have been conceived in the past; Open ID v2, OAuth, Activity Streams as well as many others. Here's how the IIW describe the event:

The Internet Identity Workshop focuses on “user-centric identity” and trying to solve the technical challenge of how people can manage their own identity across the range of websites, services, companies and organizations that they belong to, purchase from and participate with. We also work on trying to address social and legal issues that arise with these new tools. This conference we are going to also focus some attention on business models that can make this ecology of web services thrive.

Today, the Windows Live team is pleased to announce our support for OAuth 2.0 in the next version of our developer platform, Messenger Connect, which allows developers to build sites and applications that use data from the Windows Live network. This development builds on our existing commitment to open web standards shown in the current version through our implementation of ActivityStrea.ms, OAuth Wrap, Portable Contacts, & OData.

Here's to a great IIW and we are excited to be participating in this community. We'll have more to announce about the new version of platform in the coming months, stay tuned!

Deprecating the Application Contacts feature of Messenger Connect

2011-02-11T12:12:47Z

In 2009, we introduced the application contacts feature, which makes it possible for web sites to offer the ability to IM based on site-defined user relationships. Messenger users can chat with other Messenger users based on the relationships they have on web sites without becoming Messenger friends and sharing email addresses. Based on low usage of this feature, we have decided to remove support for application contacts in the Messenger Web Toolkit in six months. Core IM functionality will continue to be supported after this date.

We appreciate the feedback that users and developers provide on Messenger Connect. Please keep your questions and suggestions coming!

Check Out the Gigya White Paper on Integrating with Messenger Connect

2010-12-07T17:10:42Z

Earlier this year we announced the general availability of Messenger Connect which enables users of Windows Live services to opt in to provide access to their identity, contacts, social updates and more with websites and apps. One of the key partners that has adopted Messenger Connect is Gigya.

Gigya provides social optimization for online businesses by unifying the top social APIs and protocols, including Facebook for Websites, Sign in With Twitter, Y!OS, LinkedIn, Windows Live, MySpace and others. Websites get the ability to offer sign-in to their sites as well as the ability to have their customers share content to their friends on these networks.

The team at Gigya recently published a white paper which shows their customers how to leverage Messenger Connect on their platform. The white paper goes into the options websites have for leveraging the activity streams that flow throughout Windows Live to reach our audience of hundreds of millions of users. Gigya’s customers can now easily reach:

· over 298 million Messenger customers worldwide

· 359 million people that use Hotmail

· millions of users of the iPhone client

· users of “People Hub” of the new Windows Phone 7

If you are a Gigya customer you should check out the white paper and if not you should probably give them a try if kicking up traffic to your website user the power of social distribution sounds interesting.

Introducing the Messenger Connect Chat Control

2010-11-03T22:32:46Z

A few weeks ago we announced that Messenger Connect was out of beta and available worldwide. I wanted to take this opportunity to share some details about one of the features I worked on: the Messenger Connect Chat Control. This control allows people on your site to chat in real time. Any user can view the chat session. To participate, a user simply needs to sign-in with a Windows Live ID, that is, with a Hotmail or Messenger account.

The Chat Control currently comes in two color themes: light and dark. Here are a couple of snapshots.

How does the Chat Control add value to your site?

The Chat Control adds value to your site in a number of ways. Here are just a few.

Users will spend more time on your site

Your users will be more engaged with your site’s content, because they’ll be able to talk about it with others in real-time.
It’s great for real-time events but it is also a cool commenting tool. When you have live content, such as a video stream of an event, adding nearby real-time chat capabilities is nice because your users can talk about what they see as it is happening. Because the Chat Control preserves the chat history for a while, adding it next to an article or some other static content makes it a great commenting gadget that has the added value of updates in real time.

You’ll acquire new users through the social networks of your existing users

Sharing and inviting is easy with the Chat Control. Users can invite their friends to participate in the chat, and can post to their news feed so that their friends see it. This means that you’ll acquire more new users through the social networks of your existing users.
As users invite their friends, they can have private conversations in the Chat Control without having to leave your site.
If a user has connected a Windows Live account to Facebook, that user can easily invite Facebook friends into the chat and write on the wall.

It requires no resources from your site and yet it is scalable and easy to add

The Chat Control comes with the scale and reliability of the Messenger service. The Chat Control can handle many users, right out of the box – you don’t need to invest in additional hardware or bandwidth, and don’t need to write any server code.
You can easily add the Chat Control to your site. Just register for an application ID, add a few lines of code to your HTML, and you’re done.

You’re in control

You can moderate the content of the chat. You can delete messages and can block users from posting to any chat in your site.
You can create more than one chat in the same page, around different topics.
You can have a conversation on the same topic appear on more than one page in your site.
The Chat Control loads asynchronously and runs in an IFRAME. This means it will have minimal effect on your page’s load time and resources.

Look and Feel

A user who browses a site with the Chat Control sees a live steam of messages.

The user is requested to sign in with a Windows Live ID in order to participate.

Once signed in, the user can post messages. Messages posted by the user’s friends are highlighted in light blue.

When the user applies the Friends filter—as indicated by the yellow arrow—the user sees only messages made by the user’s friends.

If the rate of message posting becomes high, the Messenger service arranges people into virtual subgroups so that they are not overwhelmed with messages. When this happens, the user is still guaranteed to see all messages made by friends.

Invite and share experience

As shown above in the sign-in screen, the user can select a check box to indicate the desire to share a link with friends. If the user selects that check box, information about the page will be posted to the user’s feed in Windows Live. If the user has connected a Windows Live account to a Facebook account, the information will also be posted to the user’s wall on Facebook.

In addition, the user can choose to invite friends to participate in the chat. Clicking on the Friends tab shows friends who are currently online.

Choosing a friend in the list and then clicking Invite starts a private IM conversation with the user’s friend.

The friend who is being invited will see the conversation anywhere that friend is signed into Messenger.

Administrative capabilities

The Chat Control wouldn’t be complete without some administrative capabilities. The owner of the application ID—that is, the user whose Live ID was used to register for the application ID—has additional rights. Once you sign in to the Chat Control with the Live ID of the application owner, you will have the addition functionality of blocking users and deleting any messages.

Once a user is blocked by the owner of the application, that user will not be able to publish content to any chat on the site.

And obviously, users can also delete their own messages.

Adding the Chat Control to your site

Let’s get down to the details of what it takes to add the Chat Control to your page. Here is an example of a minimal page that has only the Chat Control in it.

Interesting lines to note here:

Line 4—Declaring the wl XML namespace. This namespace is used to add Windows Live Messenger Connect custom tags. The Chat Control is one of those tags.
Line 7—Getting the Messenger Connect loader. This is a client-side loader that loads Windows Live scripts asynchronously without blocking the page load time.
Line 10—Adding the Chat Control custom tag:

o Line 11—Your application ID.

o Line 15—Here you give a name for the topic of conversation. When you place more than one Chat Control with the same event-name attribute in your site, they all render the same conversation.

This page can be a static HTML page. No server code is needed. When the Messenger Connect loader is loaded by the browser, it runs client-side code that scans the page looking for HTML tags prefixed with wl. After that, some client-side code runs and adds HTML elements to those tags, and then the Chat Control is rendered.

You may register for an application ID by going to http://manage.dev.live.com.

What’s next?

· To learn more about the Messenger Connect Chat Control, go to the Chat Control reference of our Messenger Connect documentation.

· To learn about other features of Messenger Connect, visit the Windows Live Developer Center.

Creating Desktop Applications with Messenger Connect

2010-10-15T19:19:00Z

Recently, we released version 4.1 of Windows Live Messenger Connect. This version brings Messenger Connect out of beta and makes it available to everyone. Angus Logan describes many of the changes we've made in his recent blog post. I also highly recommend you check out our new developer guide, which outlines how you can start building applications that integrate with Windows Live.

A common question that we've been asked has been on building desktop applications with Messenger Connect. While it's true that most of the Messenger Connect documentation focuses on web-based applications, you can still build applications for the desktop using Messenger Connect. All you need is the Messenger Connect Desktop Starter Kit, now available for download from the MSDN Code Gallery. (Look for the file named Desktop_Sample_App.zip under the v4.1 samples release.)

Before you begin using the starter kit, you need to register your application at http://manage.dev.live.com. Registration takes just a couple of minutes; you can find more detailed steps on the registration process in the Messenger Connect documentation.

When you open the starter kit, you'll find a couple of different sample projects. The best one to start with is the AuthTest project. This project provides a basic introduction into how to use the Messenger Connect authentication and consent process. For this project to compile and run correctly, open the SigninTester.cs file in the AuthTest Project. Then, locate the line:

AppInformation appInfo = new AppInformation("00000000YourClientID", "YourSecretKey", requestedScopes);

Change the values in line to contain the client ID and secret key you received when you registered your application.

When you compile and run the sample, you get a pretty basic dialog box.

Nothing too exciting, yet. But notice the http://apis.live.net/V4.1 endpoint in the text box - more on that shortly. First, let's get things going by clicking the SignIn button. This brings up the Windows Live consent dialog box.

Type in a valid Windows Live ID and password, and then click Connect. Back in our sample application, the SignIn button has changed to a Navigate button. Click the button, and the dialog updates with the top-level REST data located at http://apis.live.net/V4.1.

From here, you can navigate through the REST endpoints by copying and pasting them into the URI text box. For example, if I want to get my profile information, I would use http://profiles.apis.live.net/v4.0/cid-XXX/Profiles, where XXX is the CID the application received after I signed in.

You can get a really good sense of how the REST endpoints work in Messenger Connect using our REST Explorer: http://rex.mslivelabs.com/.

So what's going behind the scenes here? Let's close out of the dialog box and return to Visual Studio. Open up the SignInTester.cs file. This is the file that's doing most of the work. Two methods stand out in particular: SigninSynchronous and btnNavigate_Click.

void SigninSynchronous()

{

user1 = new MessengerConnectSigninContext();

Collection<Scope> requestedScopes = new Collection<Scope>();

requestedScopes.Add(Scope.ContactsView);

AppInformation appInfo = new AppInformation("00000000YourClientID", "YourSecretKey", requestedScopes);

user1.GetToken(appInfo);

EnableMessengerConnectBrowsing();

}

The SigninSynchronous method fires when the user clicks the Signin button. The really interesting part here is the scopes collection:

Collection<Scope> requestedScopes = new Collection<Scope>();

This line makes it easy to add the scopes that control what Windows Live data you can access on a user's behalf. In the starter kit, we're getting the WL_Contacts.View scope from a pre-defined constant, as shown in the line:

requestedScopes.Add(Scope.ContactsView);

If we wanted to request additional scopes, we'd just need to call requestedScopes.Add again for each additional scope. Check out the SDK for more information on what scopes are available, and what they do.

Once we have the scopes we want, it's just a matter of creating a new AppInformation object that contains your application's client ID, secret key, and requested scopes. The GetToken method handles opening the Windows Live Consent dialog box and processing the access token we get back when the user signs in successfully.

The btnNavigate_Click method is very similar to what you would do if you were writing a web application.

private void btnNavigate_Click(object sender, EventArgs e)

{

try

{

Uri someUri = new Uri(txtUri.Text);

WebRequest webRequest = HttpWebRequest.Create(someUri);

webRequest.Method = "GET";

webRequest.Headers[MessengerConnectConstants.AuthorizationHeader] = user1.AuthorizationToken;

WebResponse webResponse = webRequest.GetResponse();

StreamReader responseStreamReader = new StreamReader(webResponse.GetResponseStream());

String response = responseStreamReader.ReadToEnd();

XmlDocument doc = new XmlDocument();

doc.LoadXml(response);

StringBuilder formattedBuilder = new StringBuilder();

XmlWriterSettings settings = new XmlWriterSettings();

settings.Indent = true;

XmlWriter writer = XmlWriter.Create(formattedBuilder, settings);

doc.WriteTo(writer);

writer.Close();

txtOutput.Text = formattedBuilder.ToString();

}

catch (Exception exception)

{

txtOutput.Text = exception.Message + "\r\n" + exception.StackTrace;

}

As you can see, it takes a URI and creates a WebRequest using the access token of the Windows Live user. As this is a pretty simple example, the method just writes the response back out to the dialog box. This is where you can leverage the REST Explorer and the Windows Live SDK to build more functionality into the sample.

We hope this starter kit gives you some good insight on how to build desktop applications with Messenger Connect. We're working hard on providing more information on how to code with Messenger Connect - meanwhile, if you have questions or feedback, please leave a comment.

What is new in the latest Messenger Connect release

2010-10-13T00:12:00Z

Jeff just announced on Inside Windows Live that Messenger Connect is now out of beta. In this post I want to give you some context on the technical changes. These changes are the result great feedback from the 2500+ people who participated in the beta and a couple of months of development time. We focused on: Making it easier to get up and running, easier and faster development, and delivering some core scenarios based on feedback.

Easier to check out

If you are new to a service you want to: understand what it can do, kick the tires, and get access quickly. We revamped dev.live.com so you can more quickly determine if Messenger Connect is something you want to add to your site. Seeing-is-believing, so we added a few links to small sample sites (try them: identity, sharing badge, chat control).

During the beta we got a lot of the questions about which permissions (scopes) web sites can ask consumers for. Some scopes are “restricted” and they are technically available in the platform but were not made available to all companies for various reasons (security, privacy, supportability, etc.). We hadn’t done a great job of making it clear which ones were widely available and which ones were not (in line with our data portability & privacy principles) – so we rewrote the Messenger Connect Scopes page to appropriately set expectations with developers.

Once you decide to add Messenger Connect to your site, we wanted to make that easier to do, so we created some new tools. For the sharing badge (which doesn’t require registration via our developer portal), we now list all the “aggregators” that include the Messenger sharing badge. We also built a small prototype tool to demonstrate how you can generate the code to add the badge to your site. This prototype does some interesting things like only showing the sharing badge for specific browser locales etc.

If you are using functionality like identity, social distribution, and in page IM/chat, you must have a Client ID – you can now get a Client ID via the developer portal without requiring acceptance into the beta. You can just go to https://manage.dev.live.com and sign in with your Windows Live ID, and create a Client ID. During the beta we had limited access and were periodically onboarding developers.

Easier to adopt and integrate

We spent a lot of time thinking about how we can make it easier for developers to complement their websites with a Messenger Connect implementation. To do this we focused on the questions and suggestions from the people who participated in the beta. We wrote a new developer guide, which outlines how you can start building applications that integrate with Windows Live.

Whilst coding, developers like to run code over and over again, tweaking it a little, but services need throttling limits for overall service stability. To overcome these conflicting requirements, we created the debug endpoint which has very high throttle limits. You can code away and publish tons of activities without fear of a throttle limit error messing with your development mojo.

For sharing user activities into Windows Live, ActivityStrea.ms is super powerful specification, and we love it. But the format itself isn’t the prize – your content (or user activity) and how it appears in the user experience is. We support ~20 different templates, but knowing which will appear best in Windows Live and get the most amount of clickbacks is sometimes difficult. That is why we created the ActivityStrea.ms template selection tool which helps you select the template, see the code, see how it is going to be rendered in Windows Live (and which parts of the ActivityStrea.ms get rendered where), and try it out.

Partners using Messenger Connect for identity and calling the Profile API gave us feedback that multiple calls were required to deliver mainstream scenarios (such as: get the user’s name, email address, and profile picture). To make this easier we condensed the response for the Profile API and also made the avatar available without authentication (of course user consent is required).

More complete, and consistent with our data portability and privacy principles

During the beta we heard about 2 things which were blocking adoption: 1) I want to be able to email the connected user’s friends, and 2) the chat control is cool, but moderation is required.

Given our view on data portability and privacy, instead of sharing the connected user’s friends’ email addresses, instead we created an Invitation API. This API enables web sites to send out email invitations on behalf of the connected user to their Windows Live friends. This increases deliverability and also conversion because it is sent on behalf of the connected user.

The Chat Control is a good way to harness the power of digital flashmobs (where lots of people will be on the same site at the same time) and will want to be able to chat or comment on an item in realtime. The comments aren’t persisted but they are visible in your site. We added after the fact moderation of the chat control. You can enable a chat moderator to delete messages, view a larger message history, and block users from posting.

Analytics are a key part of any project. In this release we have added more analytics reports and ways for you to see exactly how your Messenger Connect implementation is performing.

Finding where to invest and where not to

Based on feedback from early adopters, the strongly typed Messenger Connect .NET library has been discontinued. Future development efforts in this area will focus on samples that work directly with our REST-based web services.

Just the beginning

This release was driven by our beta participants because they gave us great feedback. If you think there is something we should do or change, please spend some time in our forum dev.live.com/forums.

Angus Logan

Senior technical product manager, Windows Live

Windows Phone People Hub Powered by Activity Streams

2010-10-12T03:24:00Z

As you may have heard, Microsoft made a major announcement about Windows Phone 7 this morning. On the Inside Windows Live blog, my colleague Chris Jones wrote about some of the many places where Windows Phone integrates with Windows Live in this blog post.

Here on our Windows Live for Developers, I’m excited to let you know that the Windows Live activities on the “People Hub” of Windows Phone 7 are powered by Activity Streams. Yes, the same Atom Activity Extensions format that I wrote about in August are powering the “what’s new” view on the Windows Phone 7 “People Hub.”

Also, while the above screenshot shows only Windows Live and Facebook, if you connect other services to Windows Live like LinkedIn, YouTube, Flickr, WordPress, and ~70 more, you and your friends will also see these in the People Hub experience on Windows Phone 7.

For example of what a Windows Live Activity Streams feed looks like, browse to your Windows Live Profile at http://profile.live.com/ (or feel free to use mine) and then click the orange RSS/Atom button in your web browser to see a public version of that user’s activity stream. You’ll see a URL like:
http://api.live.net/Users(-5141839532282463176)/Activities?$format=atom10&mkt=en-US
and if you View | Source, you’ll see the Activity Streams feed, just like what is used by Win Phone 7:

If you’d like to learn more about Activity Streams, visit http://ActivityStrea.ms/, and if you’d like to join the Windows Phone 7 team in developing with the Windows Live Activity Streams API’s, check-out this blog post and http://dev.live.com/. Thanks very much--
--Rob

New research supports business impact of “Connecting”

2010-09-21T20:18:20Z

One of the things I’ve found hard to measure is the industry’s perception (in aggregate) of the impact to user engagement and user acquisition when a site deeply connects to large audiences through “Connect like” solutions. This morning I may have found part of the answer in some new research from Gigya (conducted by Edge Research) that helps answer the question – “[what is] the value of social sign-on and the registered user?”.

You should read the entire research from here . The two big takeaways I got from the research about “social sign-on” (the term the research uses) are:

There is massive awareness and intent to deploy
There is clear alignment in the potential benefits, and a belief in achieving these benefits

Massive awareness and intent to deploy

The research showed a huge awareness with 92% of respondents said that they have heard of solutions that allow sign in using an existing [social] identity. Beyond the huge awareness, for online publishers about 59% had either fully implemented or had an implementation in progress.

Clear belief in the benefits

Another interesting tidbit is that the top 3 potential benefits (of a total of 10) were well aligned from both an importance and also a belief in the likelihood of achieving the benefit.

Potential benefit	Importance	Likelihood of being achieved
Increase engagement/relationships	84%	77%
Richer profile information to target and customize	80%	81%
Easier to share information and promote organization to social network	77%	78%

There is a lot more in the research, check it out here, and if you have any data or research you’d like to share – leave a comment!

Windows Live and Activity Streams

2010-08-26T01:15:33Z

Did you know that Microsoft’s Windows Live has been actively embracing the emerging Activity Streams open standard?

About a month ago, I traveled to Portland, Oregon, USA to participate in a “Federated Social Web Summit” organized the day before OSCON by Evan Prodromou and the team from Status.net. We spent the morning with each participant demo’ing their project or protocol for about five minutes. Below is my attempt to re-format my presentation as a blog entry.

---

My name is Rob Dolin and I’m a Program Manager on the Windows Live Social team. I’m also a co-author of the Activity Streams in Atom spec. You can find me on identi.ca as @RobDolin (and a few other places.) In the next few minutes, I’ll try to briefly explain:

What is “Windows Live” (from the perspective of federated social activities)
Where activity streams show-up
How can your project or service read activities from Windows Live
How can your project or service write activities to Windows Live
How can Windows Live direct users to your project or service

Windows Live as an activities generator, store, and display

Windows Live includes a set of web services, PC apps, and mobile apps:

Web services: Hotmail, SkyDrive, Profile, Groups, Spaces, …
PC apps: Messenger, Writer, Photo Gallery, Movie Maker, Mail, …; together “Windows Live Essentials” (WLE) – Download the WLE Beta
Mobile apps: Messenger for iPhone, Messenger for Windows Phone, http://m.live.com/, SMS Messenger

If you only do one thing to get a sense of how Windows Live integrates activities, I recommend downloading the WLE Beta and running Messenger.

Activity streams integrated throughout Windows Live and other Microsoft services

The activity stream from Windows Live (sometimes referred to as “Messenger social updates”) is integrated throughout Windows Live services and apps.

Windows Live Messenger

Windows Live Messenger has a new (default) full window view that dedicates more than 2/3 of the screen to the Windows Live activity stream:

Windows Live Hotmail

The new Hotmail homepage also includes a large area dedicated to the Windows Live activity stream:

The Windows Live activity steam is not just displayed in Windows Live branded properties, but it’s integrated into Outlook, MSN, and the forthcoming Windows Phone 7:

Outlook Social Connector

If you install the Outlook Social Connector for Windows Live Messenger, you’ll be able to see recent social activities of your contacts when you email with them:

As you can see above, the Windows Live activities stream doesn’t just include activities from Windows Live, in Douglas’s case above, it includes photos he shared on Flickr. Users can bring activities they have done from across the web into the Windows Live activities stream. I’ll explain more below about how you can enable your users to share activities from your service or app into Windows Live.

MSN

There’s also a new social module on the MSN homepage. On the USA homepage of MSN, this is in the right column:

Windows Phone

The upcoming Windows Phone 7 has a new “People” view that is powered by Windows Live Activity Streams:

How to Read Activities

On every one of the hundreds of millions of Windows Live users’s profile pages, there is a link to an Activity Streams (Atom) feed of that user’s publicly shared activities. You can easily get to this from your web browser by clicking the orange RSS/Atom icon:

This will take you to a feed of the user’s publicly shared activities on Windows Live. Try it on your own Windows Live profile: http://profile.live.com/.

You can view this in a web browser or your favorite RSS reader. And if you view the source of this feed, you’ll notice that it includes the <activity:verb> and <activity:object> elements of Activity Streams in Atom:

In addition to this link on profile pages to public Windows Live activities, developers can also read non-public activities (if a user gives permission) through the new “Messenger Connect” API’s. I’ll talk more about these below and you can learn more about these at http://dev.live.com/.

Activities in Windows Live from 75+ partners and growing

Since December 2008, users have been able to bring their social activities from dozens of services across the web into Windows Live. This has included services you likely know well like Facebook, YouTube, MySpace, Pandora, Hulu, and WordPress:

And this includes services from all around the world like AlloCine, Arto, Azbuz, Biip.no, Bilddagboken, Blingee, and more:

All of these integrations are powered by open standards including RSS 2.0, Atom 1.0, MediaRSS, Activity Streams in Atom, and at base, XML. In the next few paragraphs, I’ll briefly explain how you can add your project or service to write activities to the Windows Live activity stream so that they show-up in Messenger, Hotmail, MSN, Outlook, and Windows Phone.

How to Write Activities

There are three ways to enable your users to bring their activities from your project or service into Windows Live:

Badge
Feed
API

Writing Activities to Windows Live via Badge

The easiest way to write an activity to Windows Live is to have a user click a “badge” link. For example, try clicking this link: http://profile.live.com/badge/?url=http://status.net/2010/06/28/federated-social-web-summit-2010-announced. This takes you to a page (below) where you can add your own user message and confirm that you want to share that particular URL. As a developer, you can replace the “url” QueryString parameter with whatever URL your user has indicated he or she wants to share.

The http://profile.live.com/badge/ page will pre-populate a page title, description, and screenshot image for you from the page, OR you can pass these in as QueryString params to specifically populate them. You can also pass a return URL as a QueryString param so the user gets redirected back to your site after they share the link.

More details on the “badge” are at: http://msdn.microsoft.com/en-us/windowslive/ff796213.aspx including sample code you can quickly cut and paste into your own website:

Writing Activities to Windows Live via Feed

If your service has RSS, Atom, MediaRSS, or Activity Streams (in Atom) feeds, you can enable your users to tell Windows Live to poll their activity stream feed from your service. To set-up your service, you get an Application ID and fill-out a relatively simple form at: http://manage.dev.live.com/

As shown below, this will ask you for some basic info like your Home page URL, Sign-up URL, Support URL, and of course, Feed type:

You’ll also tell Windows Live how to compose a URL to retrieve your feed. For example below, Windows Live asks users to enter a “User name” and then uses the “replacement patterns” you specify:

Windows Live gives you a variety of choices for “User input label” and has these values translated into over 40 languages so you don’t need to know how to ask a Hungarian user for their email address.

After you’ve set-up Windows Live to know how to poll your service’s feed, you can direct users to the page where they can add your service: http://profile.live.com/services/add.aspx?AppID={YourAppID}&ru=http://www.YourService.com/return. You can even pass a “ru” QueryString parameter to specify the “return URL” for Windows Live to direct users to after they have connected Windows Live to your service. To get started, go to http://manage.dev.live.com/.

For each user who connects your service, Windows Live will start polling relatively frequently (every 30-60 minutes) and then start polling less frequently for less active users on your service.

If your service already has RSS, Atom, or Activity Streams feeds, this is likely the easiest way to help your users bring their content into Windows Live. To get the nicest looking results (i.e. photos treated as photos, etc.) you might just need to add a few <activity:…> elements as described in the “Choosing your Activity Type(s)” section below.

Writing Activities to Windows Live via API

Finally, your service can also write activities to Windows Live via our “Messenger Connect” set of API’s. You’ll set-up your connection to Windows Live and similarly point your user to an add.aspx page passing-in your AppID. The user will consent to have you write activities on their behalf (and possibly do other things like read and write SkyDrive photos or Messenger contacts ) and the user will be returned to your site (or client application) along with a token you can use to make calls on the user’s behalf.

To push write activities to Windows Live, you’ll make HTTP POST’s where the body of your request is in the Activity Streams in Atom format. The below screenshot from the online documentation describes how this gets rendered:

While there are potentially hundreds of <activity:verb> + <activity:object> combinations from Activity Streams, Windows Live supports a large portion of the most common combinations:

More details on publishing activities to Windows Live via API can be found at: http://msdn.microsoft.com/library/ff748785.aspx.

Choosing your Activity Type(s)

(This section was added at the suggestion of my colleague, @AngusLogan)

Whether you’re writing via feed or writing via API, if you choose a specific pairing of <activity:verb> and <activity:object-type>, users will potentially see your activity looking differently. For example:

A “Post” of a “Status Update” is displayed in Messenger as:

A “Post” of a “Photo” or a “Post” of multiple “Photo” objects in a target “Album” looks like:

A “Post” of a “Bookmark” looks like:

And a “Post” of a “Blog-entry”:

There are about a dozen more variations and you can see examples of what all of these look like on the web and what the XML for these looks like at: http://msdn.microsoft.com/en-us/library/ff748785.aspx.

Thank you, more?

I hope that you found this blog entry both useful and informative. To learn more:

Download Windows Live Essentials for PC and/or Messenger for iPhone
Connect some of the services you use: http://profile.live.com/services/
Check-out Messenger Connect and all of the great information at http://dev.live.com/

Leveraging Activity Streams, you can read activities from Windows Live into your app or service; and write activities from your app or service to Windows Live so your users and their friends will see them in Messenger, Hotmail, MSN, Outlook, Windows Phone, and more.

Thanks very much for reading and for your interest in Messenger Connect—

--Rob Dolin
Program Manager, Windows Live team

P.S. If you enjoyed this blog entry and would like to see more blog entries along similar topics, please leave a comment explaining what you’d like to learn more about.

Identity (authentication, profile & relationships)

2010-06-28T17:36:00Z

There are over 500 million Windows Live IDs that are used every month. That is a lot of users who can sign into web sites. In addition to base level authentication you can also pre-fill registration forms with things such as the user’s email address, so that information doesn’t need to be manually typed again and again (remember this video?). Users are able to quickly sign in and sign-up without needing to enter a username and password. Many users will already be signed into Windows Live (e.g. Hotmail) so they won’t need to enter their password again and can effectively sign into your web site in 2 clicks (1 on the in the page, 1 within the popup window).

There are several additional things we’ve been working on from a user experience perspective. We’ll cover these in more detail in subsequent posts but they include:

Conditionally showing the sign in button if the user has recently signed into Windows Live ID (more technical info)
Registration forms can be customized based on the email address the user entered. E.g. if a user typed @hotmail.com (or any other email address in a Windows Live namespace) the registration form could be tweaked to encourage use of Messenger Connect (more technical info)
Inbound traffic such as email marketing/invitations to @hotmail.com addresses or Messenger social updates could include some parameters to tell the web site “the user came from Windows Live” to encourage them to sign in/sign up quickly using Messenger Connect (remember when Plaxo got 92% conversion?)

For more information about the underlying technology of authentication, see this post or this page.

My contacts/relationships are part of my identity too

Another thing we’ve heard from customers, and observed on the web, is that customers want to be able to automatically find their friends on a web site or be able to invite them to a site via email. Historically the Windows Live Contact API enabled users to take their entire address book with them to another web site for the purposes of friend finding (indexed by email) and friend inviting (by sending an email), or in very specific circumstances migrating their address book.

We believe in these scenarios, they are important, and we think they add value to users and partners. However, we also believe in sharing the minimum amount of data required to let a user complete a desired action (more info). To that end, in the near future, we will deprecate the existing Windows Live Contacts API and remove email addresses from the Messenger Web Toolkit JavaScript Object Model. We will post more information regarding the specific timelines and what this means if you are using these interfaces. Moving forward, access to the entire address book (including email addresses of a Windows Live user’s contacts will be restricted (more info). We are working hard on building public APIs (subject to the Terms of Use) to enable the find my friends by email address & invite via Email APIs – look for another post on this topic in the near future.

Angus Logan (@anguslogan)
Senior Technical Product Manager
Windows Live

Realtime Shared Experiences with Messenger Connect

2010-06-28T17:36:00Z

Communication and sharing has emerged over the past few years as a critical element making experiences more personalized and compelling across the web. Lots of sharing is done asynchronously (via activity feed or email), but for some things you want real time sharing (it is tough to view photos or watch a TV show together asynchronously ). The challenge is: how do you know when your friends are available to engage in a real-time sharing experience, knowing the “presence” of your friends is important because it can shape how you engage with them. Having an always-on real time client is essential, because the likelihood of both users being on the same website at the same time is low except for very special circumstances. Connecting to a persistent chat client via a third party website is necessary to deliver on these scenarios.

People want to be able to share experiences like inviting a friend to a site in realtime, chatting with their friends without context switching, and see who else is on the web site. By integrating Messenger, the #1 most used free instant messaging service in the world (see some staggering stats) into your site you will be able to:

Let users connect with their friends in a differentiated, more personal mode of communication
Reach their friends no matter where they are, on your web site, on their phone, in one of the many Messenger clients (Windows, Mac, iPhone, etc.)

By adding real time experiences to your site, you are in essence making the site do something it didn’t do before, and conversations are “sticky”, therefore user engagement will go up.

Some shared experiences you can add to your site are:

Targeted (to one person or a few people), real time sharing of content. An example of where this is useful is sharing a picture that you want to discuss, or collaborating on travel plans – things that require realtime action by the other party.
Creating immersive experiences and reducing context switching - if someone is watching your glorious full screen video or playing an immersive game, they may be worried they’ll miss conversations or not be able to chat with their friends, embedding chat in your media consumption or game play experience will reduce context switching.
Rendezvous (are my friends on this site?) – for high traffic properties such as live streaming events or video play back, being able to tell if your friends are on the site (after opt-in of course) can drive more time on the site and shared experiences.

Implementation Options

There are a range of implementation options ranging from simplest (least amount of time to code) to most flexible:

Sharing Badge – the sharing badge can be added to a site with just a few lines of HTML and can allow users to publish/broadcast to Messenger Social or IM content to one of their friends

Chat control for real time events – to allow users on the same page to leave real time messages for each other. Users will be able to see the messages from their friends and others on the site.

UI Controls – a set of JavaScript building blocks which can be combined to speed up development. These controls can be easily skinned using CSS and extended using JavaScript. Try the Controls Playground.

JavaScript Library – the most advanced and most powerful way to integrate real time experiences into your site.

To get started adding real-time shared experiences so your site, check out this documentation.

Angus Logan (@anguslogan)
Senior Technical Product Manager
Windows Live

Social Distribution

2010-06-28T17:35:00Z

Messenger social is the “newsfeed” which is associated with a Windows Live user and shown to their Messenger contacts across Windows Live, including Messenger and Hotmail. The new Messenger full view is optimized for showing users their friend’s activity across a range of sites. For a limited set of partners (Facebook and MySpace today, LinkedIn coming soon) it allows users to comment inline back to these sites. For others, it allows users to share activities with their friends in Windows Live and enables users to click through to partner sites.

The simplest and most unique is the Messenger Connect sharing badge. This badge operates like other sharing badges, resulting in a social update. If the user chooses to; they can send an instant message to one of their Messenger contacts and have a conversation in real time about the content.

An individual entry in the newsfeed (aka activity) is known as a social update in Messenger. There are many different types (~ 20) of activities (e.g. pictures, comments, ratings), and when clicked they drive traffic back to the partner’s website.

The supported templates will be evolved on a quarterly basis as new activities become popular. Messenger Connect uses the ActivityStrea.ms format which is an emerging specification for making user activities portable.

A screenshot of the new Windows Live Messenger in full mode, activities appear on the left hand side

Screenshot of Messenger social in the Windows Live Messenger for iPhone

For a website to publish to Messenger social, push (via JavaScript and REST) and pull interfaces exist. The pull interface can be done with existing RSS or Atom feeds with minimal modifications. Below is an example of a comment and the corresponding Atom feed:

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"      
 xmlns:activity="http://activitystrea.ms/spec/1.0/"  
 xmlns:thr="http://purl.org/syndication/thread/1.0" 
 xmlns:media="http://purl.org/syndication/atommedia">
  <title>Title of the feed</title>
  <id>http://www.contoso.com/profileid</id>
  <link rel="alternate" type="text/html" href="http://www.contoso.com/profile"/>
  <updated>Mon, 10 May 2010 14:12:21 GMT</updated>
  <entry>
    <id>http://www.contoso.com/profileid</id>
    <title>Cool Stuff</title>
    <published>Mon, 10 May 2010 14:12:21 GMT</published>
    <updated>Mon, 10 May 2010 14:12:21 GMT</updated>
    <link rel="alternate" type="text/html" 
     href="http://www.contoso.com/link_to_content"/>
    <content type="html">I think this is cool</content>
    <activity:verb>http://activitystrea.ms/schema/1.0/post</activity:verb>
    <activity:object>
    <activity:object-type>http://activitystrea.ms/schema/1.0/comment
    </activity:object-type>
      <title>Cool Stuff</title>
      <link rel="alternate" type="text/html" 
       href="http://www.contoso.com/link_to_content" />
      <link rel="preview" type="image/jpeg" 
       href="http://www.contoso/thumbnail.jpg"/>
      <summary>I think this is cool</summary>
    </activity:object>
  </entry>
</feed>

To let your users share activities from your site with their friends in Messenger social, visit this page. Additionally, if you know what the next big social activity type will be, leave us a note in the forum.

Angus Logan (@anguslogan)
Senior Technical Product Manager
Windows Live

Developing with Messenger Connect: Recognizable & intuitive

2010-06-28T17:35:00Z

The primary goal of Messenger Connect is to help web sites & apps grow their traffic and engagement, at a reasonable cost. To that end, the technical implementation and business terms have been designed to be predictable for web developers and marketers who are familiar with the social connections domain.

First question I get asked: Is Messenger Connect standards based?

We’ve tried to make Messenger Connect as easy as possible for developers to implement. Where possible, the latest emerging specifications and standards have been implemented and Microsoft engineers are actively involved in the community to help evolve the technologies which enable the relatively new use case of social connections. Some of the technologies we have implemented or contributed to are: OAuth WRAP, Portable Contacts, ActivityStrea.ms, and OData. What about the next big thing? As new technologies are created, and developers ask us to implement those technologies, we will work with the community and evaluate adding them to the mix.

Implementation options

Messenger Connect can be used on web sites (and other apps) to provide Windows Live users access to their information and communicate/share with their friends. This access to information and friends is made possible by several types of programmatic interfaces:

Badges – simple HTML tags that can be added to a page
JavaScript APIs (including user interface controls) which execute within most popular browsers and talk directly to the Windows Live services
.NET APIs which can be used in server-side ASP.NET code or in rich client applications
RESTful services end points which can be called in a server-to-server manner

Badges

Some developers don’t want to write JavaScript or server side code. That is OK. Our sharing badge can be simply added to a page in a few lines of code.

<a href="http://profile.live.com/badge?url={your URL}" title="Share with Messenger" target=”blank”>
  <img style="border-style:none; vertical-align:middle; margin-right:4px" 
     src="http://img.wlxrs.com/$Live.SN.MessengerBadge/icon16wh.png" 
     alt="Share with Messenger" />Messenger</a>

Try it: Share

Consent, access, privacy, data rights, revocation

We recently posted about the privacy aspects of Messenger Connect (read it here). We strongly believe that users own their data and they should be able to share or access it from the websites and applications they want to. Web sites cannot access any of a user’s non-public information from Windows Live without prior consent (see the experience below) from the Windows Live user. App developers are encouraged to only request the bare minimum of permissions required to complete the desired scenario in a just in time manner (E.g. if a user is signing up, ask for their profile, if a user is adding something to their calendar, ask for calendar write permissions). If a user chooses not to grant permission for the site to access what they requested, the web site must handle the exception flow and reduce the permission requests, or explain why those permissions are required.

If the user leaves the “Remember this connection” checkbox checked (it is checked by default), the web site will be granted permission for 1 year (or until the user revokes the permissions). If the user unchecks the “Remember this connection” button, the web site will get access for 3 hours. At any point in time the user can browse to http://consent.live.com and revoke the permissions they previously granted the web site. After the token expires, or the user revokes permission, the web site would get 401 Unauthorized errors when trying to access the data, and would need to re-request that the user grants permission.

The web site renders a “sign in” button either manually by creating HTML, or using the wl:signin tag. If the web site uses the wl:signin tag (more info), an additional attribute can be added to only show the sign in button if a Windows Live cookie exists.
The user browsing the website (e.g. www.example.com) and sees a Messenger Connect button and clicks Sign In. To ensure the most Windows Live users know they can “Connect”, the iconography used for button will be aligned behind a single brand used across all “non-Windows Live” web sites (i.e. the current Hotmail / Messenger / Windows Live / SkyDrive brand fragmentation will be reduced in “off-network” scenarios).
A popup window is opened which includes the partner’s logo, a link to their Terms of Service and Privacy Statement. The partner must clearly outline in their ToS & Privacy Statement what they will be doing with the permission granted by the end user.
The user can click “What will I share?” to see each individual permission the partner is requesting.

If the user grants permission, a token is returns to the site, and the window will be closed.

One a website has been granted the appropriate permissions and has received the token, access to the user’s Windows Live data & services is possible through two interfaces: JavaScript & RESTful interfaces.

The permission granted is for 1 year (unless the user unchecks Remember this Connection). If the web site wants to access the Windows Live resources without the user being present, or without the user seeing the Messenger Connect consent screen again, the token should be stored alongside the user’s profile in the partner’s website.

If the user changes their mind and no longer wants the web site to have the ability to interact with their Windows Live account, the user can go to http://consent.live.com to revoke permissions at any time. If the partner tries to interact with the user’s Windows Live account after consent has been revoked, they would get “unauthorized access” errors and would need to re-request access from the user.

JavaScript libraries & user interface controls

Adding a script reference to the Messenger Connect dynamic loader enables access to a wide range of Windows Live data and Messenger features, including IM conversations. Developers can choose to use the data objects only or can add UI elements such as <wl:signin>, <wl:userinfo> or <wl:bar> to their page. You can experiment with the data model and controls hands-on using our new interactive SDK at http://isdk.dev.live.com/.

RESTful service endpoints

A set of cloud endpoints are available to web sites and applications for the purposes of accessing and managing user data. Generally the RESTful service endpoints will be used for web sites that want more of a “roll your own” approach to data access. Additionally, the RESTful endpoints are useful for sites that want to access the user’s data while the user is not present (for example: out of band processing of data - each week the website could make a call to Windows Live to download a user’s address book to see if some of their Windows Live friends have joined the web site).

These endpoints are multi-headed (the data is generally available in several formats), and can be queried and sorted. If developers prefer the data to be returned in several formats this is easily configurable using the $format query string key (for plain XML $format=XML, for JavaScript Object Notation (JSON) use $format=JSON, the dynamic formatting is also applied to emerging specifications/standards such as $type=portable). Additional formats for representing user data will be added based on partner feedback.

The RESTful service endpoints are also intelligent and most data-types exposed will support filter, select, orderby, and count the protocol used is the Open Data Protocol (OData).

Developer tooling

To make it easy for developers to kick the tires, we’ve created a few tools: the Controls Playground, the API Playground, and the REST Explorer – these tools will evolve over time as we see where developers need help. In a future post we’ll share details about the statistics which will be available from the application management portal.

The Controls Playground lets you quickly preview the Windows Live UI controls in action, customize controls and see results in real-time and also generates markup for these controls for you to copy, paste in your application.

The API Playground lets you try out the API service to see what type of interactions are possible:

Select common tasks such as adding a new contact to Windows Live, and preview the code
See common API usage patterns
Run API code, using sample data, and see the output in real-time
See the underlying REST HTTP traffic including request and response

The REST Explorer lets you interact with the RESTful endpoints directly against your own Windows Live ID.

If you have any questions about the different ways of developing with Messenger Connect, please visit our forums.

Angus Logan (@anguslogan)
Senior Technical Product Manager
Windows Live

Messenger Connect – Making your data more portable while retaining control over its use

2010-06-25T23:30:47Z

Last week Omar Shahine blogged about our new privacy features in Windows Live, where we’ve made some improvements that we hope you will appreciate and find both powerful and easy to use. We also recently announced Windows Live Messenger Connect, an exciting new feature set that enables you to easily connect to Windows Live from third party applications and lets you take your Windows Live experience and data, with your consent and at your discretion. Additionally, we also announced the new Messenger (try it now), which provides the most complete picture of what your friends are doing across your social networks and other sharing sites, including comprehensive integration with Facebook, LinkedIn, and MySpace.

We believe that you should be able to choose to take your Windows Live data with you when you travel the web. Messenger Connect allows you to do that by providing a way to sign in to third party web and client applications using your Windows Live ID. Messenger Connect allows you to bring your Windows Live profile and contacts with you; easily share with your friends and enable Windows Live Messenger-based chat within third party applications; and access your photos, calendar, and more. In order to enable third party applications to ‘connect’ and interact with Windows Live accounts, we needed to design to help to ensure that customers’ data is protected and accessed in a manner consistent with customers’ expectations and desires, as well as enable great partner experiences. These principles guided our design work:

Principle 1: Data portability (you own your data)

As a top-level principle, we believe that customers own their data. Your identity and profile, your address book, your newsfeed, your photos, your documents: as a Windows Live customer, you own all that data. So you should be able to take that data with you. Our role is to help you protect your data, help you make informed decisions about how your data is accessed and updated, and help you port your data to other places like the PC. That means that if you would like to access your Windows Live data from a different third party service, or even take your data completely to another service, you should be able to do that. To enable this, we give you ways to export your data from Windows Live into common formats, so that you can import it to wherever you like, as well as in many cases make this more seamless with direct integrations with partners. In a world where people are connecting services back and forth from each other, this can be complex. Just to be clear, when you connect one of your social networks (like Facebook, MySpace, and LinkedIn) to Messenger, any of your data or your friends data made available to Messenger via those connections is governed by our partners’ policies and our agreements with them.

Principle 2: You have control over your data

As Omar discussed in his post, customers should be able to easily control who has access to their data in Windows Live. You entrust Windows Live with your data, and it is only available and accessible within Windows Live. But we also know that you may want to be able to access your Windows Live data in the third party applications or websites you use. For example, you may want to share your photos or other non-public data with your friends. We make it possible for you to do so, but you have to give us your consent first. And, if at any point, you decide you would like to revoke a partner’s access to your data – you should be able to easily do so.

Principle 3: Right data for the right scenario

We believe that third party applications that access Windows Live should only access the minimum amount of user information required to complete the desired scenarios. For example: if a web site only needs permission to publish social updates, they shouldn’t also request permissions for reading photos.

Messenger Connect: Making my data and my friends data available in a responsible manner

There are cases where challenges and tradeoffs between privacy and data portability exist. An example of this tension is where a customer would like to share their complete address book with a third party, and that address book contains information such as email addresses and phone numbers. The contents of my address book are a combination of “my information” as it is “my address book” but may also include my friends’ email addresses and phone numbers. These shared data ownership scenarios are complex and have informed our design choices.

Independent of the information type or service access being made available, we have been working to replace unauthorized “screen-scraping” models, which require customers to share their usernames & passwords (“credentials”) in an unsecure manner with many sites, with the use of safer, legitimate APIs. The use of legitimate APIs and clear user consent flows have been important across the industry as they provide a safer alternative to requiring customers to share their credentials with third parties. Moving third parties away from screen scraping and the practice of asking users for their credentials without the use of APIs that use delegated authentication (more info) is important because when you share your credentials in the clear these websites can now act on your behalf. Even if a web site is not malicious, your credentials could be exposed if the third party service is compromised. Use of APIs helps to promote customer credential security, enables selective disclosure of information and the ability to revoke access.

To help us safeguard customers’ privacy and enable partner scenarios, we’ve created two distinct tiers of partner access policies. Both tiers require explicit customer consent, and follow the same security model, but are available for different group of third parties.

Public APIs: Our “Public APIs” are available to all developers and third parties to access in a self-service manner. Appropriate use is governed by our Terms of Use and Terms of Service, and is monitored for abuse reported by customers. Third parties can sign-up for access through our application management tool at http://manage.dev.live.com.
Restricted APIs: Our “Restricted APIs” allows third parties to access more sensitive information on behalf of customers. Therefore, these APIs are reserved for a select group of third parties explicitly approved by Microsoft, and meet clear and consistent criteria.

It is worth noting that within each policy tier, we have provided many ‘granular access scopes’, which allow third parties to request access to specific sets of data to complete a specific scenario. You can learn more about these scopes here.

The experience

So, let’s take a quick look at what the experience looks like when connecting with third party applications through Messenger Connect.

Sign-in and consent. When you click a Windows Live ‘Connect’ button on a third party website (explicit customer content is required), it initiates the sign-in and consent experience.

The initial screen provides you with the ability to sign in with your Windows Live ID, and learn about the level of access the third party application is requesting.

Making informed decisions. When you click the “What will I share?” link, you get detailed information about the specific pieces of data and capabilities the application is looking to access.

Managing access to your data. At any point, you can edit your permissions for any third party application within Windows Live and revoke its access to your data.

Reporting abuse. In addition, we provide “Report abuse” links from the Windows Live services so that you can inform us of any application that may be violating our Terms of Service, or generally behaving in a way you find inappropriate. In extreme circumstances, we also have the ability to suspend or revoke a third party application’s ability to use Messenger Connect, thus automatically revoking any permissions a customer granted the third party.

I hope this post has given you some insight into how we approach your privacy in Messenger Connect. As Omar previously noted, this is a challenging problem with many complex dimensions, and one that many in the industry continue to struggle with and refine. We are committed to continuously listening to our customers and partners, and together improving the experiences, technologies, and policies.

Angus Logan (@anguslogan)
Senior Technical Product Manager
Windows Live