Thursday, March 26, 2009

Permaculture / Currency as Language

I spent two years working on a small organic family farm, and was certified in permaculture while I was there by Scott Pittman (who is in THE MONEY FIX). Scott taught us to see biological systems in terms of flows and patterns. If you want to describe the state of a non-living system (such as air in a balloon), you use Newton’s laws, the laws of Thermodynamics, and chemistry. Once a system becomes living, however, these laws are insufficient to explain its behavior.

Ilya Prigogine coined the term “dissipative structure” and used it to describe life (among other phenomenon). A dissipative structure is a pattern that is stable in conditions far from equilibrium. To understand this, think of your body. Your body is still you, even though every atom will be completely replaced every few years. What constitutes you is not your physical “stuff” but rather your pattern. This is the realm of the biosphere. Patterns. And permaculture helps us understand and interact with these biological patterns of flow.

However, there is another layer when we talk about human behavior, and that is the layer of meaning or mind (Noosphere). If we want to grock human behavior, an understanding of biological patterns is insufficient in itself. Humans base their behavior on concepts in addition to biological needs. How would I use biology to describe or predict the effects of the Constitution? Shakespeare’s plays? The Beatles? All of these phenomena exist in the domain of meaning, and as such have a powerful affect on our behavior.

In the domain of meaning, we need the structure of a language to interpret those meanings and resonate with each other. Fundamentally, we use language to coordinate our behavior as a group. There has been a great deal of research on the deep structure of natural language (spoken or written word), but there are many other kinds of language. Music, art, dance, etc. are also types of language in that they provide a framework for mutually understood (and extensible) meanings between artist and viewer, and that those mutually understood meanings allow a resonance. Does that make all of these things currency? No.

We all think of speech as language, and many of us think of art as a language, but how many of us think of currency that way? If we do start thinking of currency as a language, we quickly see that it is much bigger than just money. We see that the same thing that gives money its linguistic qualities also bestows those qualities on grades, reputations on Ebay, movie tickets, etc. In fact all of these social systems can be unified by a single deep structure. I think Eric’s definition for currency hits pretty darned close to the mark: “formal information systems that allow communities to interact with flows.” Think of it as permaculture of the mind. ☺

Wednesday, March 25, 2009

Why the "currency" in the the meta-currency project?

In this blog post, Guillaume Lebleu takes a stab at defining the word currency, and recommends keeping it fairly tightly bound to its traditional meaning around "a form of payment in a trade". So I thought it would be helpful to say some words about why in the meta-currency project we use the term currency in different and broader sense.

First a short digression to build a metaphor: There are three realms of the physical world that on the surface appear quite different: light, sound, and waves on water. Under the surface, however, they are united by the general patterns described by the mathematics of wave mechanics. Once wave mechanics was understood, and we had a language to express those patterns, not only could we look at these phenomena with totally new eyes, it also meant that we could engineer physical systems that do incredible things to synthesize these realms: sound can be converted to into physical or electric representations, recorded on wax cylinders, transmitted over light waves, etc. etc.

What we are claiming in the meta-currency project, is that the seemingly different social phenomena of monetary exchange, eBay reputation points, grades, coupons, airline-miles, etc.., are similarly expressions of a common pattern. They are all:

formal information systems that allow communities to interact with flows

And we call those systems currencies, i.e. trade currencies, reputation currencies, loyalty currencies, performance metric currencies, etc. In each case the flows they interact with, or the ways they interact with flows may be in different realms of social manifestation, just as sound, light and water waves all have wave properties in different realms of physical manifestation. But what we have found, is that once we recognize this common pattern, we experience a paradigm shift: we change our focus from the information tokens, to the flows themselves. We begin to actually be able to see these flows, and see how the flows are what create wealth, and how the information tokens just help us interact with the flows.

Thus, the goal of the meta-currency project is to create a new expressive capacity, a "flow mechanics" that amplifies our ability to see and shape the flows that underlie healthy social systems. This is much like how "wave mechanics" is an expressive capacity that gave us amplifies our ability to build physical systems.

