Social Graph Theory - Home

A Design Pattern for Embedding OpenID Creation During Site Registration

2008-06-22T19:59:00Z

Chris Messina’s post on EmailToID got me thinking about other painless ways to get users to create OpenIDs for themselves.

One solution that popped into my mind, and as it’s quite obvious, may already be implemented, involves an OpenID provider who allows its OpenID creation process to be embedded into other sites (the relying parties in OpenID parlance). Ideally, the user experience would be completely ordinary, except that the pleasant gift of a new OpenID is presented at the end of the process. It would look something like this.

First, the user has the opportunity to enter in an email address. Like in the EmailToID.net implementation, the relying party can first try to autodiscover an OpenID based on the email address provided. If none is discovered, the relying party chooses to use the fictional AwesomeID.com provider which allows for embedded creation:

Lastly, the user is presented with his new OpenID and the opportunity to log in:

Thinking aloud, maybe the registration process can become standardized into the spec of OpenID, just like authentication is standardized now. This would allow for a more open solution than something like EmailToID.net, where that particular service must be accessible for the solution to work.

Graph Concepts: You Control Your Data

2008-06-21T21:22:00Z

When the history of the coming-of-age of the Internet is written, May and June of 2008 may be remembered as the time when the tides turned and the industry finally realized and accepted the importance of data portability: The idea that the user, not the service provider, should have full ownership and control over the content that user generates.

It has been far too long since I’ve blogged here at Social Graph Theory, as my blogging energies have been more in tune with my day job. But I’ve been keeping up with the emerging social and open web (what I refer to as the Graph), and I’ll use this post to first recap all the commotion of the past few months regarding data portability in all its forms and definitions, and then I’ll propose a way of thinking about how to solve these problems that’s really a throwback to a lost era. Of course, a primer on data portability is necessary before diving into the hoopla that surrounds it, so this essay by Marshall Kilpatrick serves as a good introduction.

The Scream

Robert Scoble screamed. He screamed at the top of his lungs during a conference call with some cranky geeks, and then promptly took a shower to settle his nerves.

Scoble was on the May 16 edition of the Gillmor Gang podcast, recorded at a time when within a week of each other, MySpace Data Availability, Google Friend Connect, and Facebook Connect all launched. All efforts described ways for data to move around in a less restricted manner in and out of their respective services. Dare Obasanjo had the best technical roundup of the three platforms.

There was a sense that none of these solutions were nearly enough, and the discussion on the Gillmor Gang reflected this sense. It seemed that the companies were merely serving themselves, and not really doing what was best for their users. To add fuel to the fire, Facebook had just suspended their participation in Google’s Friend Connect for seemingly petty reasons, a controversy which again bubbled up just a few days ago.

The Aftermath

During that epic Gillmor Gang recording, much virtual blood was spilled, and the participants retreated to their blogs to formulate more concrete thoughts. Robert Scoble, Marc Canter, and DataPortability.org founder Chris Saad all had plenty to say.

There seems to be two paths options for those who want to see data portability: (1) Rely on the existing big companies like Facebook, MySpace, and Google to do the right thing, or (2) Participate in a grassroots effort that pushes the corporations to play nicely via the adoption open, neutral solutions and standards. Option #2 seems most plausible, and so many eyes have been watching the Data Portability Workgroup for leadership in this space.

But DataPortability.org’s founder Chris Saad has been criticized for not achieving any concrete victories in the half year of the workgroup’s existence. OpenID leader Scott Kveton left the Data Portability Workgroup earlier this month, citing Saad’s poor leadership and lack of focus.

The one project that seems most likely for success, is actually already succeeding with working code, and that’s the DiSo Project led by Chris Messina. By building working implementations (plugins to Wordpress and MovableType) of open standards (OpenID, OAuth, Microformats, et. al.), the DiSo Project has an emphasis on building real solutions rather that just talking.

The Future

The DiSO Project understands that technological innovation has always rode on the back of standards. AC electricity at 120V brought electrical appliances to every household and helped create a strong middle class. 8 bits in a byte was essential to computing. TCP/IP, HTTP, and XML are the key foundations of the Web.

Standards have been essential to progress since the age of Edison (and he lost the standards war of his day, yet history still views him quite favorably). Then in the mid 90’s, the entirety of the Internet industry seemed to have collectively thought, “We don’t need anymore standards”. They proceeded to build services (some awesome, some not so much), and forgot about forging standards to provide some foundation for the innovation they were doing.

That emphasis of services over standards leads us to the frustrations we face today. Since 1997, there really hasn’t been a truly game-changing, market-building standard to come about. The closest thing I can think of is RSS, but regular folks still don’t use it.

The work DiSo is doing by leveraging OpenID, OAuth, Atom, XMPP, et. al. to create an infrastructure based on open standards really is quite revolutionary considering what the industry has been like since the 90’s. But it’s essential, and it offers the best chance to achieve the goal of data portability: Users who truly control their own data.

