thoughts to blog

Sam threw up a post about crosstalk in social networking websites... inspiring me to think about the problems that he raises.

Everyone in the social web posts content to several services; sometimes cross posting the same content... and a lot of these sites will also allow replies and comments. The problem is that it's all in separate places, leaving you to figure out how to collect the information and make it relevant. Sam discusses a few possible solutions, but all driving back to a concept of a monolithic "sink" of social data... a walled garden.

There are several sites out there that are trying to solve this problem... FriendFeed, SocialThing!, and even a federated micro-blogging service identi.ca... They allow you to enter in your profile information (sometimes including your heavily guarded password) and they will use an API to get the data and aggregate it. This type of system works out, but can have problems:

• You have to divulge profile information, including passwords, to these 3rd party websites.
• Those sites are at the mercy of the API of the target site... including downtown and rate limits.
• These sites are not heuristically figuring out how to munge all of the data into meaningful conversations (comments and replies)

So why not turn the idea around and think about social endpoints...

A social endpoint is a personal spot where your content magically arrives when it happens. Think of a reverse OpenID mixed with e-mail... Where if you create social content online, it gets forwarded to your own social endpoint for you to parse, store, display, etc. You could also potentially push other people's content down to your social endpoint as well.. it's just a message.

How does this solve the problem? It keeps the data input at the respective sites, thus allows those sites to function properly and keep their business models in tact. It then helps bring the conversations back to you in a relevant fashion. With optionally having other people's social data coming down your way, you can also get involved in other conversations.

Here's a small flow to show you what goes down...

1. Jake creates a social endpoint on his own webserver
2. Jake signs up for Twitter and Brightkite
3. Jake tells Twitter and Brightkite that his social endpoint is: http://socialendpoint.com/jake
4. Jake pushes a message to Twitter and Brightkite (could even be the same message)
5. Twitter and Brightkite send a social endpoint message (well known) to Jake's social endpoint.
6. The social endpoint takes in the data and stores it, uses it's muscle to figure out that it's the same message...
7. Someone replies on Twitter... Twitter sends a social endpoint message to Jake's social endpoint.
8. Someone does the same for Brightkite.
9. Jake's social endpoint takes those comments and associates them to Jake's original message.
10. Now Jake can read comments back aond forth...

The concept is pretty simple, create a simplistic spec for data and message passing for social data... and define an endpoint spec on how those messages should arrive. Create a base implementation in any language that you so choose... and store the data as it comes in. The real meat of it is the specs for the data, messages, and endpoints... but that's the whole concept right?

The Pros:

• The endpoint is your own, hosted wherever you want. It benefits from an OpenID style system... and can create a market of hosted services with competition to see who can do cooler things with your data. Hell... host your own!
• The messages and data are well known, so any service can push content back to your server...
• Implementations can be customized and/or rewritten however you want. If you want better heuristics to figure out what conversations are connected and how to display them, write it yourself or find a better implementation...
• Since it's pushing the content, you could easily daisy chain endpoints (in which they turn into nodes, like the internet). Imagine being able to subscribe to other people's endpoints and creating a massive conversation.

The Cons:

• The biggest problem faced is that sites have to implement the protocol... which is a huge problem to get it to work...
• This still has a fundamental flaw of being at the mercy of the endpoint being up... but it's the users fault, not the services
• This has the problem of trying to figure out conversations, but can be easier if the message spec is well thought out.

At any rate... I snagged socialendpoint.com to do a possible POC and see if it can catch on. I'm going to run this by a few other people but I would like some input from the blogosphere... Am I crazy??