A qualified ReTweet microsyntax idea

I have written a couple times in the past about the ReTweet as the Twitter currency. My conclusion was that you should lose credits when you RT and earn credits when you are RTed. I also suggested that the number of credits earned/lost would be fixed.

There is an interesting parallel here with the Twollars RT syntax: RT 2 twollars @giyom for …

I don’t know exactly how Twollars accounts for ReTweeter being ReTweted (Eiso?), but I like the idea of qualifying a ReTweet.

I see two ways to qualify it:

  • a number, positive or negative, indicating how much I like something or not (although the negative number may not be practical)
  • a hashtag or something similar, further qualifying my number. (BTW, I noticed that people like to add tags to the things they RT, but it’s not clear to receivers whether these were tags in the original tweet, or the RT only)

Examples:

  • Liking the Tweet: RT 2 @giyom … same as RT +2 @giyom same as RT ++ @giyom
  • Not liking the Tweet: RT -1 @giyom … same as RT – @giyom
  • Liking the Tweet for a specific aspect: RT 2 #fun @giyom …
  • In addition, a regular RT like RT @giyom would be accounted as +1

Note in the last example that the hastag is before the RTed username, which allows the receiver to see that the hastag was added by the RTer.

A tracker may keep track of balances for each Twitter user, like Twollars or Twitbank does.

A look at the Opensocial Virtual Currency API proposal

The Opensocial virtual currency API proposal is at revision #3. There has been growing interest in the money geek community as to what it might entail, so I thought I’d take a stab at it.

First of all, we are talking about virtual currency, that is governement-currency converted to a separate denomination to provide the following benefits:

  • Allow those without a bank account, particularly kids to be able to convert cash into virtual currency by way of gift cards.
  • Higher relative denominations (ex. $1USD = 10 virtual currency unit) for psychological impact: to increase the perceived value of virtual goods sold and of monetary gifts received.
  • Usually, non-convertibility or limited convertibility back into government-issued currency, which limits liquidity risk on the issuer side while allowing the issuer to use the currency as a way for users to earn by participating, checking-in, accomplishing tasks, volunteering personal information, etc.
  • Typically shouted transactions in the social graph as a way to seek mimetism of donations by social graph members or to increase social capital and seek indirect reciprocal benevolent behaviors.

Motivation

The first paragraph of the design explains the primary motivation for the API. The API provides essentially a way to workaround the fact that the application requesting the payment does not hold user’s credentials required to authorize the payment, so it has to communicate first with the container of the application, get the user’s authorization at that level, before the request can be passed to the authorization system.

A bias towards single currency per app

Looking at the details of the API, what is interesting is that there is no currency passed as part of the Payment object, only an amount and a reason. In fact, the currency is implicitly specified via the a opt_paymentHandlerUrl parameter (the URL of the payment handler) or via a pre-registered payment service URL.

In other words, it is designed primarily for applications who only deal with their own single currency, although it does not prevent an application to support multiple payment URLs. In all cases, each currency is tied to a currency service. It should also work very well for applications, which want to use a third-party currency and currency transaction service.

A bias towards purchases/rewards

Looking at the required versus parameters, the API seems really biased towards transactions between the application and the user such as virtual goods purchases.

The API supports both debiting the user’s account and crediting it, which means the API can be used to authorize both purchases and rewards for the user.

Extensibility

Despite the above mentioned biases, flexible “parameter” parameter can contain any application-specific data that the application may want to transmit. This opens the door to referencing invoice #, destination accounts, currencies, etc

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.

When will payment networks open up to non-government issued currencies?

Probably sooner than later, not only because these new kind of currencies are currently popping up all over the place and represent a lost opportunity for payment networks, but especially because there are very valid business use cases.

First of all, what are we talking about?

A payment network opening up to non-government issued currency would essentially allow payments to be done non just in US dollars or any other legal tender, but in privately-issued currencies, whether it’s World of Warcraft gold coins, Facebook currency or others. In particular, multi-currency payments would be possible: say 20% of the amount in a currency and 80% in another, which isn’t possible right now.

Furthermore, non-government issued community or virtual currencies are by nature circulating within a specific group of people, with limited conversion from/to real US dollars, which reduces revenue for payment networks exclusively focused on US dollar. It would be much better for payment networks to provide their operational expertise to communities and charge for it.

What would be the business case?

Think about the following scenario: you log in to Amazon and have registered your World of Warcraft username, so Amazon knows that you are a player. You have authorized Amazon.com to access your WoW balance and submit transactions on your behalf (say via OAuth). You now browse to a produce page, and instead of the regular price of $100 (USD), you see $80 (USD) and 20 WoW gold coins. You press the buy button, and $80 are taken out of your credit or debit car or bank account, while 20 WoW gold coins are transferred to Amazon.com WoW account.

Why would Amazon.com do that?

  • It’s a very cheap way to target and attract a particular community of customers that they can further target with specific offers knowing what they like.
  • It’s a perfect way to build their brand using the accumulated game currency on the virtual world
  • They can use the acquired game currency to target specific players with incentives to purchase at Amazon.com
  • As long as they see value in using these acquired game currency to build their brand (i.e. they recirculate them), it’s really not a rebate, simply a different use of their marketing dollars.

Beyond game currencies

Beyond game currencies, the above use case would be valid for any community currency, say of a particular city or neighborhood. It may not work very well for Amazon in the case of a neighborhood since Amazon.com may not be willing to spend too many dollars on a particular local community, but that’s the point: if they don’t, why would the local community shop at Amazon.com? there are probably other retailers that would be happy to collect currency that they can redeem for advertisment in a local newspaper or local Web site.

Exploring the possibility of a Rideshare currency in the SF Bay Area

Something I have been thinking about lately is a good use case / pilot for an Open Money currency in the San Francisco Bay Area. Although there is considerable effort spent discussing and developing currency tools, I feel there is a huge deficit of economically viable use cases for these currency platforms to be actually used.

After a discussion with Michael Linton on a Community Way Ridesharing project proposal he made to Credit Mutuel in France several years ago in 2008, I’ve given more thoughts to how it could be applied in the SF Bay Area. This is a topic I’d like to discuss on our next weekly SF Bay Area Open Money conference call.

There are several reasons why carpooling/ridesharing seems to be a good use case for Open Money:

  • Casual carpool shows that drivers are willing to pick up unknown passengers at a few known locations to benefit from free toll and getting across the Bay Bridge faster during rush hours. So, perhaps if drivers were given something of value in exchange for rides, they would be offering more rides.
  • Most cars during rush hours on major Bay Area highways still transport only one passenger, despite the fact that Bay Area residents are quite environmentally aware.
  • It is in the interest of companies to promote carpooling amongst their employees.
  • Public transportation is slow and if you take your bicycle on the train, it’s increasingly difficult to find a spot for your non-folding bicycle.
  • There are now location-aware ride sharing applications available on the iPhone/Facebook, which address the scheduling issue. See Carticipate or Carpoolworld.com.
  • Medium to long-term, gas prices are likely to go much higher, giving additional incentives for car sharing.

So, let’s go about this problem by asking questions: first, why do we need money to solve this carpool problem?

The main issue is that there is not always mutual benefit in sharing a ride. If riders need rides, it’s usually because they don’t have a car, which means that a mutual credit solution would not work: riders would quickly get large negative balances that they would not be able to repay by giving back rides to other people. So, drivers will expect to be rewarded with something else then a ride. I’m assuming here that most drivers will not go through the trouble of offering rides if they get nothing in return (some may be satisfied with accumulating these credits and donating them, but not most of them). Also, there are many Bay Area no-toll commuting routes where they would not be direct a benefit for the driver to offer a ride.

Why canshouldn’t drivers charge conventional, government-issued money?

Some web services such as Ridester do so, and the Craigslist ridesharing section contains many posts with offers to pay cash.

The main issue with using conventional money is that it does not account for the wealth created to the local community as a result of using ride sharing. The fact that someone is willing to use a ride share instead of using their own car has positive benefits for the community they live in, such as less cars on the road leading to less traffic and less accidents, as well as better air. For companies, it means less need for parking spots and more parking available.

The other issue ismay be taxation. If ride shares are offered in conventional US$, revenue will have to should be reported taxed (in practice, I’m told nobody does). If ride shares are offered in a dedicated currency in units of dollars, what it means is that it can only be used to get rides, which facilitates reporting and opens doors, with appropriate lobbying and political action, to legal tax deductibility at some point.

Why not use tax incentives or publicly-funded non-tax incentives?

Yes, one way of accounting for this wealth would be for local policymakers to offer tax incentives for those provided trusted reports of ride shares. There are actually tax incentives program such as TransitChek or CommuterCheck that allow for employees to receive up to $230 per month of tax free income as vouchers to be used to pay for local transit services. Unfortunately, as far as I know ride sharing programs do not qualify for TransitChek, only vanpools do, see for instance this program, which provides cash incentives for corporate vanpools.

Another way is to use public funds to finance non-cash incentives for those providing ride sharing. Here are examples of such programs in the SF Bay Area: the 511 Rideshare Reward$ program and the UCSF vanpooling incentives. These programs give gift cards for groceries, coffee or gas in exchange for reporting carpooling activity. There are several problems with these programs:

  • The main problem with these programs is that they are very limited in scope: the 511 Rideshare Reward$ program is only targeted at new carpoolers (if you are already carpooling or have participated in the program in a previous year, you can’t anymore – After that, there is still an opportunity to participate in the Spin the Wheel program, which essentially gives just a chance to win, but that isn’t a very strong incentive).
  • Another problem is that these programs are very underfunded: according to this article, the total amount of incentives financed is very low (roughly $16,000 in 2007).
  • Another problem is that eligibility requirements and reporting is time-consuming/clumsy: all participants to the carpool must register and report, but it does not seem that it can be conveniently done at the time of the transaction itself, which would be ideal.
  • The last problem is that the gift certificates mentioned in the program are for Amazon, Safeway and Starbucks, which may not be the best way to promote local business in the SF Bay Area.

Note that it seems that vanpool programs are more funded than ride sharing programs because they do not pose a threat to car sales revenues as ride sharing does (if you use vanpooling during the week, you still need a car during the WE). This is what this article argues. Maybe the combination of incentives is part of what explains why so many corporate vanpools have appeared on SF Bay Area highways in the last few years.

Looking for another solution: a rideshare currency.

There are many interesting elements in what I covered so far, but corporate vanpools aside, just driving on SF Bay Area highways shows that ride sharing adoption can still be improved.

As I mentioned in the introduction, a possibility might be the use of a ride share currency denominated in dollars and issued by participating businesses.

Businesses would issue them to their employees as benefits and would redeem them to whomever buys goods/services from them up to a limit % of the total transaction. For instance, a business might give every month $200 worth of ride-sharing $ to an employee instead of, say a US$100 raise in salary. To a given customer holding these rideshare dollars, for a US$100 transaction, they might accept as much as $20 in rideshare dollars. Besides employee loyalty, and conservation of US dollars in this time of recession, the benefit for businesses would be to advertise that they accept this currency as a way to attract these rideshare-friendly customers and promote their image as environmentally-friendly businesses (accepting these rideshare dollars might be particularly attractive to car-related businesses such as gas stations, garage, oil changers). As they collect these rideshare dollars, businesses may be able to re-circulate them for goods/services from other participating businesses, re-gift them to their employees, or perhaps even donate them to a non-profit of their choice that would use it to transport volunteers around or raise US dollars by auctioning them off.

Participating businesses might group into a ridesharing coalition to seek the rideshare dollars to qualify as income tax exempt just like the TransitChek or CommuterCheck.

Reporting would be greatly simplified by the use of a cellular phone-based platform for trading these rideshare dollars (maybe via a platform like Twollars or TwitBank), ideally integrated with existing payment networks for multi-currency (US$ and rideshare $) transactions at participating businesses.

A benefit of using an Open Money currency would be full transparency and integrity: at any moment, the sum of all rideshare $ account balances would always be 0.

Beyond the tradable rideshare currency – dealing with reputation

Beyond the tradable rideshare currency that is earned by giving rides and can be redeemed for goods/services at participating merchants, a reputation “currency” might be useful as well to rate riders’ experience of drivers and vice-versa. This is something most ride sharing Web services already do.

Making it practical

Besides the convenience of payment and the incentives for participants, I feel the biggest hurdle is practicality of carpooling/ridesharing.

On this topic, the way casual carpooling could be an interesting inspiration or template: the way it works is that those in need of a ride know exactly where to get one and those drivers who are willing to give a ride know where to pick up riders.

Perhaps the solution to carpooling is to set up casual carpool points at various well-known locations such as BART stations and provide riders and drivers ways to notify in real-time demand/supply at each location, possibly starting with only two locations, one in SF and one in Palo Alto for instance. Cars could advertise whether they are able to carry bicycles or not and riders would similarly advertise whether they have a bicycle or not (most riders would probably since we are talking about fixed drop-off/pick-up locations).

Conclusion

Bringing a currency platform is an important condition of the emergence of new currencies, but finding ways to use these platforms to solve real-world problems is even more important. It seems that ridesharing is an interesting use case that might benefit from the creation of a dedicated currency.