FBML, YML, OSML oh my! HTML, meet Social

This morning Yahoo! launched the first fourteen OpenSocial applications for users of My Yahoo!, though as TechCrunch pointed out they did a bit of forking OpenSocial for their HTML-ish markup. It's not all that surprising considering that OpenSocial's support for this sort of markup (OSML) is relatively new, Yahoo! has been working on their application platform for quite awhile and OSML is just a bit strange.

For instance, the “small view” (i.e. the widgets which actually appear on the MyYahoo page) must be developed using “Yahoo! Markup Language” (YML), which is an extension of HTML with more bells and whistles. Yahoo is trying to bring together YML and the OpenSocial Markup Language (OSML), but right now they are forked. But turning an OpenSocial app into one that works inside Yahoo is getting easier.

Beware, the next few paragraphs get a bit geeky. YML (more info) is a lot like FBML and OSML (more info) in that they are all social markup languages. OSML is a bit different though, unlike YML which only works inside of Yahoo! and FBML in Facebook, OSML is part of the OpenSocial project and is designed to work inside of many different social network containers. If I wanted to display a user's name inside of my application, here's what it would look like:

• FBML: <fb:name uid="4" />
• YML: <yml:name uid="QPR12345" />
• OSML: <os:Name person="${User}"/>

In this simple example, FBML and YML are nearly identical; you pass in a userid. OSML is a bit different, they've created a rich templating language and you're passing in a user object instead of just a userid.

