Category: tipjoy

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.

A bank’s payment strategy in 3 words: Convenience, Convenience, Convenience

The Bankwatch had an interesting post titled Payments – the impossible dream for Banks? this week outlining the importance of payments for banks and the challenges they face in bringing about innovative and user-friendly payment solutions. Colin’s line of thought is that:

  1. Banking has moved to self service
  2. Self-service allows two types of financial activity … view balances, or move money.
  3. Moving money is payments.
  4. Payments, as currently offered by banks, are mostly hell and they cry out for innovation
  5. Payments innovation is not about technology or standards (SEPA), but about customer experience

I cannot but connect this “hell” experience with one of the most interesting questions raised during the Mobile Web Wars conference last week:

Why  people are willing to pay for apps on the iPhone, but not on Facebook?
Why people are willing to pay $3 for ringtones, but not $1 for music files?

A participant was arguing that the reason was the “mobile effect” i.e. the fact the mobile is a relatively new communications channel that is so personal that people value it more than the PC channel. But at the same time, Bart Decrem, CEO of Tapulous, a social app company for the iPhone, was saying in the background: “Ease-of-use, Ease-of-use, Ease-of-use”, in other words: convenience drives customer value and their willingness to pay.

Something pretty obvious some would say, but this idea was made to me much clearer in the last few days while trying out two new services: expensure.com, a London-based bill sharing online application, and TipJoy, an online tipping (“micropayment”) service. Both services address different user problems, but they both address it very well with an extreme focus on convenience.

TipJoy for instance, does not require what you would normally call “payees” to register: you can simply donate to any URL on the Web you want. As Web site owners register and add the TipJoy button on their Web site, they essentially claim by the same token URLs and collect tips. From the payer / tipper perspective, a single click on the TipJob button is required, nothing more: the button is already configured by the payee with a pre-defined amount (in the order of 5 to 50 cents). This is convenience at its best.

Expensure solves the problem traditionally solved by complex spreadsheet. I used it to share bills between an upcoming WE trip with my friends and I was extremely satisfied with the application. It’s all in the details. For instance, I was able to set a ledger and experiment adding expenses to it without having to invite my friends to the service, something that would have refrained me from starting to use it, b/c my friends are too busy to receive unwanted invites from applications I found not worth using after a trial. In this case, I did, and ultimately send the invite to 5 friends.

Both applications touch on the problem of payments, but with an extreme focus on a relatively highly context-specific problem and a very well designed solution to the problem. Yes, I could have used my bank’s transfer service, or checks, plus a shared Google Spreadsheet, as I did in the past, but I will certainly not do so now that my social network is almost set up with Expensure. Same thing with TipJoy: while I could have used a PayPal button on my blog, I can see the value of simply providing a pre-defined amount to users willing to tip me, and will most likely go with them in the end if I ever want to be tipped for writing these articles (I’m not really and I’m doing this on the side of my day job).

What was the most interesting to me, what the following FAQ excerpt from Expensure:

Can I pay somebody back using Expensure? Soon. Right now we are focusing on making Expensure the best shared expense tracking app out there.

and from TipJoy:

Why can’t I withdraw cash from my Tipjoy account? There are legal implications to allowing this transaction which we are currently working through. We expect that you will be able to withdraw cash very soon. In the meantime, if you have a minimum of $5 in your account after removal of applicable fees, then you can do the following with your earnings: 1. Donate to any official charity you’d like 2. Purchase an Amazon gift

Both of these companies are clearly focused on providing the best customer experience first, then only will they figure a way to monetize it. They probably have listened very well to this presentation from Paul Graham on how being benevolent and focusing on solving problems is more important than thinking about making money when starting a business.

The only thing that these companies are missing is that they are not a bank or Credit Union, but as good entrepreneurs, starting a new CU or bank is probably not an option they will choose. Just like PayPal partnered with Wells Fargo, I would not be surprised to see an innovative bank or CU partnering with them to handle the back-end aspect of their solution, in particular legal compliance in each legal framework/geography they do business in.

So, when real-estate agents are asked about RE investments strategy, it’s: “Location, Location, Location”. When asked about early-stage investments, VCs talk about “People, People, People”. Perhaps, when banks are asked about their payment strategy, or their general banking strategy for that matter, bank should say: “Convenience, Convenience, Convenience”.