Collaborate!

The power of social networking is undeniable. Duh! Just bop on over to Alexa's traffic rankings and what do you find? MySpace is #5 on their global top 500 list, outranked by only search engine services. What does this tell you? Social networking has distinguished itself as the #2 most important function of the Internet behind search. Regardless of whether you think MySpace is a cesspool of stupidity or an exemplification of the worst attributes of mankind, it won't change the fact that it's insanely popular and its ramifications must be considered.

People want a people directory with semantic relationships. But more than that, people want services which integrate with the people directory. The #1 problem solved by MySpace is the identity issue. Identity on the Internet was never anything people took the time to establish prior to the advent of social networking sites, because so little time was invested inside the microcosms where identity could be established. MySpace took the concept of identity and ran with it, allowing individuals to create elaborate and highly customized descriptions of their personal identity. However, all that information remains locked inside of MySpace. All that elaborate personal detail is only usable within MySpace's walled garden.

The Friend of a Friend (FOAF) vocabulary was created as an open means of describing identity on the Internet, expressed in XML format which allows FOAF authorship info to be added to any XML datastream, namely HTML documents and RSS feeds. FOAF represents what many see as the first potential killer app of the Semantic Web, a metadata-driven retooling of the way information is represented on the Internet. It's a move away from documents designed for direct human consumption and towards documents designed to be processed primarily by computer programs. FOAFnet is a subset of FOAF designed for allowing social networks to exchange personal profiles, so that a profile you develop on one service can easily be imported into any other FOAF-enabled social networking service.

However, beyond that, FOAF-enabled applications remain walled gardens. Social networking functionality such as identifying friends and acquaintances, sending private messages, and communicating with groups is still locked into a particular service. This has given MySpace the edge it needs to dominate the social networking space: it has the largest community, and thus is the most compelling service to use.

The only way to compete with MySpace at this point is to build a larger social network. But if the most compelling reason to use a social networking service is to interact with the existing community, how can you possibly expect to out-compete the service with the largest community. Enter the long tail: the combined userbase of all other social networking services exceeds the userbase of MySpace.

What's needed is for a large number of services which offer social networking services to not only standardize on FOAF for exchanging user profile information, but to develop a common API for allowing distributed social networking functionality between all social networking systems, so that users can seamlessly add friends, send private messages, and communicate with groups across multiple social networking systems.

There are many projects which are similar to this but vary slightly in scope. The OpenID project aims to develop a distributed single sign-on system. SXIP is another service offering single sign-on and centralized identity management. However neither of these projects implement the goals I have outlined, namely: a decentralized, distributed system for defining online identity and programmatically interacting with the identities of others.

In order to attain this goal, I would like to propose a simple extension to the FOAF specification. (the rest of this is going to assume you have basic familiarity with FOAF) Since I'm feeling enormously drained of creativity for some reason, I'm just going to give my proposed extension to FOAF the vanilla generic name of <i>foaf:api</i>. What would a foaf:api tag look like? Something like this:

<foaf:api dc:title="My Amazing Service" rdf:resource="http://myamazingservice.com/api&quot; />