In an e-mail to me Guillaume created a metaphor to illustrate the difference between currency and reputation systems as part of describing why he's not comfortable using the word currency for both. He said: "currency is the water in the conduit, the reputation is the filter in the conduit, but the filter isn't fluid." This metaphor certainly works to an extent, but it doesn't reflect the paradigm shift that I've described above. I think the metaphor is more powerful if it is expanded thus:

The flow of water is necessary to life in a house. We need lots of integrated tools to shape how that water flows. We need pipes to direct where the flow goes, we need valves to keep the flow going in the right direction and in the correct amounts, we need filters to keep out crud from the flow, etc... All together, we call this plumbing. It's an integrated system.

Our goal is to create a platform that will allow communities to build the social plumbing that allows them to interact in all the necessary ways with the many types of flows that will make them radiant and healthy communities. I am totally convinced that such a platform must be flexible enough to carry information about more types of interactions than just trade, precisely because the paradigm shift that I have experienced is about the underlying unity of the patterns and processes involved.

So, my current sense is that claiming an expanded use of the word currency is a powerful strategic move to help awaken the understanding of this paradigm shift. Using old words in new ways is a time honored technique to get us to change our thinking, and that's exactly what's needed. Guillaume does make an excellent point in the post about the how the word currency when translated into other languages doesn't carry with it the flow connotations we have for it in English. That is a serious strategic issue, but I'm not sure how important it is that if we expand the meaning of currency in English that we also have to do so in all other languages. If it doesn't work in a particular language why not find a different word in that language that does? Strategics I think are always language and culture specific. But please note, that I'm not wedded to forcing the word currency into talking about all these types of flow shaping tools. It's just the best I've heard so far. The point is that what I want to focus on is flow shaping information systems for communities to build wealth at all levels, because they are all integrated. But who knows, maybe the best strategic move is to call it the meta-plumbing project!

I want to reiterate that I'm not talking about using this language to explain how to use Twollars, or time banks, or eBay ratings, or any particular currency that is created using the platform. That makes no more sense than talking about wave mechanics when trying to explain how to use a microphone. But to build and design a microphone and the devices it is attached to, we had to have developed and gained fluency in the language of wave mechanics.

Just one more thing: This sounds like an overwhelming task, and really long term. At one level it is, in that the fullness of what will come of it is huge and will only appear in the long term. But getting started is not that hard, or that long term. I believe that at the very least, the crucial components of the kind of expressive capacity or language of flow needed to build this kind of plumbing are actually achievable short term. That, actually, it is like wave mechanics which boils down to some very simple relationships. There are few underlying basic relationships out of which all such flow token systems (including money exchange ones) can be built. These relationships become the basis of the meta-currency technical platform we are building, at the heart of which is the meta-currency protocol. More on that very soon...

Saturday, March 21, 2009

The Footprints of Flow

Alan’s recent of posts (about P2P Currency and Currency Platforms) outline a trajectory that points in this direction, but I want to specifically spell out one thing that is so different about what we’re building than any other currency projects we’ve seen.

There are some fundamental shifts that must be made in currency infrastructure for us to break free of the constraints and dysfunctional patterns of the past, and I don’t believe that any prior platforms provide for these necessary shifts yet.

I’ll let Eric write about how MCP and SGFL are also a complete departure, but I’m writing about the one that has been consuming my attention: Intrinsic Data Integrity.

Intrinsic Data Integrity

No, you didn’t space out in your computer science class and miss this term; I’m totally coining this phrase. There are a few other names for it that I’m considering, but for now, I’m calling it Intrinsic Integrity.

There were times when whole villages hid behind castle walls and great moats, and when the borders of nations were defined by defensible boundaries like rivers, coasts, mountain ranges and Great Walls. Closing something off behind high walls and tight defenses is certainly one approach to security.

However, we’ve discovered that there are much more effective methods to ensure security (even if many of us are not conscious of it). Notice that today, there are very few people living behind castle walls, and few nations focused on defensible borders. We’ve replaced walls with laws and moats with tort. Rather than erecting walls to hide from hordes of savages, it turns out we’re much safer having people internalize rules and laws. They suddenly cease being “savages.”

