nPost Blog

Web services should be both federated and extensible

One of the most important developments of the web 2.0 era is the proliferation of full featured, bidirectional APIs.  APIs provide a way to “federate” web services from a single website to a distributed network of 3rd party sites. Another important web 2.0 development is the proliferation of web Apps (e.g. Facebook Apps). Apps provide a way to make websites “extensible.”

The next step in this evolution is to create web services that are both federated (APIs) and extensible (Apps).

In my ideal world, the social graph would not be controlled by a private company. That said, Facebook, to its credit, has aggressively promoted a fairly open API through Facebook Connect. Facebook has also been a leader in promoting Apps. For Facebook, creating extensible, federated services would mean providing a framework for Facebook Connect Apps – apps that extend Facebook functionality but reside on websites.

Consider the following scenario.  Imagine that in the future a geolocation data/algorithm provider like SimpleGeo takes Facebook Places check-in data and, using algorithms and non-Facebook data, produces new data sets, for example: map directions, venue recommendations, and location-based coupons. The combination of Facebook’s data (social graph and check-ins) and SimpleGeo data/algorithms would create much more advanced feature possibilities than either service acting alone.

With today’s APIs, if, say, Gowalla wanted to integrate Facebook plus SimpleGeo into their app*, they would basically have 3 choices:

1) Embed Facebook widgets in Gowalla.  These are simple iframes (effectively separate little websites) that don’t interact with SimpleGeo.  Gowalla would just have to sit and wait and hope that Facebook decided to bake in SimpleGeo-like functionality.

2) Pre-import SimpleGeo data. This significantly limits the size and dynamism of the SimpleGeo data sets and doesn’t incorporate SimpleGeo algorithms, thus severely limiting functionality.

3) Host an instance of SimpleGeo’s servers internally.  This requires heavy technical integration, undermining the main benefit of APIs.

In a world of extensible APIs (or “API Apps”), Gowalla could instead send Facebook data back to SimpleGeo.  The data flow would look something like this:

(Note how there are three parties involved – @peretti calls this a “data threesome”). This configuration is much simpler to integrate – and potentially much more powerful and dynamic – than the other configurations listed above.  You could implement this today, but it would create user experience challenges.  For example, Gowalla would be sending Facebook data to a 3rd party (step 3), which might (depending on the data sent) require explicit user opt-in. Things become more onerous if SimpleGeo wanted to share its own user data with Gowalla. That would require an additional oAuth to SimpleGeo (authorizing step 4).

Allowing websites to be federated and extensible will open up a whole new wave of innovation.  Ideally some spec like oAuth could include the multiple authorizations in a single authorization screen.  Facebook could also do this by allowing 3rd parties to be part of the Facebook Connect authorization process.  Inasmuch as Facebook’s seems to be trying to embed their social graph as deeply as possible into the core experiences of other websites, allowing extensible APIs would seem to be a smart move.

* I have no connection to any of these companies (Facebook, Gowalla, SimpleGeo) and have no knowledge of their product plans beyond their public websites.  I am imagining functionality that Gowalla and SimpleGeo might include someday but for all I know they have no interest in these features – I just picked them somewhat arbitrarily as examples.


It has become customary to use “graph” to refer to the underlying data structures at social networks like Facebook. (Computer scientists call the study of graphs “network theory,” but on the web the word “network” is used to refer to the websites themselves).

A graph consists of a set of nodes connected by edges. The original internet graph is the web itself, where webpages are nodes and links are edges. In social graphs, the nodes are people and the edges friendship. Edges are what mathematicians call relations. Two important properties that relations can either have or not have are symmetry (if A ~ B then B ~ A) and transitivity (if A ~ B and B ~ C then A ~ C).

Facebook’s social graph is symmetric (if I am friends with you then you are friends with me) but not transitive (I can be friends with you without being friends with your friend).  You could say friendship is probabilistically transitive in the sense that I am more likely to like someone who is a friend’s friend then I am a user chosen at random. This is basis of Facebook’s friend recommendations.

Twitter’s graph is probably best thought of as an interest graph. One of Twitter’s central innovations was to discard symmetry: you can follow someone without them following you. This allowed Twitter to evolve into an extremely useful publishing platform, replacing RSS for many people. The Twitter graph isn’t transitive but one of its most powerful uses is retweeting, which gives the Twitter graph what might be called curated transitivity.

Graphs can be implicitly or explicitly created by users. Facebook and Twitter’s graphs were explicitly created by users (although Twitter’s Suggested User List made much of the graph de facto implicit). Google Buzz attempted to create a social graph implicitly from users’ emailing patterns, which didn’t seem to work very well.

Over the next few years we’ll see the rising importance of other types of graphs. Some examples:

