Tag: microformats

Reputation badges as a driver for benevolent behavior

I’ve had a couple travel hours today to continue my reading of Richard Alexander’s The Biology of Moral Systems. The essential thesis of the book is that our moral, benevolent behaviors are motivated by our desire to receive indirectly reciprocal benevolent behaviors from others in a way that maximize the reproduction of our genetic capital. “Indirect” means that we may not get the reciprocal behavior from the same individual as the one we originally were benevolent to. There is another indirection since we may not even ourselves get the reciprocal behavior, but it might be given to our descendants or relatives. As Jean told me a few months ago, we might want to call this “slow reciprocity”.

In other words, we are acting morally and being benevolent to others, sometimes making this moral behaviors into law because it will serve the reproduction of our genes. For instance, monogamy rule limits competition between males, which maximizes every male’s chance to reproduce.

Another example are empirical evidences that social recognition of donations is an important incentive in pro-social activities, as if we cared about talking about our donations/moral behaviors in return for reputability and ultimately obtain an indirect return even if it won’t be ourselves but our children or great grand children who will enjoy it.

For instance, this paper documents an experiment that shows that when people know that their donations are being watched, they tend to donate more.

Another example is a study on blood donors in Italy that has shown that “that donors significantly increase the frequency of their donations immediately before reaching the thresholds for which the rewards are given, but only if the prizes are publicly announced in the local newspaper and awarded in a public ceremony”.

In a Web 2.0 world, this public announcement would translate to the blood bank issuing a virtual badge  certificate, that the donor would be able to shout out to their friends on Facebook or publish on their Web sites.

There are many blood donors Facebook groups, but I don’t believe anyone requires a certified blood donation to become a member. The closest think to a blood donor reputation badge is the I give blood application, allows your blood center to automagically upload your donation and cholesterol history and your blood type to your profile page.

Badges are also used in the Foursquare social game application, but are less serious. “They are little rewards you earn for doing interesting things – e.g. staying out late on a school night or visiting places far outside your neighborhood”.

Despite the positive potential that these reputation badges could unleash, I am not aware of any standard mechanism in social networks that support this. You can advertise a donation you’re making via TipJoy, but you can’t get a certified donor/benefactor/donator for all the good things you’ve done.

As Jody Reale mentioned this morning: “Why nothing positive is ever recorded in one’s “permanent record.”

One simple way to achieve this would be for non-profits receiving donations to publish on their Web site the name of the donors. This is something Wikipedia does. It wouldn’t take much for donation receivers to microformat these pages with hReview (the URI pointing to the Web identity of the donor), in a way that it can be easily extracted, aggregated and re-published on social networks.

Microformats and decentralized online currencies

Most people are probably aware of the announcement by Google (following Yahoo’s announcement) that they would be supporting microformats.

What is really interesting to me is what this means for online currencies.

If you look at an hReview, what it is fundamentally is a declaration of positive (or negative) experience measured as a number betwen 1.0 and 5.0 about an item, which someone publishes on the Web anywhere he/she wants. An aggregator like Google in turns aggregates it and computes an average of the rating. The reviewer does not need the authorization of the reviewed item to publish the review.

That name typically includes a link (URL), which can be viewed as one of the identifiers of the reviewed items on the Web. It might be their own homepage for a restaurant, or it might be a description of the item on a review Web site such as Yelp (here the Yelp URI of a thai restaurant where I live).

In the payment world, there is already a payment application that allows you to donate/pay money without the other person having registered, it’s Tipjoy. The way it works is that you donate to URLs on the Web. Just like an hReview, the recipient does not have to be registered with TipJoy for others to tip them. If and when they eventually register they can claim their money by inserting a tipjoy tag with their username in the HTML of their Web page. Twollars followed a similar process but with Twitter names instead of Web URLs, but Twitter names are also URLs…

So the general pattern of Twollars,  TipJoy and hReview is that you give or review a URL.

This could work for a really open monetary architecture:

  • People would write somewhere on the Web (typically a Web space they own) an hReview-like statement that they give a number of units of currency to someone else. For instance: <span class=”hPay”><span class=”give”>Given</span><span class=”amount”> <span class=”value”>20</span> <span class=”currency” title=”us.ca.sf.bh”>BH$</span> to <a class=”to fn url” href=”http://www.yelp.com/biz/blue-elephant-thai-san-francisco”>Blue Elephant restaurant</a></span class=”hPay”> (Note that they could write it manually, but most likely, they will use a form that will generate it for them).
  • An aggregator would find this statement, either by crawling the Web, or if they are blogged via a RSS ping. The aggregator will typically compute balances (positive and negative). In a mutual credit model, people’s balances would be allowed to be negative, but in a traditional government-issued currency, they would not, they’d have to borrow it at interest.
  • Receivers may claim some of the URLs through a similar process than the one used by TipJoy.
  • Users may publish back their balances via a widget on their Web site.

What’s great with this model is that anyone can start playing, even create their own currency, very easily.

More importantly, you can have several accounting services tracking hPay statements and computing balances. You don’t need an account at a bank, your Web site is your bank account. What the accounting service does is simply authenticating that you own the space where you published transactions, and keeping tabs.

There are several issues:

  • Currency creation: Where do we register new currencies so that accounting services can distinguish different currencies? The ISO 4217 code is too limited to support millions of currencies. We need something like I used above: “us.ca.sf.bh”, which would allow new currencies to be easily created out of existing ones simply through forking.
  • Currency rules: different currencies have different rules. Some will allow negative balances of any amount, some won’t allow anything below zero, some will allow some negative balances or positive balances with limits (ex. 5,000). These rules must be encoded in a formal language, published to accounting services and participants and associated with the name of the currency. Eric Harris-Braun and Arthur Brock have already explored this topic extensively.
  • Refusal: how does a recipient refuses a given currency amount? (another currency rule BTW) this assumes that the recipient can be notified that their URL was mentioned. This is essentially a linkback.
  • Security, in particular:
    • Authentication: how do we make sure that statements posted indeed come from the person owning the resource.
    • Authorization/Privacy: how to we ensure that not all transactions I make are public, but available only those I transact with and possibly as few as possible trusted reputable intermediaries. OAuth could be useful here if the resources can be easily segmented and tokens can be issued to groups at once.
    • Non-repudiation/Tracability: how do we prevent the effect of people deleting hPay statements.
    • etc.

Quite a lot to think about. Some of these items will be the topic of future posts.