XFBML is the evolution of FBML but designed for use via Facebook Connect. Given that XFBML is designed to work for sites outside of Facebook.com, I'm much more interested in the ideas behind it and how they will ultimately be useful across social networks. Today XFBML is powered by JavaScript, though in the future I can imagine having actual HTML tags for this sort of social content. One of the large benefits of this approach is that a user's privacy settings can be maintained easily across sites (see Thoughts on dynamic privacy, though note that Chris' closing is no longer accurate).

Today XFBML works in such a way that I include Facebook's JavaScript loader in my page, the JavaScript walks the page's DOM looking for tags like <fb:profile-pic uid="4" />, uses your browser (and thus your current cookied session) to request the user's photo, and then based on the user's privacy settings and your relationship to the user fills in their photo (or doesn't). This provides two main benefits: 1) if you only share your photo with your friends, a non-friend browsing this page would not see the photo and 2) if you change your photo on Facebook it will change on this page as well.

Given how quickly the Social Web is coming together, I believe that HTML will need to support social elements someday soon. It's great to see this type of innovation by Facebook running in the wild, but the web itself ultimately evolves best when multiple competing approaches come together. Just as OAuth brought together the best practices from AOL, Flickr, Google, Yahoo! and others, there is a similar opportunity to bring together FBML, YML and OSML along with the client-side benefits of XFBML.

Facebook in 2010: no longer a walled garden

A lot of what I've been working on the past two years has been built on the assumption that the model that social networks use today will fundamentally change. Social networks have largely been built on the premise of being walled gardens in such a way that users can't communicate or share content or friends across networks; put simply this is what keeps a Facebook user from being able to send a message to a MySpace user. This is the same model that destroyed AOL, CompuServe and Prodigy's ISP businesses when normal people chose the Internet itself versus their thoughtfully curated walled gardens.

Over the past year we've seen an uptick in the infrastructure, development tools and projects designed to build the social web (n.b. I define the social web as something that is inherently decentralized, just like the web itself). On top of that, MySpace has gone from being off of most developer's radars to the most open social network in existence. With MySpace I'm able to use my account to sign into other sites via OpenID, share my activity using Activity Streams, build applications using OpenSocial, interact with their APIs using OAuth and access APIs that not only allow the creation of new content within MySpace's garden but also extract data from it.

While Facebook has made significant contributions to open source projects, ranging from some of their own to memcached, they've largely been absent from much of this progress around building the social web (remember, I define it as being inherently decentralized). Instead, like Microsoft they have willfully ignored many industry efforts in favor of their own proprietary development platforms. To their credit, they've been one of the most innovative social networks over the past two years, pushing the boundaries of what's been thought of as possible with features like social tagging in photos, Newsfeed, Platform, Beacon, integrated chat and Connect.

Two weeks ago this changed. Facebook joined the board of the OpenID Foundation, released two-way APIs around status, notes, pictures and videos, hosted a user experience summit focused on OpenID and released a blog commenting widget powered by Connect. Since then they've also talked about how they wish to support the Activity Streams project and have reiterated their commitment to the sort openness that we've been promoting as key pieces of the social web.

I know what you're thinking: "talk is cheap." True, Digg said they'd support OpenID three years ago and we've seen...or wait, no we haven't! I wish I had something concrete to point at to show that my next argument isn't crazy, but I don't. All that I can point to is the change I'm seeing when interacting with Facebook and their interactions with developers this year compared to the past.

My prediction is that by the end of the year Facebook will become the most open social network on the social web. I believe that not only have they now found business value in doing so, but also truly believe that the next phase of their mission, "to give people the power to share and make the world more open and connected" requires that they do so. This means that anyone building a business based on the notion that Facebook will remain a walled garden and won't adapt - as was true with traditional media when blogging came about - will have their world turned upside down this year.

Disagree if you like, but my second argument is that if Facebook does not seriously embrace these ideas this year that their current position of dominance will be usurped. I'm not saying that Facebook will go away, that all of my friends will leave, that it will become irrelevant or that tens of thousands of developers will move on overnight. This year, there is an amazing opportunity to find and define a proper balance between traditional walled-garden social networks and completely decentralized efforts like the DiSo Project.

Anatomy of "Connect"

I'm here at Webstock in New Zealand working on my talk for tomorrow (Open, Social Web) and one of the things I've been thinking about is all of the different "Connect" applications and products that have recently sprung into existence. I mean, we have Facebook Connect, Google Friend Connect, MySpace (thankfully not "Connect") ID, TypePad Connect, RPX and I'm sure the list goes on. I'm trying to break down all of these products - ignoring the underlying open or proprietary technologies that make them tick - toward a straw man definition of a "Connect" application:

1. Profile: Everything having to do with identity, account management and profile information ranging from sign in to sign out on the site I'm connecting with.
2. Relationships: Think social graph. Answers the question of who do I know on the site I've connected with and how I can invite others.
3. Content: Stuff. All of my posts, photos, bookmarks, video, links, etc that I've created on the site I've connected with.
4. Activity: Poked, bought, shared, posted, watched, loved, etc. All of the actions that things like the Activity Streams project are starting to take on.

In my mind, the Goals of all of these "Connect" applications are focused on helping people discover new content, people they already know as well as new people with similar interests. They also all help to reduce some of the major pain points when it comes to decentralization of social networks; signing up for a new account, eliminating the manual process of filling out your profile, uploading a photo and going through that madness of "re-friending" your friends time and time again. While all of these features aren't new, how this style of application combines them all certainly seems to be. If 2008 was the year of social application platforms (Facebook Platform and OpenSocial), perhaps 2009 will be all about "Connect" - whatever that means.

(I've put together an example of this using Facebook Connect and Citysearch as it seems to be the most complete example that I can find.)

Getting OpenID Into the Browser

Google Chrome did a smart thing: Less. They unified the search box and address bar, since that's what people do anyway. That gives us back precious pixels for the only thing that's as important to an average web user as where they're going: Who they are. Identity belongs in the browser. Don't just believe me, just this week ReadWriteWeb talks about The End of Online Anonymity and TechCrunch on how Facebook Connect is the Biggest Battle Yet For Social Networks: You, Your Identity And Your Data On The Open Web.

As Web 2.0 took root, the ability to login to a site, store preferences and build a profile became ubiquitous. Beyond reading news or blogs, it's fairly rare that you're on a site where you're either not logged in or don't have the ability to login. The downside is that just about every site requires you to create a new account and have cookies to keep you logged in. Thus when your cookie disappears, you have to login again. Maybe your browser's password manager eases this pain, but there are plenty of people that would be in a world of hurt if their browser every forgot all of their passwords (or they use a friend's computer).

If we remove passwords from the equation and instead use OpenID, there's the notion that upon visiting an OpenID enabled site (now numbering more than 25,000 across the web) you'll most likely submit a form telling that site about your OpenID. I might go to MapQuest and login by typing in my OpenID "http://www.davidrecordon.com/" or Ma.gnolia and clicking a "Sign up with a Yahoo! ID" button. These interactions, with various tweaks around them, are very much the status quo today. If OpenID wishes to see true mainstream adoption, this will need to change.

Imagine if your web browser really knew who you were on the web. Just as you login to your computer, what if when you fired up your browser, it said "Hello Dave" and asked you to "unlock it" as well (Chris Messina was quite influential in my thinking about it this way). In doing so you become securely logged into your OpenID provider (or maybe more than one of them) and as you move around the web your browser takes care of automatically logging you into the sites that you want to be, asking you about others, and helping you register with new ones using your OpenID. Argue as much as you want about the details in making this happen, but I think it's hard to disagree that making it easier for people to manage and use their identity (or identities) online is a bad thing.

There are a lot of proposals around how current OpenID interactions will change - a great summit on OpenID usability was held a little over a month ago - and whether it be more one-click buttons, less buttons, bigger logos, or email addresses I think it's also worth looking at what it will take to really get the browser involved. This certainly isn't a new idea, every major browser has the ability to remember passwords and FireFox even has those pesky user profiles so that people could theoretically have different cookies, bookmarks and other settings.

In the internet identity space this isn't a new idea either. Information Cards (more widely known by Microsoft's CardSpace implementation in Windows) have credit card like rich desktop integration built using WS-* and SAML. Dick Hardt's team up in Canada has built Sxipper for FireFox which helps with both OpenID and normal web forms as well. When I was working for VeriSign, we developed the OpenID Seatbelt which is also a FireFox extension designed to make OpenID easier and prevent phishing by detecting OpenID enabled sites and your provider.

Today, MySpace, Flock and Vidoop released a prototype of their implementation toward this vision with OpenID for Flock. All three of these browser plugins help you manage your OpenIDs, detect when you're on an OpenID enabled site, and then make it easier to sign in. To me, what Sxipper aspires to enable feels the most useful for a mainstream user.

OpenID for Flock is an add-on that polishes previous attempts of putting OpenID into a browser. While the user experience and graphics are quite a bit better than what I helped build at VeriSign, it's lacking the features that help prevent phishing (making sure you're actually logging into your OpenID provider versus a phishing site that looks like it) which is a bit surprising given Vidoop's involvement. That said, OpenID for Flock is Open Source as part of a project dubbed IDentity in the Browser (IDIB) which the same cannot be said for either Sxipper or VeriSign's OpenID Seatbelt. Given that IDIB is Open Source and already written as a Flock add-on, I'd certainly expect to see it ported to FireFox and there be far more community support of it compared to the other add-ons.

