A Simple Proposal for the Social Web

I’m writing this just before heading into f8 ‘08 (the Facebook Platform conference). Normally, I’m content to just sit back and analyze things and recommend how to adapt. But today, I think I know what’s going on (based on my recent work at Ringside Networks trying to integrate an external web site into our own platform). In the interest of being clear, I do NOT have any form of “insider” information. This opinion is based totally on my own work and the work of the Ringside team. Also, I’m trying a new format with sections, which is discouraged by the WordPress UI, but I have a lot to say today!

APIs and Clients

An important part of the social Web is the fact that applications can call APIs on social services like Facebook and one of the many OpenSocial social networks. If you have an existing property, you build an application that can be used in the context of the social network. This doesn’t necessarily mean that the application runs inside the social network (REST APIs allow a stand-alone application to play), but important parts of the context, like authentication, belong totally to the social network. There are two inefficiencies with this model:

1. A web site is not necessarily an application, and it might just want access to the user profile services, and
2. A successful web site with an existing user community probably already knows how to authenticate users and do interesting things with that identity

Users as Services

Lots of folks are probably now thinking, “sounds like OpenID” (okay, I’m assuming a lot about my readership, but bear with me). OpenID is great for letting users really take ownership of how they are authenticated. It’s taken me a while to be a believer, and, well, I’m not fully converted yet, but it is pretty cool. The problem with OpenID as it is today is that it isn’t as valuable as a Facebook login (yet). An OpenID lets a user of your web site or application confirm they are who they say they are. So what? That tiny bit of information is basically just an identifier that you can now use to store information. It doesn’t spawn a dialogue with the user, which is kind of the whole point of being social, isn’t it?

The real value of a Facebook user is that ample set of APIs that the application (or web site, once Facebook Connect launches, I’m pretty sure) has to communicate with the user and to enable them to bring their friends along for the ride. An authenticated Facebook user is a lot more valuable in this case than the equivalent, say, authenticated WordPress user. Technologies such as OAuth, OpenID, and XRDS (big parts of the DiSo project) will dramatically improve things, given time. The point I’m trying to make is that, from the perspective of the application (or web site) operator, the User is a set of services used to communicate in different ways with that User and with that User’s friends (insert your own privacy disclaimer here; I don’t have one handy).

Prediction Time

Here is my prediction for Facebook Connect: In the same way that Pages were introduced to have something just like a User, but without all the User “baggage” (like an identity, etc.), with additional features (like delegated authority to update the “profile”), and with modified features (Fans instead of Friends), I predict that Facebook Connect will enable Sites to connect to their APIs in the same way that Applications connect today, but without all the messy Application bits (like lists of developers, canvas pages, etc.).

Update: Okay, Facebook Connect was announced, and it is both more and less than I predicted. Yes, you use an API key to connect, but there is nothing special about a site calling an API. There appear to be some Connect-specific APIs, but they don’t yet appear in the distributed client (even in the sample app!). In addition, Facebook Connect provides some simple JavaScript APIs that activate some widgets that provide access to some of the built-in Facebook functionality. The most notable absence is any mention of running actual apps. I suppose it’s a good start, but it is really just inverting the relationship between the application and Facebook. Instead of Facebook being “in front”, the “app” (web site) is “in front” of the user. Of course, at times, Facebook is in front again (via those widgets). I think more can be done here, and I’ll be tracking this as things emerge.

fbOpen Analysis: Part 1: APIs

As an implementer of a Facebook-compatible API server, we’re taking a look at fbOpen, Facebook’s recent open source effort. I wanted to share some initial analysis that compares fbOpen with Facebook and with the Ringside Social Application Server. Let me get the caveats out of the way right up front. I realize the following:

 

1. fbOpen is young and it is intended to be focused on Facebook application developers.
2. Facebook very likely has non-public APIs that are used to operate Facebook.
3. Ringside serves a different set of users from either and has its own extensions.

 

Okay, with all that out of the way, here is the score card for APIs:

fbOpen: 19-

Facebook: 92

Ringside: 98+

I give fbOpen a “-” because even if a certain API is implemented, it may not actually do anything. It also may have a hard-coded implementation (APIs that touch the social graph generally behave this way). I give Ringside a “+” because every time our code base grows or a new application is developed, we add new APIs. In fact, I’m pretty sure that new APIs have been introduced since I tabulated this data.

The difference in number of APIs between fbOpen and Facebook itself is easily explained by the developer orientation. Even the no-op methods are only unimplemented because fbOpen doesn’t provide a full user experience. Most of the other missing APIs in fbOpen are related to Facebook core applications that are not present in fbOpen (Marketplace, Photos, Page, Groups, and Notifications). It may seem strange to refer to these as “applications”, but that’s exactly how Ringside implements these features and those applications are tied into the same APIs on a Ringside instance.

The differences between Ringside and fbOpen are a little more complex. There are Facebook Platform features that the current beta version of the Ringside platform does not yet provide (specifically friend groups and API batching, a total of 3 APIs). So Ringside is not (yet) a proper superset of fbOpen.

