RoadSound

RoadSound is a content management system designed to help Music Industry concerns centralize their workflow and standardize online content. As a lifelong music snob, I've always loved going to shows and reading the backstory on how albums were made. Around 2000 a friend and I tried to make a website that could aggregate all the show and release info - but we increasingly noticed how incorrect or out-of-sync this information could be, even across 'official' sources.

As I got older, close friends increasingly wound up in major & indie label rock bands / labels / pr firms and I started to see how the industry's own workflow was the true culprit: managing a tour or a release schedule is a choreographed routine using the talent, labels, pr firms, booking agents, and venues ... but no one can dance. Looking at what was going on behind the scenes was a sobering experience: people were still faxing and mailing materials between offices, online updates were sent to interns and contractors, emails would be forwarded and redirected to more appropriate parties ad-nauseum. Everything was - and still is - chaotic, nothing about the 'official' workflow made sense.

Eventually the impact of blogs , social networks and social calendars hit the industry - and information on the net became even messier as people started promoting second hand information which was based on first-hand information that was never correct to begin with. Social Calendars would often have cancelled shows, blogs would post working or outdated copies of release schedules. Timeliness of information became less important than rhetorical questions like "Who do you trust?" and "Why?"

One day it just kind of hit me - I was staring at a problem that everyone (including myself) was trying to solve with aggregation , and we were all dead wrong. The solution wasn't aggregation, but the exact opposite... syndication. The music industry needed a way to centralize workflow, package it into standardized content, and push it out across the net to their colleagues and consumers. After way too many focus groups ( read: drinking heavily ) with people across the industry, RoadSound was born - a collaborative content management platform that streamlines workflow and gets the right info to fans.

After we built and tested the industry side to RoadSound in 2005 , I was left staring at the user problem - how do users interact with the user-oriented aspects of the system ( anti-scalper ticketing features trading and communal buying ; online content indexing ; etc ). The answer (to me) was simple – they shouldn't. For the system to be of best use to end-users, it really needed to be a clearinghouse with as much of the content and interaction pushed offsite as possible. Consumers should use any social network they please - requiring people to use our site didn't help the fans or the bands - portable content means portable advertising. So we focused on widgets and the concept of 'reputation': you might not trust my identity on RoadSound, but you're friends with me on Friendster and MySpace... so you'll trust buying a spare ticket off of me. To power that, we had this little sub-system called "Find Me On" that would manage the online network associations for our users. For the users, it meant building reputation through a little directory service ; for the industry it meant being able to derive a preliminary element of Social Mapping - the "Associative Overlap" of fans ( i.e., the uniqueness of their MySpace and Friendster fan bases).

RoadSound is currently on hiatus: built, patented, and sitting on a server somewhere. It was too far ahead of its time. When we pitched it to users and labels we always got a canned response "But what about MySpace? Don't they do that already?" This was at the height of the MySpace craze, and no matter what we said or did, we couldn't get the industry to get past its collective hubris and look down the horizon- social networks were exploding, and MySpace would face serious competition. U nfortunately, the industry is still slow to learn from its mistakes: people are making the same arguments now about Facebook that they did from MySpace, which was just a recycled Friendster argument, which was just a recycled AOL argument, which was just a...

RadioRequest

Around the same time as I worked on RoadSound , I was also working on a project called RadioRequest which had seemingly simpler goals: help people request airplay for songs they like online. Unfortunately, the concept of online music requests was at the crossroads of 3 generalized competing interests:

• Users wanted to use whatever social networks and emails they wanted
• Labels wanted to own the user data , and have them request non-stop
• Radio Stations wanted to own the user data too , and they don't trust anything that a record label funds

We ultimately decided on a widget approach for the users - making song request 'tools' that could be put on profiles, blogs, and even show up on email. To handle the labels and radio stations wanting to own the info, we decided that users would own the info and could opt-in to share it with the corporate interests ( and provided incentives for them to do so ). To handle the legitimacy of the requests for stations - and bring some value added to the labels - we did some preliminary 'share your social network info with the band' type stuff. Users were incentivized to share their MySpace and Friendster accounts: the station managers were ok with that as further proof of being a real person, the labels wanted to use that information to better plan online promotions and partnerships with the social networks. Though far simpler than the RoadSound implementation, the account tabs of RadioRequest used a little catchphrase called "Find Me On..." to head the social network account entry pages.

