Thoughts on a Twitter Time Bank with multi-currency support

Today, Eiso Kant, the co-founder of Twollars announced that he had been working lately on a multi-currency version of Twollars, and that “soon everyone can start their own currency on Twitter”. This could be an interesting development for Twollars, which have so far acted as a multiplier and allocator of the generosity of the sponsors US dollars donations: Twollars are backed by commitment of sponsors to donate real US dollars to the charity of the donator’s choice (the first $1,000 was sponsored by Eisomac Ltd, the creator of Twollars themselves, and it seems they are now looking for a new sponsor for the next $10,000).

We will have to wait until more details emerge, as there are many different ways a multi-currency platform could be implemented.

In the meantime, I’d like to share some thoughts on the concept of a Twitter Time Bank, something I’ve been thinking about in the last few days.


The goal of the Twitter Time Bank is to allow people to bring the reality to the idea that “time is money”, and allow anyone to issue their own time-based money they can use to pay others for products/services or to donate to others.

Here is an example of how it would work:

“(from @glebleu) give @receiver 1 hr for …” would give the receiver the right to schedule 1 hour of my time with him/her/them, through an operation called “redeeming”. Alternatively, they could transfer the time/money I gave him/her/them to someone else via the following Tweet: “(from @receiver1) give @receiver2 1 @glebleu hr for …” (receiver1 gives one hour of glebleu to receiver2).

Give syntax

Anyone is free to give their own time money to anyone else they want for whatever reason they want. They can give as much as they want (but there is an obvious limit, as each person’s time is limited). Anyone is also free to transfer other people’s time money they received to someone else. Here is the syntax:

Short syntax (@giver = @issuer) “give @receiver 5 hr ….”  or  “give @receiver 10 mn …”

Long syntax (@giver <> @ issuer) “give @receiver 5 @issuer hr” or “give @receiver 10 @issuer mn”

units supported: hr or mn

Accept syntax

Although you are free to give your time money to anyone for something, they are also free to acknowledge it or reject it. Acknowledgment would be done via the following Twitter syntax:

Short syntax: (@issuer = @giver) “accept 1 @giverissuer hr for …”

Long syntax: (@issuer <> @giver) “accept 1 @giver hr from @issuer for …”

Creating fungibility with community currencies

Fungibility is the property of a good or a commodity whose individual units are capable of mutual substitution.”

Personal time money is hard to get accepted, obviously. With the above scheme, each time you are given some time money, you need to review the issuer for the value of his/her time to you and his/her creditworthiness.

To make personal time money useful, we need to make it fungible, but obviously all people’s time is not fungible. It is only within specific groups/communities that it may be.

To create mutual substitution, we need to allow people to spontaneously mutually agree to make their time money substitutable with one another. This agreement is a currency. In Twitter terms, @user1, @user2, etc. create a community whose currency is for instance called #bernal (say for the Bernal Heights neighborhood in San Francisco to support neighborhood “barn raising” events). In the community currency configuration, the community admin can decide:

  • how people can be accepted in the community (ex. unanimous vote, cooptation from a minimum number of existing community members, verification of affiliation, etc.)
  • the limit on each community members’ un-redeemed issued time.
  • whether the currency can be sold for US$ to highest bidder (note that there is no way to prevent it from happening, so it’s better for the process of buying/selling currency for US$ to happen in a way that can be tracked and users protected from theft).

Once this is set up,  community members can issue community currency backed by their own personal time money. For instance, if I’m a member of #bernal, when I tweet “give @receiver 1 #bernal hr for…”, I automatically have an additional @glebleu hr that is accounted for in my un-redeemed issued time. If I exceed the personal issuing limit set for my community, the issuance is rejected (the received can’t accept it).

Web service

A Web service would provide a Web version of give and accept actions, as well as the following actions:

  • reports:
    • un-redeemed issued time,
    • un-redeemed (but scheduled) issued time,
    • total redeemed issued time
  • search profiles of people that you can redeem your personal money or community currency with
  • request redemption (schedule time & location, or redeem for US$)
  • confirm redemption
  • bid in US$ for redeemable personal time money or community currency
  • personal profile/preferences
    • auto-accept given money (default is no for personal time money, can be configured on a per community currency basis)
    • authorize personal time money issued to be sold for US$ to highest bidder (default is no, but there is no real way to prevent it to happen)
    • community currencies joined
    • schedule w/ booked time.
    • geo location, services/products provided for 1 hr, delivery (F2F, online), etc.