Out of the 92 Facebook Platform APIs, Ringside implements 41 of them and provides 57 “Ringside-exclusive” APIs. Interestingly, many of the unimplemented APIs support applications that Ringside does not provide (like Marketplace; Data, except for user preferences), similar to the omissions in fbOpen. Likewise, the Ringside extension APIs primarily either support additional applications that we provide (like SocialPay, Ratings, Favorites, and Items) or support administrative or additional access to the core applications that Facebook does not provide (like Comments, and several additional Admin methods).

If you see any errors in this analysis, please let me know. Also, please contact me if you’re interested in the raw data, which I retrieved from the Facebook Client Library for PHP, the Facebook Open Platform, the Facebook API documentation on the developer wiki, and the Ringside Social Application Server download on SourceForge.

Update: I have published my comparison spreadsheet here: fbOpen API Comparison

Identity Agnosticism

Not every web site is going to be (or needs to be) a hub. Sites can exist in a state where they are sustained by transient users. I typically refer to this kind of environment as a tide pool because it is reinvigorated by people passing by and enriching the experience by interacting with it. Sometimes, the barrier to interacting with these sites is set really high compared to the value users get from the site. Even a simple registration process may be too heavy for some users. Joshua Porter has a great blog entry on how users evolve from one stage of engagement to the next by crossing “hurdles”. What isn’t immediately clear from the picture is that in certain environments, people may stay a long time at one of these stages (or never get over the next hurdle). However, people are connected in interesting ways, and these connections may cause people in their social networks move from one stage to the next.

Recently, I had to find a remote control code for my universal remote provided by my cable company. I’m no expert on remote controls, but I know there are people who are. I also know that the community of cable company remote control users is large. So, I searched for a while and found several communities that track remote control codes for various remote control/TV combinations. Eventually, I found a user-contributed code that worked for me, but it was listed for a similar (not identical) TV model. Feeling a natural need to contribute back to the community that helped me, I tried to post back with my TV model to try to help someone who might be running a similar search. The site required me to create an account, give my email address, real name, etc. I just stopped right there. I came across this site via a search, and I had no relationship with the site (and, frankly, didn’t want to start a relationship). It’s a shame that the rest of the community would never benefit from this new knowledge.

My experience illustrates the need for “identity agnostic” services on the Web. What this means to me is that a site or service should not always care that they know everything about me, but instead should accept a “pointer” to an identity that they can use in certain situations, such as if someone responds to a post that I make (either a question about something I contributed or an answer to a question I asked, for example).

Emerging technologies like OpenID and OAuth, along with an easy way to integrate these services into niche web sites, will help the Web realize this kind of potential. Combined with social technologies, this kind of experience can really be engaging for casual users and can help site owners tap into the potential of the casual user’s social network. Not only would users be able to pose questions or post information to these “tide pool” communities, but they would drag along their entire social network. In my example, lots of my friends are local, and lots have the same cable service that I do. Besides potential answering a latent question that many of my friend might have, I can arm them with the knowledge that there is a niche site out there than could answer questions like this in the future, moving them from “Unaware” to, possibly, “Interested”.

The Ever-Expanding Social Web

The recent announcements by MySpace (Data Availability) and Facebook (Facebook Connect) are an important step in a natural evolution of the web toward integrating social features into every web site. As Ringside Networks demonstrated in our first two deployments (see The Business of Being Social), enabling a web site or social application to make use of a social context being provided by another party is important to support a user’s goals. Kudos to these two networks (and the many more I expect to emerge over the coming months) for recognizing that the user should have the power to use their social network how they see fit. Users should have this capability across and between networks as well, which is one of our technical priorities for the Ringside Social Application Server.

These first forays into identity and profile sharing appear to be about big social media sites starting to integrate with big social applications. Users will be able to share content broadly using existing social connections, which will certainly be a good thing. What these announcements really imply is a change in the dynamic between a social application and a social network, letting the social application be “in front” of the user with the social network being “behind” the social application. So, hypothetically speaking, instead of having to use the Digg Facebook application to share bookmarks with your Facebook friends, you may be able to do so from within the Digg site (possibly automatically, since this data may make its way directly into your Feed). Likewise, you may be able to use your Facebook login and password to login to Digg, hopefully making that one less password you will need to remember. Finally, you may be able to “assign” your Facebook profile picture and other profile fields to be use from within Digg for your profile there.

Ringside Networks provides an open source platform (currently in beta, available via SourceForge) that supports (among other features) the ability to tie multiple identities together and to use a social network identity to authenticate to a web site or a social application built using the Ringside platform. Now that there is explicit support for both authentication and profile data sharing from these large social networks, we have the possibility not just to tie the identities together but to use the entire profile as the base data when forming these associations on a third-party web site. Over the next few months, we will be looking at how to support not only these announcements by Facebook and MySpace, but also emerging open standards in this area (e.g. OpenID, OAuth, and OpenSocial). The major social networks opening up in this way enables us to empower sites that run on our platform to engage more deeply with their users and more broadly with the networks those users belong to.

Initial Ajax Support in Ringside Social App Server