Taste: At Hunch we’ve created what we call the taste graph. We created this implicitly from questions answered by users and other data sources. Our thesis is that for many activities – for example deciding what movie to see or blouse to buy – it’s more useful to have the neighbors on your graph be people with similar tastes versus people who are your friends.

Financial Trust: Social payment startups like Square and Venmo are creating financial graphs – the nodes are people and institutions and the relations are financial trust. These graphs are useful for preventing fraud, streamlining transactions, and lowering the barrier to accepting non-cash payments.

Endorsement: An endorsement graph is one in which people endorse institutions, products, services or other people for a particular skill or activity. LinkedIn created a successful professional graph and a less successful endorsement graph. Facebook seems to be trying to layer an endorsement graph on its social graph with its Like feature. A general endorsement graph could be useful for purchasing decisions and hence highly monetizable.

Local: Location-based startups like Foursquare let users create social graphs (which might evolve into better social graphs than what Facebook has since users seem to be more selective friending people in local apps). But probably more interesting are the people and venue graphs created by the check-in patterns. These local graphs could be useful for, among other things, recommendations, coupons, and advertising.

Besides creating graphs, Facebook and Twitter (via Facebook Connect and OAuth) created identity systems that are extremely useful for the creation of 3rd party graphs. I expect we’ll look back on the next few years as the golden age of graph innovation.

Steve Jobs single-handedly restructured the mobile industry

With the introduction of the iPhone, Steve Jobs achieved something that might be unique in the history of business: he single-handedly upended the power structure of a major industry.  In the US, before the iPhone, the carriers (Verizon, AT&T, Sprint, T-Mobile) had an ironclad grip on the rest of the value chain – particularly, handset makers and app makers.

Ask anyone who ran or invested in a mobile app startup pre-iPhone (I invested in one myself). Since the carriers had all the power, getting any distribution (which usually meant getting on the handset “deck”) meant doing a business development deal with the carriers. Business development in this case meant finding the right people at those companies, sending them iPods, taking them to baseball games, and basically figuring out ways to convince them to work with you instead of the 5,000 other people sending them iPods and baseball tickets.  The basis of competition was salesmanship and capital, not innovation or quality.

The carriers had so much power because consumers made their purchasing decisions by choosing a carrier first and a handset second. Post-iPhone, tens of millions of people started choosing handsets over carriers. People like me suffer through AT&T’s poor service and aggressive pricing because I love the iPhone so much.

I’ve talked to a number of mobile app startups lately who say their former contacts at the carriers are shell shocked: no one is knocking on their doors anymore. I guess they have to buy their own iPods and baseball tickets now.

Yes, Apple has rejected some apps for seemingly arbtrary or selfish reasons and imposed aggressive controls on developers. But the iPhone also paved the way for Android and a new wave of handset development. The people griping about Apple’s “closed system” are generally people who are new to the industry and didn’t realize how bad it was before.

While Google fights on the edges, Amazon is attacking their core

Google is fighting battles on almost every front:  social networking, mobile operating systems, web browsers, office apps, and so on.  Much of this makes sense, inasmuch as it is strategic for them to dominate or commoditize each layer that stands between human beings and online ads.  But while they are doing this, they are leaving their core business vulnerable, particularly to Amazon.

When legendary VC John Doerr quit Amazon’s board a few months ago, savvy industry observers like TechCrunch speculated that Google might begin directly competing with Amazon:

[Google] competes with Amazon in a number of areas, particularly web services and big data. And down the road, Google may compete directly in other ways as well. Froogle was a flop, but don’t think Google doesn’t want a bigger chunk of ecommerce revenue from people who begin their product searches on their search engine.*

In fact, Google and Amazon’s are already direct competitors in their core businesses. Like Amazon, Google makes the vast majority of its revenue from users who are looking to make an online purchase. Other query types – searches related to news, blog posts, funny videos, etc. – are mostly a loss leaders for Google.

The key risk for Google is that they are heavily dependent on online purchasing being a two-stage process:  the user does a search on Google, and then clicks on an ad to buy something on another site. As long as the e-commerce world is sufficiently fragmented, users will prefer an intermediary like Google to help them find the right product or merchant. But as Amazon increasingly dominates the e-commerce market, this fragmentation could go away along with users’ need for an intermediary.**

Moreover, Google’s algorithmic results for product searches are generally poor. (Try using Google to decide what dishwasher to buy). These poor results might actually lead to short term revenue increases since the sponsored links are superior to the unsponsored ones.  But long term if Google continues producing poor product search results and Amazon continues consolidating the e-commerce market, Google’s core business is at serious risk.

* Froogle (and Google Products) have been unsuccessful most likely because Google has had no incentive to make them better: they make plenty of money on these queries already on a CPC basis, and would likely make less if they moved to a CPA model.

** Most Amazon Prime customers probably already do skip Google and go directly to Amazon.  I know I do.