But when it comes to dealing with computers and data, we’ve mostly ignored this lesson. We lock our data behind passwords, permissions and firewalls, relying on that one type of security when we could have the data internalize rules which keep it secure. There are a few instances where we do this like when we use CRCs (Cyclic Redundancy Checks) to ensure a downloaded file hasn’t been tampered with, parity bits in RAID arrays, or check sums on network packets. However, we don’t generally structure the data we use for decision-making ways that ensure its integrity.

One great example of software that does do this is the distributed source code management tool called git. Instead of a tightly controlled central repository where you protect from unauthorized people committing changes to it, git allows anybody to download the source code for a project (for example, the kernel of the Linux operating system), make modifications to the code and then commit the code again!

This would be very dangerous to do with typical software or databases. Imagine if you could download your bank’s internal software or your bank account data, make changes to it, and then recommit it again. Everybody would be changing their bank balances all the time. With git you can’t alter something without adding a completely new commit which records your signature. If you tried to make a sneaky unsigned change to existing data, it would longer match with the signatures attached to it. This makes it safe for people to change to the Linux kernel and yet ensures they cannot introduce flaws or security holes because it will break the signed data patterns.

By implementing Intrinsic Data Integrity, you can allow people to have a completely authoritative copy of their own transaction history. This data could be specifically shared with the parties of each transaction, or shared with third party notaries or auditors, or possibly open to public review. New ways of analyzing and aggregating the data become possible, because the original data is available in a linked and signed chain. Just like you can notate the moves of a chess game and replay them to recreate the state of a chess game, you can replay the signed transactions to create the state of an account or the whole currency system at any point in time.

Tracks in the Sand

Humans are good at seeing objects; but we’re not so good at direct apprehension of flow. Flow is really only visible to us when it is embodied in something. We typically create a story from the movement of stuff and the after-effects on objects to perceive what is flowing. We see the Grand Canyon and rebuild the long story of erosion that etched it. We see mouse tracks in the snow which end in a sudden deep indentation having wing marks on either side and reconstruct a story of a flow that occurred.

If currencies are the tools for shaping, enabling and measuring currents or flows, then a linked chain of digitally signed transactions are the tracks those flows leave behind so that we can understand the story that the flows are telling. If we later learn about patterns we want to study, we can always go back to the original flow-tracks and look for them. Each participant in this kind of currency becomes a sovereign individual empowered represent their current status and complete history.

Openness is about more than open source code

Consider Wikipedia. It is more than an Encyclopedia which uses Open Source software. There are millions of sites and wikis built on such open source tools. But the Wikipedia folks made a decision right up front that has encouraged many thousands of people to invest their time, expertise and money in supporting that particular project. They made all the data freely available. I don’t mean just readable via web pages; you can download their whole database and create your own fully functional copy of Wikipedia.

Why is that so important? It is an explicit promise that your investment will never be lost because of bad policies, poor decisions, internal politics or failure to adapt to the needs of the community. If someone can do the job better than Wikipedia, then they can just take the all data and start doing so with better policies, incentives, interfaces or whatever. The cost to branch the project to another, possibly more fruitful path, is extremely low. This looming possibility also serves to keep them honest and responsive.

A closed currency system (behind castle walls) where individuals do not have the sovereignty to fully and accurately represent their own activity history ensures that the investment of account-holders dies with the authority managing the castle walls. The integrity of the data relies on the ability to defend the walls and requires complete trust of the individuals who get access to the data inside the walls. Once a single individual abuses the trust or the walls are breached, all the data becomes questionable. This makes it almost impossible to gracefully transition data from a failed project to new endeavor.

A Walled Currency Will Eventually Fail You

Let’s pretend for a moment that there are two possible outcomes for any currency system – success or failure. I’m going to completely forego defining success, so you can view it as massive adoption, high volumes of activity, universal liquidity, meeting the needs it was designed for, or whatever. If the individual participant does not have sovereignty which includes full “ownership” of their personal data either outcome ends up being a loss for them.

If a bad currency design fails, the value embedded in it is lost. However, currency failure may happen for reasons independent of the validity of the currency design itself: bad timing, bad governance, inadequate leadership, lack of funding, lack of promotion, poor infrastructure, internal strife, etc. Whatever investment of time, energy, learning, goods or services that each participant invested is completely lost and generally cannot be usefully ported to a new iteration of an otherwise good currency. If some people still like the original idea even though it was steered awry, they are forced to start over from ground zero.

