Since I can't think up a better name for this feature set + data set, I'll just refer to it as "SN" for Social Networking.

I'm describing this because I find it interesting to think about what happens when you a) factor it out of current social networking services to see what's really there to differentiate them, and b) project it onto other services where it does not currently exist to see what opportunities arise.

What I conclude is that there aren't any "Social Networking Services" per-se. There are however, Social Network-Aware or Social Network-Enabled services. I'll further wager that existing services will benefit more from the addition of SN capabilities ("SN-Enablement" ?) than bare-bones SN services will from tacking on non-SN features.

The Basic SN Profile: You have the user profile, a set of user-supplied fields attached to a userid. You also have the user edges, which imply some sort of real world relation between two individuals. Those are the two nouns involved here. For verbs, you have the basic CRUD functionality for profiles and edges attached to your userid. This is naturally subject to some sort of access control (for instance, not exceed some maximum degrees-of-separation between userid of requestor and userid of subject of request).

Roughly speaking, the user should be able to:

• Create a user account with a unique id
• Attach metadata to it (favorite movies (Friendster), previous jobs (LinkedIn), political interests (iCan))
• Specify a list of other accounts to which the user account is in some way related.
• Browse the various degrees of separation between accounts

A concrete example of this would be something like PeopleAggregator, but less ambitious. Maybe FOAF + WebDAV would make more sense.

Existing Services

What I haven't been able to find is a Sourceforge.net + SN example. One could easily scrape projects and participants off the sourceforge website, and that would give you the six degrees of your favorite ubercoder. (related note: Oh dear God no. This should not be.)

I'm excited about Evite 2.0 because I constantly see people trying to do this on Friendster using Fakester accounts. There was this fakester called "Austin Parties" but it was limited by the meager non-SN features that Friendster provides. It was a great way to find out roughly what's going on in town, but not a good way to do planning or more articulate notifications.

Some Things I Can't Do - Yet

Suppose that you're throwing a new year's party, and want to tell all of your friends on Friendster (I'm sure this is well-worn scenario but bear with me). It would be nice to have an "Evite my Friends" button so that I could do that. But no, I go post something in my bulletin board and maybe fire off a couple of messages, and ultimately resort to posting a bunch of email addresses into a new Evite form. Even with Evite 2.0, these two services probably won't be able (or even want) to talk to each other in this manner.

As an alternate example, imagine that you go to a party to which you have been Evited. You meet a bunch of really great people, but fail to get any names or other contact info because you were so hammered (hypothetically speaking, of course ;-). The one bit that you do remember is that they were friends of friends of so-and-so who threw the party. So you go back to the Evite page, and browse through the host's Friendster network via the guest list and find them.

The Indefensible Layer That They'll Fight Tooth and Nail to Protect

Anyone who uses a combination of services like this is going to get sick of creating a new account for each of them. You'll end up rebuilding your Social Network every time you want to do something new with it. I'd like to be able to just say "Hey Evite 2.0, import my Friendster network" but sadly I don't think that's going to be the case. I think the conclusion I'm coming to is that interoperability is going to drive growth in Social Networking-enabled services, and user-data hoarding is going to impede real innovation in this space the way it's impeded instant messaging for the past eight years.

So I think of it like this.

In one layer you have activity-oriented services, like dating, job hunting, and event planning (the answers to "What can I do with Socially Networked services?"). Separately, in a lower layer you have the Social Networking services like "link me to this person" and "fetch all the people linked to this person". This lower layer should be interoperable across the upper layer services. If we have to enter the same information over and over (which is more complicated than just your name and address because it requires separate steps for discovery and location of your friends), new upper-level services will see slow growth and resistance to participate from users.

Additionally, this lower layer shouldn't contain any rocket science or otherwise defensible intellectual property. It's just CRUD and a two-class object model. Activity-oriented (upper-layer) service providers can attach their own metadata to this SN-layer data by reference and store that stuff separately.

I hate it when otherwise intelligent people scramble to claim ownership of something that's totally obvious. I bet there's going to be a lot more of it going on while this social networking "boomlet" is in effect. Essentially, this stuff shouldn't be part of any startup's secret sauce. Services could and should share it because it will be better for them in the long run. When they inevitably begin to consolidate more aggressively, they'll benefit again from the shared SN layer.

There's an opportunity here to avoid the utterly retarded balkanization of user communities that Instant Messaging created in the late 90's. I'm trying to be uncharacteristically uncynical when I say that I bet it doesn't happen again.

Mainly because someone's going to resurrect the Hailstorm idea to try and do just this.