So where do we go from here? I don't know how to write great browser plugins so just doing it is out. It's great to see Flock's direct involvement in this Open Source effort as it shows browser vendors innovating and experimenting with how their own products must evolve to support identity. Maybe this will cause the other browser vendors to think seriously about what they too could be doing in future versions to help make identity management easer and more secure on the web.

In my mind, Gears can help us get there. While it started as a project by Google to evolve web browsers faster and add needed features like offline support, it's grown beyond that with offline support now coming in HTML 5 and a new Geolocation API. Today Gears runs on half a dozen different browser/platform combinations including FireFox, Internet Explorer, Safari, Chrome and Android. If there was ever a developer platform to build an Open Source cross browser implementation of what OpenID support might look like, Gears seems like the place to do it. Not only does this mean that we'll need to write less code to have it work in multiple browsers, but ideally if it became mature enough maybe the Gears team would choose to ship OpenID support as well? All of a sudden, the community could be down from a handful of browser plugins to one leading Open Source example.

What do you think? Do you agree that identity is becoming as essential to a browser as location? Should we content ourselves for issues like security to be relegated to a few dozen-pixel lock icon, or have Big-Red-Phishing-Warnings set a standard that important issues deserve significant real estate? Really though, should the browser become more actively involved in how you use the web on a daily basis?