On the other hand, currency success tends to lead to continued use, reliance and influence. As this cycle continues the currency gains more and more power and influence in its community or economy (consider the dynamic of national currencies). In a silo/castle-wall system, the people who control it also grow in power and influence. It becomes harder and harder to consider alternatives to the currency system because it seems so vital. Eventually, imbalances emerge. The centralized access and control leads to corruption of leadership and inequitable treatment (even if unintentionally via Pareto Effect). Or needs of participants change but the system doesn’t adapt effectively. In any case, the only way to break free from a successful closed currency appears to be through painful and disruptive collapse.

Currently, we have the privilege of experiencing the collapse of a “successful” currency first-hand.

The only real way to avoid those dysfunctional dynamics is to have the underlying infrastructure optimized for easy forking, evolution and adaptation with each participant having the capacity to migrate toward systems which provide better solutions.

Never Surrender!

We have surrendered the power to make money to the government. Then of course, the power hungry have figured out how to get the government to surrender money-making powers to them.

In America, the bankers have "stolen" money-making power 6 times. We've taken it back from them 5 times. I suggest this time when we take back money-making powers, we keep them. We should not surrender them back to the government or any oligarchical group.

Intrinsic Data Integrity ensures that we can maintain our sovereignty as individuals even when we gather together in communities and groups to create currencies. The other protocols of the metacurrency platform separate functions and powers so that there is much more of an open market for the various activities in a currency. The functions performed inside the closed banks, such as authentication/identity, transacting, auditing, managing security, granting access, enforcing rules, changing rules, maintaining the state of the system, assessing fees, storing records, charging interest, providing interfaces, etc. are broken into separate functions many of which an individual can do themselves, and for the others they can select from various providers who have the technical capacities. This prevents abuses of power by any one group.

Where Privacy and Openness Meet

You may wonder if we can make these footprints visible and still honor people’s privacy. Yes. We can share data and still ensure privacy, but many systems may not and should not do so. Transparency is a very powerful tool for spreading awareness and mutual trust. Most currencies would be wise to tap into that kind of power and clarity.

If, however, you have reason to safeguard privacy there are a number of solid ways to do so. The most obvious one is to encrypt the core parts of a transaction that you don’t want publicly visible, and leave only the outer layer of linked signatures visible. In this case, you don’t need to worry about whether the various “owners” of their transactions are protecting them behind high walls. Let them loose but build a tiny wall into each one.

This post covers the theoretical application of Intrinsic Data Integrity and its importance. I’ll have to follow it up with a geekier post illustrating technical aspects of its implementation.

I’m excited about the larger implications of the power shift from enabling currencies with Intrinsic Integrity.

I’m still trying to sort out how this is like giving social DNA the “organic” material to really evolve our social “bodies.” There’s more to come when I can explain that.

Thursday, March 19, 2009

Metacurrency grammars and Twollars

In the metacurrency world, one of the key things we need is a grammar to that allows us to specify what a transaction will look like for a particular currency. Yesterday Art & I had a wonderful conversation with Eiso and Mac from Twollars about how this might be accomplished in a mult-currency Twollars universe. Twollars is based on parsing tweets from the public timeline looking for a particular format that indicates that the tweet is supposed to be a transaction. Here's an example tweet that Twollars recognizes:

Give @artbrock 2 Twollars because he's brilliant

Grammatically this translates to:

Give [subject] [quantity] Twollars because [reason]

Twollars could become deeply multi-currency if instead of there being just that one hard-coded grammar, anybody could specify a grammar for the Twollars server to recognize as a transaction for their currency. All that's needed is to throw in a hash tag to specify the currency. Here's an example:

Twollars: #zippybucks Give @artbrock 2 because he's brilliant.

The meta-grammar here that the Twollars server could parse is:

Twollars: #[currency-name] [transaction]

And then the [transaction] part gets parsed by the currency specific grammar which is:

Give [subject] [quantity] because [reason]

Now there's one other thing that has to be added for this to work, and that is a notion of what state a transaction is transforming. I.e. what's the aggregate result of many transactions. In the case of the current Twollars, the state is the balances of tweeter and the tweetee, and the transformation rules are simple:

1) Tweetee balance is incremented by [quantity]
2) Tweeter balance is decremented by [quantity]

But this too should be up for grabs and specifiable by the currency creator. The way Twollars has started out, users are issued 50 Twollars to begin with. This means that the total amount of thanks that can circulate in the system is 50 times the number of users. Think about it. Does that really make sense? Not really because my capacity to be grateful and acknowledge value given to me isn't hard limited like that, which is not to say that it's infinite. Eiso and Mac have very good reasons for starting out Twollars as they did, so I'm not knocking that at all. I'm just pointing to the fact that in the multi-currency world we want communities to be able to specify the circulation properties of the currency as suites them best. So, lets imagine a different "thanks" currency where you can "give" different words of gratitude (or ingratitude for that matter) and instead of a balance in that currency, what you have is a count of those words given and received. Here are some sample transactions:

Twollars: #thx Thanks @zippy314 for his amazing...
Twollars: #thx Appreciates @fer_ananda for her....
Twollars: #thx Scolds @artbrock for ..

Now when specifying such a currency we need to give both it's grammar:

#thx = [action:Thanks,Scolds,Appreciates] [@] for [description:what]

and define what the states are, which for this currency are simply 6 numbers, the count of thanks/scolds/appreciates given and received, and also give the transformation rules which are just:
1) Tweeter [action word given count] increased by 1
2) Tweetee [action word recieved count] increased by 1

Of course the Twollars interface should hide almost all of the underlying details of the states and transformation rules, by giving us a simple AJAXy way of defining our little transaction grammars and choosing various state transform options, and it would all be really easy, fun and cool. From the sounds of it, you might see something like this on Twollars no too far in the future…

Here are some more examples of other such currencies that Art & I came up with:

A simple LETS currency:
#lets = [action:Pay] [@] $[qty:int] for [description:what]


State transform: qty adjusts Balances

Example:
Twollars: #lets Pay @artbrock $2 for currency consulting

A Kilowatt Hour currency:
#kwh = [action:Energize] [@] with [qty:int]kwh for [description:what]

State transform: qty adjusts Balance [where balance max = infinity & balance min = 0]

Example:
Twollars: #kwh Energize @artbrock with 2kwh for currency consulting

A LOL Cat acknowledgement currency:

#lolcat = [action:can haz cheezburgr, cant haz cheezburgr] [@] forze [description:stuff]


State transform: action adjusts Counts: e.g. 20 can haz. 0 cant haz

Example:
Twollars: #lolcat can haz cheezburgr @zippy314 forze cieling cat prayrz

A currency for rating political debates:

#DebateVote = [action:rates] @obama [rating] stars @mccain [rating] stars


State transform: rating adjusts Average

Example:
Twollars: #DebateVote rates @obama 4 start @mccain 1 stars

Monday, March 16, 2009

Intro to Currency Platforms

I was recently forwarded a question about the difference between LETS, time-banks, and Open Money. I struggled hard to find the right response and decided that the fundamental shift was from “currency designs” to “currency platforms.” What follows is my attempt to describe that shift.

LETS, time-banks, commercial barter exchanges, and HOURS (Ithaca or otherwise) are all currency designs. Open Money is a currency platform. Those in the currency design world have tended to focus on coming up with the best design to maximize the chances of success. There was good reason for this focus since roughly 90% of attempts at implementing currency systems quickly fail. The most successful designs have been built around the concept of “mutual-credit” as in LETS, time-banks, and commercial barter. While each of these employ different subtleties, the core design principle is the same.


Even when currencies employ the relatively successful core design of mutual-credit, the odds of success are still slim. More importantly, however, is that the cost of failure is high. Until recently, if you wanted to harness the power of currency creation for your community, you had to invest many long hours in organizing. Frequently, these hours were uncompensated and underappreciated. Given the odds of success, only the most zealous even bothered to try.


To date, currency designers have tended to try to find the design that will finally take the idea of community currency to its full potential. The goal has been to raise the success rate thereby making those long hours of organizing worth it. However, what if instead of success being more likely, failure was less costly? Enter the currency platform.