Intro

Whenever I'd focus group or pitch RoadSound or RadioRequest, one common section really resonated with our userbase and evaluators- FindMeOn. People increasingly liked portability of content and the simple listing of their accounts. The response was so good that it became clear FindMeOn needed to be split out - and at that time there were no online identity systems - so we spent a few months not just splitting the system out , but rebuilding it from the ground up as a very secure way of handling online identities. From the RoadSound model, we mandated public identity verification - but that wasn't enough: the Developer in me said "This needs to be as open source as possible," the Paranoid in me said "This needs to afford as much online privacy as possible", and the businessperson in me said "We need to be able to productize the data while ensuring privacy". After months of research into various attempts at online identity systems, web standards, security protocols and everything else, FindMeOn settled as hybrid system: FindMeOn.com would handle centralized management and content push ( apis, widgets, etc), findmeon.org would release and promote open standards to this means.

When Fred @ ClaimID beat us to launch, my jaw dropped - FindMeOn was pretty much on the same development timeline at that point as ClaimID. My friend Chris had sent me an email, and I had never been so scared to click on a weblink before. When I read through his approach, I experienced an amazing relief - I don't think any two identity projects could have been any more different.

The first big difference was that ClaimID was really working as a destination/portal - people would visit ClaimID to view aggregated content. We specifically steered away from that model, as we found it very network antagonistic and networks we focus grouped basically said "Steal our users and we will destroy you". Networks view their users as their revenue stream ( read: advertising base ) ; bringing them offsite hurts their bottom line. The team at ClaimID was able to diffuse that by positioning themselves as academics, we didn't have that luxury. Surely enough, as more people would enter the aggregation space (or other portable content systems), they would increasingly find their links and widgets stripped/blocked from MySpace and other sites. A large tenet of our system was to not just simply avoid network antagonism, but to really come out and be network positive.

The second major distinction between FindMeOn and ClaimID is this: where ClaimID was focused on tying all of a person's online IDs together, FindMeOn was concerned with managing a 'Meta-Identity' and exposing facets of it to different online networks or even 'roles'. ClaimID works perfect if you want to create a central public repository of your online info - but a lot of people don't want that. People share different parts of themselves offline -- shouldn't they do that online too? We designed the FindMeOn technology so that work and personal lives can never be conflated; so the end users can decide where certain people can find them ( and where certain people can't ).

Centralized Identity vs Centralized Identity Management

While I think ClaimID and some of these other Centralized Identity Systems are great tools, I think their utility is ultimately limited by human nature. People are increasingly wary of sharing "Too Much Information" online as the veils of anonymity are lessened.

A few Reasons to use ClaimID / OpenID / Centralized Identity

• You are an author and want to create a listing of your published articles & website identities.
• You are a 16yr old blogger and living your life openly online. You want everyone to read everything about you.

Centralized Identity systems work well for these situations, because everything ties back to a unique universal id. If you think of this in terms of a bicycle wheel, the spokes are all on different parts of the wheel, but they connect to a central hub; if you trace any single spoke back to the hub, you can access every other spoke on the wheel.

A few Reasons to use FindMeOn Centralized Identity Management

• You work in an office that has strong support for political groups that you oppose
• Parts of your personal life are a little too casual to be exposed on your business sites
• You want to share photos of your child and your family blog with close friends, but not with the people who regularly read and troll your personal blog

Centralized Identity Management systems use some sort of firewall that abstract connecting the spokes to one another. With FindMeOn, we use abstracted identity endpoints as our firewall (we wanted to use the external identities, but ran into problems when more than 1 person had the same email or website). Users update a central repository with their information, and configure rules on the firewall that affect how information is shared.

We believe Centralized Identity Management is superior to Centralized Identity , because it is far more responsible when dealing with user privacy.