Microsoft Releases a Technology Preview of OpenID for Windows Live

This morning at Microsoft's Professional Developers Conference, the Windows Live ID team announced that Windows Live ID will support OpenID 2.0 with a Community Technology Preview today and production support sometime next year.

Beginning today, Windows Live™ ID is publicly committing to support the OpenID digital identity framework with the announcement of the public availability of a Community Technology Preview (CTP) of the Windows Live ID OpenID Provider. You will soon be able to use your Windows Live ID account to sign in to any OpenID Web site!

Microsoft joins Yahoo! who implemented support for OpenID earlier this year for all of their accounts. By sometime next year, every AOL, Microsoft and Yahoo! user will have an OpenID which makes the emerging focus on improving OpenID's user experience even more important.

Angus Logan from the Live team has put together a quick screencast showing the current developer oriented process for testing the Windows Live ID OpenID Provider with an OpenID 2.0 enabled site.

Windows Live ID OpenID Provider Screencast from Angus Logan on Vimeo.

While this is great news from Microsoft, real web-scale adoption of technologies always faces a chicken-and-egg problem between developers and vendors. Developers don't want to adopt a technology without buy-in from platform providers and platform providers don't want to support a technology if developers won't use it. We've largely been able to successfully avoid this concern with OpenID as it grew from roots in an open source community with lots of people and companies involved in making OpenID what it is today. There are now well beyond half a billion OpenIDs available on the web which means we can mark the first phase of OpenID adoption, platform support, as a success.

The next phase of developer adoption will not be measured in the number of OpenIDs or sites that support it, but rather user experience, accessibility, and seamlessness of integration into a wide variety of applications and experiences.

Portable Contacts API Starts to Get Real

This evening Joseph and John of Plaxo and I have been hosting a hackathon at Six Apart for the Portable Contacts API (video about PorC). The Portable Contacts API is designed "to make it easier for developers to give their users a secure way to access the address books and friends lists they have built up all over the web."

We originally expected a handful of people to show up and hack on implementing bits of the specification, but so far have been blown away at the progress made and about the twenty people that came. Tomorrow is a summit style meeting hosted by MySpace also in San Francisco to try to finalize the specification among a wide range of providers and consumers. I'm expecting a handful of interesting demos, but wanted to share two that have already come together tonight.

Joseph Smarr and Kevin Marks of Google hacked together a web transformer that integrates Microformats, vCard, and the Portable Contacts API. Given Kevin's homepage which is full of Microformats, they've built an API that extracts his profile information from hCard, uses a public API from Technorati to transform it to vCard, and then exposes it as a Portable Contacts API endpoint. Not only does this work on Kevin's own page, but his Twitter profile as well which contains basic profile information such as name, homepage, and a short bio.

Brian Ellin of JanRain has successfully combined OpenID, XRDS-Simple, OAuth, and the Portable Contacts API to start showing how each of these building blocks should come together. Upon visiting his demo site he logs in using his OpenID. From there, the site discovers that Plaxo hosts his address book and requests access to it via OAuth. Finishing the flow, his demo site uses the Portable Contacts API to access information about his contacts directly from Plaxo. End to end, login with an OpenID and finish by giving the site access to your address book without having to fork over your password.

While the individual building blocks are fairly geeky themselves, pulling them together like has been happening tonight shows that we're only at the beginning of building the next generation of social networks. When the pieces work together, people won't have to know what's going on under the hood; it will just work--and will be almost like magic. John has more photos up on his blog.

Breaking Down What's Happening on the Social Web

The past few weeks, John McCrea, Joseph Smarr, and I have been shooting a 15 minute video podcast called TheSocialWeb.tv. Each week we try to break down what's happened in the Social Web in a way that is understandable so you don't have to be living and breathing this stuff.

This week we discuss Meebo's announcement of Community Instant Messaging since it continues the trend of making the entire web more social while using existing building blocks to do so. As Joseph explained, the underlying architecture Meebo is using is Jabber/XMPP. What this means is that unlike Facebook's Chat, social networks using Meebo's Community IM have the ability to interoperate from day one if they choose to do so. Google's Friend Connect is another great example of reusing building blocks where they take advantage of OpenSocial, OpenID, and OAuth. Overtime supporting these underlying technologies becomes easier as companies like Google and Meebo start to build them into their products.

Last week we focused on Gnip and Identi.ca, explaining how Gnip is helping to change the model of accessing data on the web. Traditionally web APIs have been focused on pulling data though things like Twitter's XMPP Stream and Gnip are starting to flip this model on its head. And next week we'll be taping from Facebook's annual developer conference f8 in San Francisco. So please check it out, subscribe to our RSS feed (yes, we know our enclosures are broken), let us know what you think, and how we can do a better job of explaining the Social Web in an understandable way.

Google's Social Graph API Learns a New Trick

This past February at Social Graph Foo Camp, Google released the first version of their Social Graph API. (see past Radar coverage) This API was focused on making it easier for developers to understand who a user is and find their other accounts around the web via publicly declared data.

Today I'm driving up to Foo Camp along with Brad Fitzpatrick, the developer of the API, where he has just pushed a new API method live called "OtherMe". This new methods focuses on making it easier for developers to get a holistic view of a user, their feeds, and some basic profile information. You can see this for my profiles in a pretty form from the API. Unfortunately it hasn't been documented yet, but if you're familiar with the existing API it is pretty easy to figure out and real documentation is on its way. This is another large step forward when it comes to opening the social graph. Today it has become many times easier to welcome a new user to your service by presenting a list of people they already know versus asking them if you can scrape contacts from their email address book(s).

Part of Brad's announcement of these changes is below:

Note that this is simply a mechnical transformation on the /lookup method, not offering anything that wasn't possible before. It's just that the transformation was tedious and error-prone and silly to have to repeat in each client library. Hopefully putting it in the server makes it more convenient for everybody.

Why is this useful? A lot of websites are now letting you list your other websites/profiles on your profile, but it's just as annoying to repeat this information on every site as it is to redefine your friends everywhere. If the site incrementally hits this API in the background as you enter profile URLs, the site can then recommend you link/share your other websites. Examples of sites that let you enter your other profile URLs and could use this API include: Pownce, Digg, Vox, Typepad, Movable Type, Plaxo, Friendfeed, Mugshot. And that's just off the top of my head from sites I'm familiar with. I'm sure there's a bunch more.

Is SocialMedia Overstepping Facebook's Privacy Line?

SocialMedia is an advertising network which places ads within social applications such as those on Facebook and MySpace. SocialMedia claims to be more effective in this type of advertising, due to a patent-pending technology they've developed named FriendRank. SocialMedia CEO Seth Goldstein claims that SocialMedia ads can pay up to 2.5 times more than traditional ads within social networks and that early tests show people are 200 times more likely to respond to a "social ad". See CNET's coverage of SocialMedia's FriendRank launch for more detailed information.