As Michael Linton has pointed out “we all belong to many tribes.” This means that there are countless communities we already belong to that might benefit from some kind of currency strategy. But who in these communities is likely to spend the hours of organizing needed to implement such a strategy? What if creating a currency was, as Linton says, “as simple and easy as starting an email group?” Then, there would be little to no cost of failure. If people used the currency, great. If not, no one sacrificed long hours to make it happen. By lowering the cost of failure, countless numbers of communities will gain access to the power of currency creation without the risk of anyone wasting their time on a wild goose chase.

Some of these currencies will be measured in hours (as in a time-bank); some will be measured in the national money (as in LETS). Some will involve complex formulas for calculating credit limits; others won’t have credit limits. Some will have open account balances; others will have private account balances. The specifics of the design will depend on the needs of the community in question, just as the specifics of how email groups are implemented depend on the needs of the group.


This evolution represents a PROFOUND shift in how currency designers will operate. For those wanting a taste of what this might be like, Twollars is about to release a multi-currency platform. While still in its infancy, Twollars will allow users to generate their own currencies by simply defining a hash-tag for them. Hopefully, other currency platforms such as Open Money will also soon be operational (and interoperable), so we can really get this party started.

Wednesday, March 11, 2009

Twollars (why they are an important step forward)

About a month ago, Eiso Kant and Mac Taylor released Twollars. Twollars is a twitter-based “thank you” currency that allows users to join by simply participating. To participate, you only need tweet in the following format: Give [amount] Twollars @[twitter user] for [reason]. The Twollars server continually searches the global twitter stream for text matching this description. It downloads the tweets (to prevent them being deleted), and tallies a user balance based on the tweets the user has given and received in this format. The user balance and transaction history is completely open, meaning anyone can see it. This helps prevents fraud. After all, how different might have Enron behaved if their books had been open?

Eiso and Mac have set the arbitrary amount of fifty twollars (TWs) as the starting balance for anyone participating. They have also proposed a non-profit fundraising component where Twollars donated to charity are matched by conventional money donated by a business once a certain Twollars threshold is reached.


However, what makes Twollars an important evolution in currency design are not the surface level details. Twollars is using a very popular existing platform (Twitter) for transacting and accounting. Most currency efforts to date have depended on a separate platform specifically designed for currency exchange. While this has yielded some limited results, people who want to participate have been forced into walled gardens. Twollars gives added functionality to an existing user identity thereby lowering the entrance barrier. There are numerous Facebook applications that make use of this principle, and many of them could be thought of as a kind of currency. However, few people think of them that way, and their use value is somewhat questionable (do I really gain any value from having a sheep thrown at me?).


Community currencies have frequently charged a yearly fee (in conventional money) for membership in their “currency club.” With the advent of Twollars, this approach has become outdated. Lowering the cost of failure for participating in a community currency will likely make the idea far more appealing for the potential user. The fact that Twollars is on an existing platform, where the use of the currency promotes the currency itself gives Twollars a viral quality that other currencies simply don’t enjoy.


Even more significantly, according to Eiso, they are close to releasing a version of Twollars that allows for user generated currencies. People would be able to define their own currency by simply defining a hash-tag for it. For instance a Portland based time-bank focused on the film community might use “#pdxfilmtb”. The Twollars server would tally transactions bearing this hash-tag separately from others. A simple mutual-credit architecture would give the power of a time-bank to any and all people willing to participate for free. Here finally we see the dawning of what many of us have been waiting for: a free, multi-currency platform that demystifies money / currency, and empowers the user to define their own economic exchange networks.


Eiso and Mac are also very wisely using the K-I-S-S principle (keep it simple stupid). Many of us (myself included) in the currency world have a tendency to over-complicate matters, especially when it comes to the user experience. Someday soon, we will need a nuanced platform that can describe any currency imaginable, but for now a simple mutual-credit architecture (like LETS or a Time-banks) will be able to engage a wide array of people who haven’t considered the possibility of using community currency before.


In addition, Eiso and Mac have both been very open to the ideas and input from other members of the currency world. By releasing their beta version and soliciting input from the community, they have adopted one of the key success strategies of social web innovators. I can’t overemphasize my enthusiasm for the Twollars project.

Congrats!