Graph Concepts: You Are Your URL

2008-04-27T20:00:00Z

As the next wave of communications technology evolves from the Net (network of computers) to the Web (web of documents) to the Graph (directed graph of people, places, and things), it’s important to keep in mind the big ideas that are driving the innovations. In this series of blog posts, I’ll go over four (and maybe more) concepts:

You Are Your URL
You Control Your Data
Collective Intelligence Wins Over Artificial Intelligence
Attention is a Scarce Commodity

Let’s begin with the first concept: that a URL is the best identifier for a person.

The OpenID Endpoint

The promise of OpenID is single sign-on to any supporting website. But what makes OpenID more special than any other previous single sign-on system is that it uses a URL (or if you want to be semantically correct, a URI) as the identifier. So, luigimontanez.com is my personal website as well as my OpenID. A URL is much more powerful as an identifier because it can act as a publicly accessible endpoint. An endpoint can contain things like links to that individuals other profiles around the Web, links to friends and contacts, marked-up HTML code that provides contact information, pointers to other services, and so much more.

Other Forms of Identification

As OpenID adoption grows, the notion of a URL acting as an identifier (instead of user name or email address) will become mainstream. When this happens, the URL will be the person. Today, if I say the name “Barack Obama”, you immediately know who I mean. A picture pops into your head of him, maybe his voice, maybe what has been recently said about him in the news. You associate the two words “Barack Obama” with the presidential candidate, even though it’s likely that there are at least a few more Barack Obama’s in the world. So the name, “Barack Obama”, is in fact not a unique identifier, even though it’s a pretty good one.

Conversely, if I were to show you this picture:

You would immediately think “Barack Obama”, and just as before, you may hear his voice in your mind or recent news items about him might be conjured up. The picture is a better identifier in the sense that it really, truly means I’m talking about that Barack Obama. It is, then, a unique identifier. But, and this is a big but, one has to know what Barack Obama looks like in order for the identifier to be useful. While most Americans and probably most Westerners know what Obama looks like, chances are many in the developing world have no idea. More importantly for the Graph, a website or service won’t be able to identify a person via photograph either (barring advanced face recognition technologies).

So we need an identifier that is truly unique yet in a form that all computers can recognize. An email address certainly fits the bill, and has been the standard identifier since the beginning of the Web. But, because of some very good privacy and spam concerns, personal email addresses aren’t generally made public. So while I use my email address to identify myself to Facebook, others in Facebook identify me via my name. Also, email addresses are uni-taskers when it comes to actual functionality. There’s only one thing you can do with an email address: send an email to it.

Arriving to the URL as the Solution

How about the URL as an identifier?

It’s unique. No one will have the same URL as you.
It’s universally accessible. Through the magic of DNS, any person or computer hooked up to the Internet can access the URL and its content.
It’s a multi-tasker. The page living at the URL can be configured to accept and output just about any kind of data.

Here’s a simple but powerful example. Let’s say that you and I are in the same city, and you’re wondering if I’m free for lunch today. You have a myriad of options:

Call me. But you’d have to know my highly arbitrary phone number.
Text me. See above.
Email me. Obviously, you’d need to know my email address.
IM me. You’d need to know my screen name and be on the same service I use.
Tweet me. Send me a direct message or an @ message via Twitter. We’d have to be following each other on Twitter for this to work.

But there are many points of failure here. If you call or text me and my cell phone is dead, you’re out of luck. If I’m out and about for the day and not online, the last three options don’t work. But what if you had a simple interface for sending me a message via my URL, easily discoverable via a quick Google search? Imagine a magic application window that lives on your computer or your cell phone where you could type:

@luigimontanez.com Want to meet for lunch?

On my end, my luigimontanez.com endpoint is set to receive messages and forward them to me as I see fit. Maybe I’m at my computer all day so I want to get messages via Jabber, or I’m a vain nerd and want them forwarded to my #luigirocks IRC chatroom on Freenode. Maybe the text-based message gets converted to a Stephen Hawking-like voice and I get a call from some VOIP service I’ve set up. Maybe I want messages from people I know to hit me in several ways, while messages from strangers are just dropped in my email inbox.

You don’t have to worry about how I get the message, you simply have to identify who I am (via my URL) and provide a message. Great, isn’t it?

That’s the power of what’s possible when You Are Your URL.

Two Mantras for the Graph: Don't be creepy. Don't be annoying.

2008-04-02T13:08:00Z

We all know Google’s mantra of “Don’t be evil”. It was a direct statement against all things Microsoft (referred to as the Evil Empire by many a pundit), and for the first few years of Google’s life, they pretty much followed it. But when it came time to get into the Chinese market, many saw Google’s cooperation with the totalitarian, human rights-violating Chinese government as going directly against the mantra. And so it goes. A mantra that had helped shine a light on the company as the underdog fighting against injustice has now covered that company in a blanket of hypocrisy.