This sounds very compelling, but immediately raises serious questions around privacy and whether a Facebook user knows that SocialMedia is using their profile information in this way. While technology certainly makes this possible, are user expectations being set correctly? Facebook's Beacon functionality faced an uproar at its launch earlier this year not for the technology it provided, but rather for upsetting expectations around privacy, information sharing, and ultimately ad targeting. So how is SocialMedia getting access to the type of information required to create such a compelling social advertising network?

Facebook provides a customizable public profile page for each user (mine is here) which by default makes your name, picture, and a few friends publicly available. SocialMedia could and most likely is using this public information, just like anyone else could too. Multiple sources including ValleyWag and others familiar with the ad platform say that SocialMedia doesn't stop there. Rather they're very quietly also accessing information from Facebook Platform applications directly. This was originally broken by The Social Times a few weeks ago:

So how does SocialMedia display these targeted ads outside of Facebook? Through a collection of data via applications in combination with images obtained via user public profiles and unique cookies they can piece together who you are and who some of your friends are. This is off of Facebook.

The question then is, are social applications properly disclosing the fact that they give your information to SocialMedia, and is that action covered by a clear privacy policy? This is not about the technology behind how SocialMedia might access this information, but rather making sure that the technological implementation matches user expecations. We can start by looking at the process of adding an application on Facebook which does not appear to use SocialMedia for advertising:

If you've ever installed a Facebook application, you're familiar with this screen, which prompts you to grant explicit permissions to each and every application you choose to install. It should be noted that Facebook Platform does not have any affordance for allowing an application to share your information data with a third party. Facebook's Developer Terms of Service explicitly prohibit such sharing, and the technological implementation of the Facebook Platform API make it extremely likely that sharing such data would sometimes involve sharing a developer's secret key with SocialMedia as well. All of this is explicitly and strictly prohibited by Facebook's Developer Terms of Service: (emphasis is mine for readability):

"Facebook Platform" means a set of APIs and services provided by Facebook that enable websites and applications (collectively, "Applications") to retrieve data relating to Facebook Users made available by Facebook and/or retrieve authorized data from other Applications. The term "Facebook Platform" includes any data, images, text, content, code, APIs, tools or other information or materials provided by Facebook through or in connection with such APIs and services (collectively, the "Facebook Properties").

...

5) You may not sell, resell, lease, redistribute, license, sublicense or transfer all or any portion of the Facebook Properties, or use or store any Facebook Properties for any purpose other than as specifically authorized herein.

The bottom line is that though this might seem like an obscure technical issue, sharing user activity and profile information with SocialMedia would be as objectionable as the worst behaviors ascribed to Facebook Beacon. With Beacon people were surprised that their actions from around the web were starting to be shared with their friends on Facebook. It wasn't that everyone objected to this happening, but rather that it was implemented as opt-out which led to information being shared in ways that normal people didn't expect. This in turn completely killed Beacon with participating brands such as Coke dropping support. A few weeks ago Facebook shut off access to Slide's Top Friends application for "allowing access to non-friends' personal information" as reported by Inside Facebook. The following week Facebook's responded with a blog post Building Trust and Protecting User Privacy which started by saying:

Privacy is at the core of Facebook.

Because we provide users with rich privacy controls and respect their choices, users feel safe using Facebook to share their information with their friends. By opening up Facebook through Platform, developers have the opportunity to innovate on top of this information. In exchange, developers commit to treating user information with the same respect that users expect of Facebook. Our Developer Terms of Service strictly limit use of user data and serves as guidelines to these expectations.

But I truly believe that Facebook does try to protect user privacy and by doing so creates an environment promoting the creation of rich profiles tied to real offline identities and sharing more content between friends. Facebook has shown a history of learning from these situations over time. If Facebook learned so much about the dangers of surprise with Beacon, shut off Top Friends for sharing profile information, and continues to block access to Google's Friend Connect for redistribution of profile information then why are they still permitting Platform applications to possibly share this data with SocialMedia? As technologists we must be extremely careful in making sure that our implementations match a normal person's expectations. If we forget to do this, we could collectively end up killing something that might someday become great.

