Hacker Newsnew | comments | show | ask | jobs | submit login

My goal is to create a service that allows users to carry their good reputation from service to service. The idea is to collect the achievements you have earned from many sites and make them accessible via a single API. These badges or achievements could come from many types of sites and service. Some example might be Stackoverflow.com, Plurk.com and Kongregate.com which already award their users achievements. I’m hoping that sites will want to partner and award badges since they can get some visibility with links on the profile pages of users.

The system is based on the email addresses you used with the services you use. You can claim multiple addresses and manage them as a single profile. Another important feature is that the service does not require user registration to benefit from it. For example, StackOverflow.com might decide that you earned the 'Teacher' badge. They would make a call to our API and say "give youremail@example.com the Teacher badge". Even if we didn’t have that email is our system yet, we would record the action and the owner of that email can claim their badges later. Now when you sign up or use other sites they could place badge requirements upon registration or when trying to access special features. Perhaps all new users must have at least 3 StackoverFlow badges and 2 Twitter badges. Maybe a game forum requires that you have X WoW achievement to post comments. In a way, it becomes a sort of CreditScore for your contributions to other sites.

Also, since blog comment integration seemed like the perfect way to share your profile's URL, the system works similar to Gravatar. By MD5 hashing an email, you are able to link to someone's profile without exposing the email address associated with the page. So when you leave a comment on a blog, the blog engine can hash the email and link to your profile. Now we can all see how awesome you are on the internet.

As you can tell, this isn’t complete. I finished enough to get the idea across and get some feedback. I would appreciate your thoughts and suggestions. I wrote and designed this all myself and I could also use some suggestions on how to take things to the next step. Does it sound like an idea that really needs my full attention and possible VC funding since I depend on partnerships? Is this something you would use? Can other sites and services be bothered to publish this sort of data?

This is my example profile: http://www.kabadge.com/User/Profile/11d39fe94051978a44ce887a...




Trying to consolidate a person's reputation across the web is a great idea, and one that's only going to become more important.

However, I'm glad I read your explanation here because the site itself tells me very little and without reading your explanation I probably would have shrugged and kept browsing. Put this explanation on your site, and show people an example profile.

You really do have a "chicken and egg" problem trying to get providers to see the value. My two cents would be to write some blog posts on "the reputation currency" and try to get as much attention out of that as you can, getting people excited and enthused (and bumping up your own reputation on the topic). To me that seems like the best way (short of reaching out to many partners) to gain some traction.

Good luck!

-----


I would never limit access to a feature on my site based on badges someone has earned on another site. It's like slapping a big sign up that says, "In order to use this site, you also need to sign up for X, Y, Z, ..."

It's hard enough to get users to sign up for my stuff, let alone make them sign up for something else. Throwing in additional roadblocks is definitely not the way to go.

That's not to say I'd be against showing the badges they've earned elsewhere. That would be nice, I suppose.

Another problem: If things go very well for you, you'll end up with hundreds of partners all pushing badge info. On the other side, you'll have consuming partners that want to use this data, but they'll need to know exactly what badges to extract. Not every user will have the same badges from the same sites, so the consuming sites have to do the legwork of deciding which badges they want to display.

Further, if site X decides to change their badges, all sites that consume from X will need to change as well, or just keep displaying the now stale data.

Seems like too much communication will be necessary between all the different parties.

-----


I'm not exactly sure what legwork you're talking about for the 'consuming' sites. From what I understood of the description, the KaBadge site is the sole repository of badge information, with consuming sites pulling from that data when displaying a user's information (hence the API). As such, consuming sites will simply access that user's full or partial list of badges (possibly sorted by importance, or order of acquisition, or a genre system?).

A consumer might have to do specific badge checks for restricted sites like the WoW forum example (I agree that I would never use this feature myself, but I can see some value in it), but they would clearly know exactly what they were looking for beforehand.

-----


The legwork is in determining which badges are available and applicable to your specific sites. Here's an example:

Publishers: WoW forum, StackOverflow, HotOrNot.com

Consumer (me): Hacker News

As HN, I obviously don't want to display the HotOrNot badges, probably just the SO stuff. So, I set it up to pull those. Not too bad. Now imagine that there are hundreds of producers, some that make sense, and many that dont. You probably have to do a fair amount of digging to find those that make sense for your site, and a lot probably fall into a grey area. Then, you may find that only 1% of your userbase uses any particular 3rd party badge-producer. So you have a choice: include lots of badges, most of which will mean absolutely nothing to 99% of users who see them, or include only the most popular badges, which means the service ends up dominated by a few big producers (Twitter, Facebook, etc.).

I guess I'm having difficulty articulating, but I'm just thinking that as someone who runs a community site, I don't want to go digging through dozens of other sites' badges to determine what they mean and if they're applicable to my site. Plus, I don't want to have to re-do this every couple weeks to add any new badges that have appeared in the system. And, the only end result I see is being able to decorate user profiles with bling that is meaningless to the majority of the other users on the site.

-----


Ah, I see now. This strikes me as an idea that people will like, but I just can't see the use case.

Maybe it's because I've never understood the whole "achievement" thing anyway, but I can't come up with a reason to care about them at all. I can't think of a reason to use a system that restricts access only to people with completely arbitrary credentials. I can't think of a reason to implement such a restriction, either.

I can think of a reason NOT to export my application's "badges" to other applications, if any: it would encourage people to create accounts on my system for the sole purpose of gaining these badges. It further encourages behavior designed to obtain badges.

That said, I don't want to be too down on the idea. It's got some potential as an information hub. I would consider losing the "badge"/"achievement" terminology, downplay the "access control" angle, and bill it as a more generic hub for sharing information about what users get done in a given application.

I could see benefit of sharing information about -- say -- how often a user makes posts on user-moderated discussions, as opposed to voting, or that sort of thing. Swapping numbers and ratios instead of boolean data reduces the arbitrariness of the thing. The ability to use them in subtle ways, as opposed to ham-fisted restrictions, would likewise reduce the temptation to create throw-away accounts.

-----


>> it would encourage people to create accounts on my system for the sole purpose of gaining these badges.

I doubt anyone would make a (non-spam) system that rewards people just for signing up. The site creator would be careful to reward only meaningful actions. So this isn't realistic.

>> It further encourages behavior designed to obtain badges.

That's the whole point of the badge itself though - encourage a particular type of behavior. I don't see this as a problem either.

>> bill it as a more generic hub for sharing information about what users get done in a given application

Very interesting take on the idea.

-----


The problem is that it's very difficult to make badges actually encourage the type of behavior you want, unless that type of behavior is "spend a lot of time doing something meaningless".

For example, HN could have a "1000 Karma" badge, which would be meant to encourage thoughtful, intelligent submissions and posts. People could instead say majority-pleasing things. Even worse, people could collaborate to vote each other's posts up. Get 32 such people together, have each make 32 posts in a topic that left the "New" page without getting any votes, and presto! 1024 Karma for All!

There are many variations on these themes. Badges (in social/multi-user settings) largely fail at getting people to do what you want, unless what you want is for people to waste time getting badges.

Now, in a closed system, this can be minimized: people who would normally read and post on HN are less likely to resort to these shenanagins, and others just wouldn't care. The aggregator gives them a reason to care.

-----


ok, interesting idea and nice site but where's the business case? i.e., "show me the money!"

-----


At scale, this site/idea could theoretically "own" the reputation market. There's definite value in that.

-----


There may or may not be (monetary) value in that. That's why the business model is necessary. Popularity does not necessarily equal financial success.

-----


Kabadge, The FICO (Fair Isaac Corporation) of the Social Internet.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: