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.

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).


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.