Here we have the optional dc:title attribute identifying the name of the social networking service. We also have an RDF resource attribute. This is pointing at the URL of an API (I'm going to go ahead and suggest REST for this) which gives us tools for collaborative FOAF authoring and some basic social networking features. I'm going to go ahead and give some descriptions of two use cases for this API: friends and private messages.

Friends!

When you use FOAF, you become your URL. Most of the major players using FOAF so far, namely LiveJournal and Tribe, have tacked FOAF support on as an afterthought. But here's a suggestion for those implementing new social networking sites: use XSLT to style FOAF documents in order to generate user profiles. When you do that, there's no disconnect between the URL people present their friends they want to show their profile and the FOAF document describing that person. Failing that, you can place <link> tags in the <head> of the HTML user profiles which point to their FOAF profile.

All that said, I'm going to describe how the <foaf:api> tag could be used to allow friends to be seamlessly shared between social networking services. Bob and Alice suck, so I'm going to call my peeps Julio and and Francois.

Okay, so Julio is surfing around on My Amazing Service (despite being a user of My Evil Competitor's Service) and discovers his long lost friend Francois. "OMG it's Francois!" Julio exclaims. Fortunately for Julio, me and my evil competitor both provide services which support <foaf:api>. So hey, maybe my evil competitor isn't that evil after all.
Julio logs into My Evil Competitor's Service, clicks the handy dandy add a friend button, and is propted for the URL of the profile he wants to try to add as a friend. He pastes in the URL to Francois's profile. My Evil Competitor's Service then grabs Francois's FOAF profile, processes it, and pulls out the details for the foaf:api tag. Huzzah, Francois's service supports foaf:api (because I created it, bitch!), so we can go ahead and establish a mutual trust relationship between the two profiles.

How does this work? It goes a little something like this: My Evil Competitor's Service connects to my service's FOAF API. It sends an add-a-friend request, which contains two parameters: Francois's mbox_sha1sum, so I can look him up on my system, and the URL to Julio's profile on My Evil Competitor's Service. My service downloads Julio's profile and presents it to Francois the next time he logs in. "Holy schnikes!" exclaims Francois, "It's my long lost friend Julio." Overjoyed, Francois clicks add on my service. My service then connects to the rdf:resource in Julio's foaf:api tag, and informs them that the trust relationship has been established (or, if Francois decides to screw that jerkass Julio, it would send a rejection.) At this point a mutual trust relationship between Julio and Francois has been established. Both of their FOAF documents are then updated with new foaf:Person listings in their foaf:knows block to reflect the mutual trust relationship.

And that's it. Now you aren't tied into using whatever service (i.e. walled garden) your friends are using. Hell, you're free to develop your own social networking software, if you've got a really bad case of the NIH. The entire system is completely decentralized way of providing the same people directory features that MySpace and other social networking sites offer.

Of course, what good is a people directory without some additional features? I'm going to go ahead and describe how I would implement private messaging, but hopefully the description of the approach will give you some ideas of how other services like groups could also be implemented.

Private Messages!

The really crazy thing about this is: what I'm going to describe here is basically going to be a Semantic Web-enabled replacement for e-mail. And obviously, being perhaps the oldest feature of the Internet, e-mail is something other people have thought a lot about. A lot about. We don't want to reinvent the wheel here, or do we?

Well, there's a guy who knows more about e-mail than almost anyone on this planet. Some people love him, some people hate him, but regardless you pretty much have to admit that he's a brilliant programmer and an all around sharp guy. I'm talking about Dan J. Bernstein, a.k.a. djb. Having developing the wildly successful and highly secure qmail software, he decided that e-mail, or more specifically the SMTP protocol which delivers mail across the Internet, needs to be thrown away and reinvented from scratch. He wrote up a paper on the basic concept of how he thought mail should flow around the Internet, and idea he called IM2000.

This is great as an academic exercise. The problem is: SMTP is ingrained into the structure of the Internet. Why would anyone bother using an alternative, especially one which offers no value to the end user over traditional SMTP-based mail. Various people tried fleshing out and implementing djb's ideas, but no project based on IM2000 ever saw widespread use, for the reasons I just outlined.

In private messaging for social networking services, I think we really have an opportunity to redesign e-mail so it doesn't suck. I'm guessing djb is really going to hate the approach I'm suggesting because it will involve the bloated, standard faire of the new web: HTTP-powered web APIs that communicate with XML documents. Thinking of replacing e-mail with that makes me cringe a little, but then I just remember how awful SMTP is and feel a little better.

Okay, end of schpiel, here's the nitty gritty:

Julio, having just been notified that Francois accepted him as a friend, wants to contact his dear ol' buddy. He uses the crappy private messaging page my competitor authors to write a message to Francois. He clicks send, and then the real magic begins.

Here's where the first concept from IM2000 comes in: "The message isn't copied to the receiver's ISP. All the receiver needs is a brief notification that a message is available." Where does this become really useful? Bulletins. Say Julio wants to send the same message to Francois, Maria, and Fritz. All he needs to do is connect to their respective services and tell them the same URI for the same message. Contrast this to traditional e-mail where mailing lists send out duplicate copies of the same message over and over, regardless of who actually wants to read them.

My competitor still knows Francois's foaf:api address (i.e. the one on my service). So it connects to my FOAF api and issues a private message command, with four parameters: Francois's mbox_sha1sum, the URL to Julio's profile (in case we don't already have Julio's profile cached on our system), the URI where the message can be retrieved, and the message subject. The message URI should contain all access control information necessary to retrieve the message successfully encoded into the address itself (for example, Francois's mbox_sha1sum and a message ID as part of the URI path). This way, it would be possible for Francois to use client software to connect to some other API I offer and retrieve a message list from My Amazing Service, then fetch the messages directly, so that My Amazing Service would never have to connect to Julio's in order to forward the message. Since this URI provides access control, there's privacy/security at stake when the message URIs are transferred between servers. Thus SSL may be in order to protect message confidentiality. But e-mail doesn't do this right now anyway and few have seemed to care…

Anyway, let's ignore the rest of the potential applications for now and go back to the use case of two communicating web-based services. Francois logs into My Amazing Service, pulls up his listing of private messages, and sees the message from Julio. He decides that it isn't spam and he wants to read it, so he opens it. My Amazing Service now connects to Julio's service, retrieves the message from the URI we were given, and displays it. This way, spam is reduced to (REST-driven) message notifications only. Furthermore, services or users may elect to disallow messages from those who haven't been added as friends, which provides a further mechanism for preventing spam.

Spammers, if they wish for anything more than the message subject to be delivered, must now keep a service active where messages can be retrieved. No bandwidth is wasted on the bodies of undesired messages: you get to see the person who sent the message (and all the details they publish in their FOAF profile), and the subject of the message, and you decide from that if you actually want to retrieve the message body. Furthermore, services can still elect to automatically retrieve the message body when they receive a delivery notification if they want messaage to open. quickly.

Obviously the biggest detail being omitted here is the format of the private messages. I'm going to go ahead and suggest an XML document with RDF authorship info in FOAF format. But really, that's more detail than I want to go into in what's supposed to be a conceptual overview in a blog entry.

Something else we can offer through this appraoch is read notifications. My service can connect back to Julio's foaf:api and send his mbox_sha1sum, and the URI to the message that he sent Francois (provided it's unique to Francois, otherwise we'd need to send Francois's mbox_sha1sum or the URI to his FOAF profile) to inform him that Francois has indeed viewed his message.

The End!

So there you have it: a way to implement the two of the most used functions of social networking in a completely distributed manner, using only a handful of commands issued to a web API.

Everyone trying to compete with MySpace: this is the ticket. MySpace is going to keep pushing out, leveraging its enormous userbase to try to marginalize everyone offering a community for exchanging blogs, audio, and video. If there's one hope for beating out the advantages of the massive MySpace community, it's going to be building a distributed, collaborative social network that spans multiple sites.

Bottom line: it's time for social networking to break out of the walled garden. Let's collaborate, folks.

del.icio.us | digg it | reddit