I've tried contacting SocialMedia to ask about how their advertising network works, though unfortunately while I've received replies have not had my questions answered. As full disclosure, I work for Six Apart which launched an advertising network for bloggers earlier this year, and has a privacy policy here. I'll be at O'Reilly's Open Source conference in Portland at the end of the month.

MySpace's Data Availability is not Data Portability

Yesterday MySpace, Yahoo!, eBay, Photobucket (also owned by News Corp), and Twitter announced the Data Availability Initiative. While I could write at length about how this shows the big companies have already realized how to diminish the DataPortability group's brand by linking anything they do "data portability," that isn't the point of this post. The crux of the announcement yesterday was that shortly MySpace would begin allowing third-parties to embed MySpace profile information within their own services in the name of "data portability". Unfortunately, the details around this remain buzzword-laden at best.

Their press release yesterday stated:

Additionally, rather than updating information across the Web (e.g. default photo, favorite movies or music) for each site where a user spends time, now a user can update their profile in one place and dynamically share that information with the other sites they care about. MySpace will be rolling out a centralized location within the site that allows users to manage how their content and data is made available to third party sites they have chosen to engage with.

At first glance this seems like a great thing. MySpace is partnering with Yahoo!, eBay, Photobucket, and Twitter to solve a pain point on the web; the inability to keep parts of your profile in sync around the web where you'd like them to be. The announcement didn't however offer any insight into how this would work beyond that, "the MySpace Data Availability initiative uses OAUTH [sic] and Restful APIs as its core technology underpinnings." After this announcement I had the pleasure of speaking with a reporter who was on the briefing call. He explained that MySpace said that due to their terms of service the participating sites (e.g. Twitter) would not be allowed to cache or store any of the profile information. In my mind this led to the Data Availability API being structured in one of two ways: 1) on each page load Twitter makes a request to MySpace fetching the protected profile information via OAuth to then display on their site or 2) Twitter includes JavaScript which the browser then uses to fill in the corresponding profile information when it renders the page. Either case is not an example of data portability no matter how you define the term!

To make this worse one of the pieces of profile information made available is a list of a MySpace user's friends. Once again there are two reasonable ways to do this: 1) MySpace provides a user's friends as a list of hashed email addresses to Twitter or 2) MySpace provides a user's friends as a list of MySpace usernames. While the hashed email route would certainly be simpler and easier for sites like Twitter to match against their own user database, I highly doubt this will be the implementation due to concerns around undesired account linking. Rather I think MySpace will choose to provide a list of other MySpace usernames. What this means is that in order for Twitter to make use of the information they must encourage all of their users to fill in their MySpace account on Twitter so that they can map a MySpace username to a Twitter username. Obviously in the best interests of MySpace to have more of their profiles linked to from around the web thus increasing page rank, visitors, and thus ad revenue.

At the end of the day it seems that MySpace is trying to become a large centralized profile repository on the internet. One where information might be available but certainly not allowed to be actually moved outside the network's walls. A good try, but just as no one would like Microsoft own identity for the entire web with Passport I fail to see how others will let MySpace own all of the profiles.

Update: Just got off a plane from London and realized that I missed a link to Chris Saad, DataPortability's co-founder, explaining yesterday that they "hope to see the MySpace “Data Availability” initiative evolve toward becoming a compliant implementation of the DataPortability Best Practices." While MySpace did not say in their release that Data Availability is a form of data portability, it certainly seemed to be interpreted that way.

Recent Posts

• App Engine, Facebook Platform, OpenSocial, and the Future of the Web on April 8, 2008
• Is Being Open Now a Priority for Facebook? on January 9, 2008
• Battling Social Network Fatigue ... By Going Open on December 18, 2007
• Web2Summit: Opening Up the Social Graph on October 19, 2007