Today’s post is a little more technical than I have been, but it’s an important milestone for the Ringside Social App Server. In our Beta2 drop (available via SourceForge), we have introduced preliminary support for Facebook JavaScript (FBJS). FBJS enables Facebook (and now Ringside) applications to use Web 2.0 functionality like Ajax and DHTML to provide better user experiences. As far as I know, we are the first and only implementation of FBJS outside of Facebook! Here are the key pieces of the implementation we released today:

• Many of the DOM extensions (APIs to get and set properties for DHTML)
• The Ajax object (primarily to support getting new FBML from the back-end application)
• The DOM extension setInnerFBML, allowing applications to generate FBML as the Ajax response and to dynamically update the UI with that FBML

We expect this implementation to mature between now and our next beta release, which should come out in about 2 weeks. But what we have today is enough to run the Voomaxer Facebook application on the Moorestown Running Co. site. If you try it out and find something lacking, let me know, or consider contributing the our open source social platform.

The Other Data Portability

There is a lot of discussion these days about data portability, and it’s an important topic. Most of the blogosphere is abuzz around the idea of moving personal profile information and contact lists (your “friends”) out of one network and into another. People have mentioned that this kind of portability is key to reduce friction in the social networking arena. While I do agree that this is a good goal, the analogy to cellular number portability is not entirely accurate. I still haven’t found a mobile service provider that will help me transfer my numbers from a phone locked to one service into a phone locked to another service. To do this, I use some external tool (one advantage of being a Mac user is that I get this tool for “free” [okay, at no additional cost] from Apple). I’m sure people will use an external tool to move their social graph around, too, but the large-scale social networks currently restrict anyone from doing this.

Now that I’ve defined what I am not talking about, I’ll move on to what I am talking about. The kind of data portability that I see being important is the ability to take social application data and move it around from social network to social network. Some stand-alone social application (Flickr, YouTube, etc.) already support this in some way, allowing feeds to be displayed on social networks. But what about a truly social application, built on the social infrastructure that the social networks provide as part of their platforms? This kind of data portability is currently hard to come by, but providing it has some serious advantages to application developers. The biggest benefit is reach, which enables applications to stretch beyond the original social network that they were developed for. Applications that include data portability in their core architecture are able to use extended social networks such as friends that cross networks. This extension enables additional viral connections that applications that connect only to one network can’t enjoy.

I see data portability as something that empowers users to use their social connections in the way they see fit. Users should be the masters of their friends list, and there are two separate (but related) ways to accomplish this. One involves being able to move these lists between networks, but the other very useful way is for applications to support the entire social network of a person, spanning across general-purpose and special-purpose networks that people use for various reasons. All this will help support people taking control of their networks, engaging people in the whole network for purposes that will certainly spread beyond simple social interactions like “poking” into whole new realms of applications.

At Ringside Networks, we’re working with a Facebook application developer to put the final polish on a real application that will be deployed on Facebook, on the application’s own web site, and on a third-party site that has an interest in running the application. It will be great once that is in place as a sort of test bed for these ideas. I’ll comment or update this post once it is available.

Social Media: Rent or Own?

Social media sites like Facebook, MySpace, Bebo, hi5, and Orkut have a specific value proposition for those who interact with them. In the recent Avenue A Razorfish 2008 Digital Outlook Report these sites (along with their smaller social application cousins, like Flickr, del.icio.us, Digg, etc.) are identified as key entry points into existing web properties. The report observes specifically that “many top Web properties see 50% to 75% or more of their traffic originate somewhere other than the home page”. With so many hits originating from outside the main web site, it begs the question: Is social media the new home page?

No longer are web portals and directories the primary way that people discover content. Now there are rich communities of people documenting what they like and sharing it with friends, colleagues, and acquaintances. Many of these social sharing events take place in the context of a primary social media site. Engagement with users now takes place on a different playing field, and marketing managers and web site producers need evaluate how their web site engages with these social media behemoths. There is a lot of value in these networks to enable viral marketing and viral growth. But the model of the large social media sites is very similar to the broadcast television network model. For Facebook and its ilk, the value is in the ads and the content is there to draw eyeballs. To me, this is very clear in that there is no monetization model associated with producing successful applications, groups, or “pages” (profiles of non-users). Let me be clear, there is certainly a place for these properties on the web, and I certainly respect what these sites have put together. And for other web properties who need the reach provided by them, they are the clear place to go.

However, if your site’s interests conflict in any way with the goals of the major social media sites, you should consider how to go about engaging with these sites with some caution. Engaging with social media sites is like renting an apartment or a house. All improvements (i.e. additional traffic you generate, additional stickiness that your application or other innovation produces) belong to the owner, not to you. This doesn’t mean that the place doesn’t deserve a coat of paint, but are you really going to put on that addition?

There are ways to engage with these large sites so that your message doesn’t get lost in the shuffle. It requires some careful thought and planning, but it is possible to tap into the extraordinary opportunity provided by social media while maintaining (and growing) your own position in the marketplace. What are your thoughts, fears, opinions on engaging with these sites?