Facebook is the undisputed market leader in the Social Graph. They may have less users and less traffic than MySpace, but they hold the mindshare of the industry and garner far more media attention. They’ve also shown an amazing propensity to fail spectacularly, many times over. And that’s a Good Thing. While they certainly don’t intend to fail, when they do, it acts as a teaching moment to their vast user base and developers looking to continue to build on the Graph. Two new mantras can inform the direction of where we’re headed:

Don’t Be Creepy

Large social networks, like Facebook and MySpace, will always have creepy users on them. That condition is just as unavoidable as the creeps residing on the Internet as a whole. But Don’t Be Creepy isn’t about the users. It’s about implementing the right features that maximize the display of useful information but don’t creep out.

Facebook started out as decidedly un-creepy, because each network was limited to a single college or university. It was exclusive, and it was the anti-thesis of MySpace, where those people who didn’t go to college hung out. It was friendly, warm, and inviting. Much like those first few weeks of freshman year.

When Facebook launched its News Feed, a complete backlash ensued. Everyone could see what everyone else was doing! Well, everyone could already see what everyone else was doing, but it wasn’t as easy as seeing a feed on one’s home page. Groups were formed with the title “Facebook has gotten creepy!” and hundreds of thousands of users joined them. Days later, Facebook scaled back the information being presented, and allowed users more fine-grained control of what about them was displayed, a system still being tweaked to this day.

Facebook flubbed even more with the Beacon program, a way that advertisers could track users’ spending habits online, and report purchases back to Facebook to be displayed in the News Feed, with the online shopper never informed of what exactly was happening. I find it hard to believe that Facebook didn’t realize that this would cause a backlash (and it did, spearheaded by advocacy groups like MoveOn.org). It seems to me that Facebook was willing to pay the cost of grief in order to move its user base (and thus the industry as a whole) to begin to accept such advertising tactics. But it was still creepy, and all it’s creepiness was promptly axed, allowing users to completely opt out of the system.

Don’t Be Annoying

This mantra addresses the problems of information overload and the cost of creating a new account and profile at every new social service. No one wants to be bombarded with notification emails. Some people get completely enraged when they get an automated email that they didn’t want (I’ve been on the other end of the line). Annoyance leads to a distrust of the offending system, and that’s not good for anyone. Setting notification preferences needs to be one of the first things a person does on a new social network. And it needs to be more than a binary, yes or no, option. Instead of a new email arriving with each new friend request, why isn’t a daily digest available of all notications?

Which bring us to the problem of there being so many new social networks. The cost of joining a social network is twenty minutes of time and effort spent setting things up. “But I already did this!” the user thinks, which is completely correct. This particular annoyance is already being addressed by the data portability movement, and establishing those standards is an essential piece of a truly functional Graph.

Conclusion

Don’t be creepy.

Don’t be annoying.

Two simple rules to live by, and we have Facebook to thank for demonstrating to the world how important those rules really are.

The Next Phase of Social Technology

2008-03-31T09:32:00Z

The times, they are a changin’. These last few years, the Web has become much more social. You know about Facebook, MySpace, Twitter, and all of that. Our recreational hours online are no longer considered to be aimless mouseclicking or “surfing the Web”. Instead, we’re interacting with others like we would around the water cooler. We’re sharing thoughts and updates. We’re making real-world connections and friendships. The Internet is neither seedy nor immature. It’s become a well-lit, friendly place.

This new phase has been called many things:

The final article in that list, on the Giant Global Graph, most clearly illustrates where we’ve been versus where we’re headed: From an Internet of computers, to a Web of documents, to a Graph of people and their relationships.

I’m placing my bets on “The Graph”, and will refer to this next phase as such moving forward. Why? I like the branding of it: You can get caught in the Net. You can get tangled in the Web. But you can only get orderly placed in the Graph. There’s a wonderful sense of order and direction behind the concept of the Graph, and the term comes closest to describing what cutting-edge social technology is now doing: modeling real-world relationships.

Despite which label actually “wins” the branding battle, there are certain values which are consistent to all of the above concepts:

New Standards Are Needed – Since the Dotcom Era of the late 90’s, there has been exactly one truly game-changing standard adopted: RSS. HTTP, HTML, Javascript, and XML were all widely adopted in the mid-90’s, yet those are still the building blocks of any new web application.
Open Web Services, Open APIs, Open Data – Users are rebelling against the data silos being created at every site they use. Data portability and distributed social networking are key concepts addressing this very problem.
More Signal, Less Noise – Too many of us are suffering from information overload. Email, IM, SMS, feeds. They hit us at a rapid-fire rate, and we desperately need help. New technologies for filtering out the bad and letting in the good would be a godsend.

Two more seminal pieces on the social graph from last fall were Brad Fitzpatrick’s Thoughts on the Social Graph and Alex Iskold’s Social Graph: Concepts and Issues. Both are essential reading to get yourself up-to-speed with the concepts and technologies that will be described in this space.