Business Model

The business model would quite simply to take a % of the time money sold for US$ (the system would allow users to prevent their issued time money to be put up for sale in US$ if they’d like to).

Twitternomics, the Twitter currency, and the monetization of Twitter

In my previous post, I argued that the ReTweet (RT) is the currency of Twitter. The rationale goes: When you RT, you extend or donate some of your reputation to the Twitter user who originally tweeted, and you should earn something for it, say some RT credits or possibly even some hard dollars. The service ReTweetRank, which ranks people according to how much their tweets are re-tweeted seems to follow the same line of thought:

Retweets are great indication of the originator’s topical influence and the audience’s interest.

There is a major issue with my argument though:  it’s not because I donate something to you, that it necessarily has value to you. It only does if you acknowledge so. We can assume it does since you are following the person, but that’s a quite rough estimate.

So, things are a little more complex and we have to dig a little deeper. It’s good to start with some Twitter economics or Twitternomics:

When you tweet (or re-tweet), you essentially donate to your audience a piece of information that you think has value to them. But only when your audience acknowledges your tweet’s value, you should earn something from them.

What are these acknowledgments:

  • The simplest form of acknowledgment is to spend the time to read the Tweet, but unfortunately that’s not trackable. The closest thing is to know which unique Tweets in the authenticated user’s friend timeline has been retrieved from Twitter, which is not easily trackable across all Twitter clients (except by Twitter themselves).
  • The next form of acknowledgment is to click on the link provided in the Tweet, if any. Normally these clicks would be hard to track, but since most Twitter users use URL shortening services like, the URL indirection provides a point of tracking how many did visit the URL. One problem is that it is difficult to track who actually clicked, but this could be easily resolved if Twitter or a Twitter intermediary was rewriting all the URLs to include the username of the authenticated user.
  • The next form of acknowledgment is the ReTweet.
  • The ultimate acknowledge is to make the Tweet a favorite. I put this one at the top because it is a persistent acknowledgment, not a transient acknowledgment like the RT or the URL click. But my guess is that it is also not as used as a RT simply because they don’t drive as much traffic (who tracks your favorite Tweets? not many people).

To come back to when you earn or when you spend Twitter credits or Tweetbucks or RT$:

  • you earn a credit when someone acknowledges your Tweet. Say, 1 Twitter cent for a view, 3 Twitter cents for a click, 5 Twitter cents for a RT and 8 Twitter cents for a fave. This isn’t too far from what I mentioned in last year post How to measure someone’s Whuffie.
  • conversely, you pay 1 Twitter cent for a view, 3 Twitter cents for a click, 5 Twitter cents for a RT and 8 Twitter cents for a fave. In other words, it costs you to be nice to others (giving attention or clicking buttons and writing things takes some of your valuable time indeed).
  • The ReTweet is a special case. If @a retweets @b (“RT @b check out this link”), it would make sense that any click on the link or further RT (“RT @a RT @b …”) should earn both @a and @b something. @a acts as a distribution channel and should take a share of the credits earned, say 50%.

So far, this is a zero sum game with funny money and no-one loses anything.

Just like RetweetRank, a list of the richest (in Twitter $) Twitter users could be compiled and people may start to compete for a better rank.

A simple business model might consist in providing a foreign exchange mechanism between Twitter $ and real U.S. dollars. Twitter users with positive balances would be able to offer their Twitter $ for sale, and Twitter users with negative balances would be able to offer to buy in U.S. dollars. Twitter would simply take a commission on the fee.

Of course, this isn’t incompatible with Twitter offering the possibility for users to pay for RTs rather than charge for them, as a way to provide additional incentives for users to RT.

“Please ReTweet”: RT as currency and Twitter social ad business model

There have been various discussions in 2008 about what business model Twitter should use to monetize its user base. I’m not aware of any that have considered how the Retweets (user’s re-posts of existing posts of users’ they follow) could be leveraged into a social ad platform.

Retweets are a powerful way for people to broaden the audience of their tweets beyond their immediate followers. Some people spontaneously retweet interesting tweets posted by others, but some users actually request others to retweet their posts. Every minute or so, there are several Twitter users asking their followers to “Please RT” a link they tweetted about, whether it is to promote an event, an widget, some marketing offer, or to find someone. Here are some recent examples:

DuongSheahan: It’s tonight! Christian Women Tweet Up 9pm EST Go here to register: (expand) #cwtu Please RT

RefugeesIntl: RT @deborah909 Please help me spread the word about this new widget for advocacy groups:

micaela6955: Win a $50 Pet GC at Please RT!

RT @shefinds: We need a NYC intern – please RT to anyone you know

Currently, when users kindly retweet these posts as requested by their sender, they do not earn anything, soft or hard dollar. A Retweet is essentially a favor you make to someone because you can and you want. This favor might be worth a lot, considering that many Twitter users have 1000s or 10,000s of followers.

One way that Twitter users could earn something would be through a favor  bank, or in this case a Retweet bank or Tweetbank for short. The concept of favor bank is not new (I love this one in particular). Paulo Coehlo even mentioned the concept in his book The Zahir.

Here is how it would work:

  • When you retweet, you are making a favor, and you earn Tweet credits in the amount of the number of followers you have.
  • When you are retweetted, you are using a favor, and you lose Tweet credits as were earned by those retwitting your post.
  • You can’t really go bankrupt here, although you could go deeply negative if you are highly retweetted, which should encourage you to pay back by retweetting others.
  • If you are retweetted a lot, this should prompt others to follow you, which would make your RTs more valuable and make it easier for you to track your “debt”.
  • If you are in debt, and don’t want to be anymore (although it has no real consequences for you), you might be tempted to spam your followers with a lot of RTs. That would be a very bad idea actually, since it would certainly tire your followers who will surely decide to not follow you anymore, making your RTs in turn less valuable and your debt harder to repay.

This would be a nice little game with no real financial consequence for either one. But it could be pushed a step further with some users actually deciding to incentivize RTs with actual U.S. dollars.

When you consider that an ad by The Deck displayed in a Twitterific client costs roughly 5 cents (based on their December 2008 statistics/pricing), some may think they deserve a share of the advertising they provide: after all, they generally retweet if they consider that the tweet is relevant to their audience. With a 5 cent per RT, if you only have 20 followers, your RT is worth $1, $100 for 2,000 followers and $500 for 10,000. Not pocket change for many.

The way it would work is that a user willing to pay for RTs would set a max $ budget for RTs payment. Other users retweetting would earn the same credits as above but redeemed in dollars for the exchange rate of say a few cents, with Twitter taking its share as well.

A really nice plus of this model is that it would allow Twitter to monetize its user activity on any client, whether Web, Desktop, Mobile, SMS, etc.

How to compute someone’s Whuffie

Imagine yourself in a world where nanotechnology has made scarcity and the associated traditional form of money a thing of the past. In this world, the only currency is the goodwill that people give electronically to one another and everyone’s overall resulting reputation score is accessible by anyone in real-time. This reputation is Whuffie and the term and world was coined and imagined by Cory Doctorow in his sci-fi novel, Down and Out in the Magic Kingdom.

Fast rewind to present time. We are a world where people increasingly publish digitally their life i.e. are “life streaming”: they publish pictures, blog posts, twits, videos, wikis, etc. Other people subscribe to these life streams (RSS/friendfeed), give attention to the ones they find the most relevant and sometimes comment positively or negatively on these life stream items. These comments are themselves life streaming items and subject to views and positive/negative comments from others.

One thing is missing to get us closer to Cory’s vision: real-time computation of anyone’s Whuffie, the Web 2.0 equivalent of your FICO score. How do we compute it?

I have only found one blog post so far on the the problem of the so-called Whuffie algorithm, but I was not convinced by the arbitrary number of points won/lost for specific actions, and by the difficulty of implementing the tracking of some of these actions:

Trash talk somebody: -1000
For every conference you attend: +200 (Plus bonus +5 for each #tweet)

I know that Jeff Ward wrote that he was just posting for fun on this one, but since there seemed to be interest in the comments for an actual implementation, I decided tonight in BART to take a stab at what such algorithm would look like.

Here are the basic principles:

  • The algorithm should take into account how many positive/negative comments or citations your life stream items have got from other people, weighted by the Whuffie score of each of these people.
    • The use of the weight here is important as it allows to remove completely the arbitrary point amounts: for instance, instead of “For every conference you speak at: +10,000″, speaking at a conference would essentially be equivalent to posting a summary of your speaking engagement and have the conference organizers or the conference itself comment on it/cite you on their Web site, with the Whuffie value of the comment being a function of the Whuffie of the conference or conference organizers themselves.
    • The positive/negative nature of the comment would be determined via semantic analysis or microformats votelinks or voting nanoformats (vote:for:this article, +1/-1).
  • If the positive/negative nature of the comments cannot be determined, a positive Whuffie point amount of a lesser amount would be attributed, weighted by the Whuffie of the entity issuing the comment.
  • If no comment is available, views should be used (# of time a video was viewed), agained weighted by the Whuffie of who viewed it if possible. Views should contribute less Whuffie points then comments.
  • In all cases, for each item published a number of points should be provided multiplied by the number of followers the person/entity has on the site where the life stream item is posted on (# of subscribers to RSS feed, # of Twitter followers, # of Flickr contacts, etc.).

I don’t really have a precise idea of what these point amounts should be. Let’s say +10 for a positive comment, -10 for a negative comment, +5 for a comment, +3 for a view, and +1 for a published item.

Let’s also say that these points would be weighted by 1/100 of the Whuffie of the person commenting, viewing or following the publisher/life stream item. so, if my Whuffie is 1,000,000 and I view an image of someone, but do not comment on it, that gives 10,000 Whuffie points to the person who posted this image.

Of course this algorithm reduces the number of arbitrary constants to a few, but these are still arbitrary. So, the next question that came to my mind is whether there is a set of constant values that would be better than another, better for instance at achieving the goal of a Whuffie system.

What is such goal? do we want a bell curve distribution of Whuffie scores, a very spiky curve or a very flat curve. Do we want Whuffie to last indefinitely, or to self-destroy over time (with the objective of preventing social capital to be too concentrated among too few people). I think this is where I should have started, but that I will the subject of another post hopefully. In the meantime, I will get good ideas/suggestions from you.

Another interesting problem is how we fight spam and reputation hacking in such a system. I think one partial answer would be to allow Internet hosts to have their own Whuffie, and to use that as an additional weighting factor. Ideas here are welcome as well.

Twitter: Unified Communications 1.0 (beta)

As I was twittering earlier in BART, I had to switch from the mobile Web twitter interface to the SMS interface. It suddenly occurred to me that just as I was able to choose which communication protocol (HTTP POST, SMS, voice-to-text: Twitterfone) and I suspect the reverse service exists as well) to post a message, my followers would be able to choose to read them using the reader of their choice (Twitterific, SMS, desktop Web, mobile Web).

This reminded of the old concept of Unified Messaging/Communications. Here is the definition from ZDNet:

The realtime redirection of a voice, text or e-mail message to the device closest to the intended recipient at any given time. For example, voice calls to desk phones could be routed to the user’s cellphone when required. E-mail intended for a desktop mailbox could be sent to the user’s PDA or turned into speech for a phone message.

Twitter is indeed pretty close to being the version 1.0 (beta – for its reliability issues) of Unified Communicator, and it probably achieved adoption where others failed or partly succeeded because 1) it limited the problem to 140 characters, a good common denominator for a variety of protocols, in particular SMS, and 2) APIs were exposed for 3rd parties to extend its capabilities.

twauth: mobile authentication with OpenID and Twitter

I stumbled upon Ian McKellar‘s twauth prototype: a Twitter and OpenID based mobile authentication solution.

The idea behind twauth is to address the usability issues of current mobile OpenID-based authentication workflows.

The particular issue that Ian’s twauth addresses it the effort place on the user to enter alphanumeric passwords.

Twauth addresses this issue by replacing the alphanumeric password entry by a digits-only 5-digit one-time code sent to the mobile phone via Twitter/SMS, that the user then enters on the openid authentication page.

Here are some screenshots of the complete workflow:

1. Entering the twauth mobile OpenID URL at the mobile ( mobile login page

2. Instructing the OpenID server to send a direct (private) Twitter message with a 5-digit code (ignore the garbage):

Direct message selection

3. The mobile phone that is linked to the Twitter account linked with the twauth OpenID URL is sent a message with a 5-digit code (18010 – screenshot not available)

4. User enters the one-time 5-digit code:

Entering the one-time 5-digit code

5. You are authentic!

You are authentic