A while back, I posed a question to the Diso mailing list wondering if there was any work being done to enable cross-domain "friend requests" in the context of social networks and other systems that have the notion of "friend lists".
There was some interesting discussion surrounding this topic, and I've been meaning to solidify my thoughts around this whole idea. Given that I love to utilize the xml2rfc tool, I decided to just codify my thoughts into a formal specification. However, I quickly realized that I was creating a lot of new terminology, so this blog post is my attempt to provide some background explanation about the "what" and "how" of cross-domain friend requests, as well as to illuminate my new proposed specification, OInvite.
So here goes...
A "Friend Request"?
First, you might be wondering, "What exactly is a 'friend request', anyway." Well, for my purposes I will use the following definition:
Friend Request: A request from an invitor (the sender of the request) to an invitee (the recipient of the request) to enter into a "communications relationship."
OK, there's some more new terminology.
First, the notion of a "communications relationship" is purposefully left quite vague. Perhaps two users (let's call them "John" & "Beth") simply want to email each other. That's certainly an obvious form of communication. However, communications relationships are much bigger than this. Imagine if John wants to allow Beth to see his photographs on Flickr...that's communication, too, and it generally involves some acceptance of this communication.
Thus, a "communications relationship" is the term I invented to describe an agreement between two parties to send and receive information.
In tandem, an "OInvite" is a request to enter into such a relationship.
In Facebook terms, this type of thing is generally referred to as a "friend request"; in twitter terms, a "follow me" request; in OAuth terms, it's "I want to share data with you" request, etc.
One-to-One? Uni-Directional? Bi-Directional?
As we travel down the rabbit-hole of "communications relationships", we quickly encounter the notion of directionality. For example, what if John only wants to share (read: send) information with Beth, but doesn't really care to receive information from Beth? Such a relationship would be considered "unidirectional", because information only flows one way. However, if John wants to both send and receive information to/from Beth, then a bi-directional communications relationship would be required.
In addition to directionality, "friend requests" might be sent to a single individual, or they might be sent to a group of invitees (a.k.a: recipients). This is the notion of Invitation cardinality, and quickly adds to the complexity of a communications relationship. For example, should an invitation be "one-to-one" (an invitation from one user to a different user); one-to-many (an invitation from one user to multiple users); or many-to-many (I'm not even sure if this is possible).
Closed vs. Open Communications Relationships
Going even deeper, there's one last area of communications relationships that should be considered/defined, and that is the notion of an "open" vs. "closed" communications relationship.
On today's Web, we are commonly exposed to "closed" communications relationships. Facebook users can invite other Facebook users to become "friends", thereby allowing communications of various types (messages, photos, activity-streams, etc). Twitter users can only "follow" other Twitter users; MySpace users are limited to communicating with other MySpace users, and so on. These are all considered to be "closed" relationships because a Facebook user (for example) cannot easily "becomes friends" with a user from Twitter, without that Twitter user first having a Facebook account with which to interface to Twitter with.
Conversely, the notion of an "open" communications relationship would allow Facebook users to "friend" users on any other social-network (assuming the two networks could speak the same protocol). For example, John (on Facebook) might invite Beth (on Orkut) to "share information".
We don't see this type of thing today for a myriad of reasons. For one, most social networking sites are closed ecosystems, so they have never bothered to support a "hook" into other social networks (this is beginning to change, e.g., Facebook Apps).
However, even as social networking websites "open up" their content (and access to that content), they still require an account on the "home" social network. In the example above, Beth (on Orkut) would need an account on Orkut as well as on Facebook to have John's Facebook data show up in Orkut.
These "silos" exist for a number of reasons (competitive, economic, technological, etc), but at the core they exist because there is no protocol that will allow Facebook (for example) to control the number of invitations coming from an infinite number of other social networks. In essence, even if the Internet community could overcome the all the hurdles standing in the way of "open" social networking, there would still be the great white elephant in the room: SPAM.
Now, I'm not talking about the kind of spam everyone is familiar with in the email world. Instead, I'm talking about Invitation Spam.
Social Networks don't allow communication between users until each user has given some sort of "approval" to be communicated with (e.g., acceptance of a "friend request"). When a social network provider controls both ends of this interaction, that provider can easily throttle invitations, remove "bad" accounts, and more; thus controlling and eliminating SPAM of any kind.
However, in a truly open world, the ability to control the "bad guys" goes away, demanding some other mechanism that will both 1.) allow a nearly infinite number of cross-domain social networks to interact with users on the local social network (i.e., a completely open Facebook) and 2.) prevent unwanted invitation SPAM from ruining the entire user experience for legitimate users.
Email: Truly (Bad) Open Communications Relationships
O.K., so there's a lot to digest there...but we're not quite done yet. One last thing to consider before delving into the innards of OInvite is the current SMTP-based email system.
SMTP provides for cross-domain information sharing, or "open" communications relationships. In fact, the current email system is perhaps the most successful (and unsuccessful) "open" communications mechanism ever created in the history of the world. For example, messages from an email address in one domain can be freely sent and received to/from email addresses in another domain. As we all know, this is a blessing and a curse, enabling unfettered communication on the one hand, while at the same time enabling mass amounts of SPAM on the other.
Email: Communications Nirvana 0.1
Despite its shortcomings, email is pretty amazing. It has enabled an incredible amount of asynchronous communications, productivity (perhaps that's debatable), and more. However, if there is such a thing as "Communications Nirvana", then email is version 0.1 because it has, despite its open-ness, three significant shortcomings--all of which ultimately have to do with SPAM.
First, email lacks the ability to properly authenticate the sender of a message. I can send an email purporting to be from firstname.lastname@example.org, and it's somewhat difficult to verify whether or not "John" was the actual author of the message.
Editor's Note: The Internet is making progress in this area: SPF, DomainKeys, etc are all positive moves, but they're not universally required nor adopted, making SMTP fundamentally susceptible to this vulnerability.
Second, email puts all of the resource burden onto the recipient of a message, allowing senders to trivially send mass amounts of email at virtually no cost. Bandwidth, CPU resources, and intermediate data storage for email messages is borne by ISP's, and likewise each recipient, making it very inexpensive to send copious quantities of SPAM.
Third, email has no concept of a "friend list". Email was designed from the perspective that a particular user should receive all incoming messages. Today, this principle still holds, unless a message, sender, or domain is specifically blocked by a SPAM filter.
Social Networks: Communications Nirvana 0.5
So, if email is Communications Nirvana 0.1, then social networks are version 0.5. They solve issues #1, #2, and #3 above; but at the expense of open-ness (e.g., we can't send arbitrary messages to a Facebook account from a system in a different domain).
Yet, social networks are still pretty incredible. Virtually no spam; resource burdens borne by the network provider; and the concept of a friend-list that means I'm only receiving information that I elect to receive (for the most part -- I can't say that I really care about Facebook activity updates from 200 'friends', but again -- perhaps the topic of another post).
The Future: Communications Nirvana 1.0
Well, if you're still reading this, then congratulations--I'm now ready to make a point, which is this: If you buy the argument that social networks are an improvement over email, then the last remaining hurdle to getting to a 1.0 version of Communications Nirvana (in my opinion) is to "open" up social networks. This is was the Diso project is working towards, but it seems to me that as long as we sacrifice "open-ness", we'll never it make it to a 1.0 version of communication Nirvana, let alone a version 2.0, 3.0, or 10.0.
To become "open", we require a mechanism to enable cross-domain invitation requests which will allow us to enter into communications relationships with each other. In layman's terms, we need an open "Friend Request" mechanism that solves the problem of first-contact SPAM.
My answer is OInvite--an open protocol to enable cross-domain "friend requests" with a pluggable anti-spam mechanism--and since this blog post is so stinking long, I'm going to discuss the actual protocol in a different post, namely this one.
Why do we express incredulity when remembering the Internet of ~16 years ago, where for a long time people with an AOL email addresses could not send email to people with a CompuServe addresses? Today, we suffer this same abuse when it comes to the communications platform du-jour, namely, social networks.
Imagine 16 years from now when we tell our children how it "used to be":
Dad: "...in my day, you needed an account at every social network provider in order to be able to communicate with people there..."
Daughter: "Seriously? You're kidding, right?"
Dad: "Yep, if I wanted to talk to you on Facebook, I had to sign-up there. Then, if I wanted to follow you on Twitter, I had to sign up there..."
Daughter: "What's Facebook?"