UI Update

After trying out several javascript-based data visualization tools, I decided to use dygraphs to chart an entity’s budget-related trends. This was not a straightforward choice since mootools extends core js objects and the potential for conflicts is always there, but so far everything – except for IE – works as expected. Dygraphs fits nicely with my UI design goals.

I will concentrate on the documentation for the remainder of this quarter. Although it took longer than initially planned, the UI came together pretty much as envisioned with js or Ecmascript doing much of the work and PHP just serving data for the most part. Definitely a new approach for me, but the benefits far outweighs the time investiment and frustrations in learning new libraries and closure-oriented code organization.

Busting Currency Myths

In exploring the workings of various currency systems, I’ve had to overcome ingrained ideas that thwarted my informal study of core design issues. These myths are quite powerful. It is worth spelling them out in detail, hopefully to serve as reminders since these myths come up often in currency-related discussions.

“If everyone has the ability to issue money, then that particular currency would soon be worthless due to inflation.”

This assertion is true only if market participants unconditionally accepted that particular currency, regardless of how much was issued. In fact, it is possible to design a currency system where published information about potential over-issuance helps regulate the behavior of currency issuers. The design should make currency traceable to particular issuers, so that market participants would have the informed option of rejecting over-issued currency. The design requirement for traceability led to the core concept of independent currency brands in satconomy.

“All currency systems involves notes or credits that circulate in a market.”

This assertion is true only for commodities and reusable, or transferrable, physical representations of credits such as coins and currency notes. However, in ledger-based currency systems which do not require physical representation of credits, it is quite easy to design a system where credits are not transferrable between currency issuers. There would be different motivations for issuing currency, especially in light of the fact that — if everyone could truly act as an indepedent currency issuer — no one would need to receive currency from others in order to accrue credits. The budget-centric OCAUP accounting system was conceived to provide a currency lifecycle framework for bona fide currency issuers.

“It is possible to design a large-scale currency system that is technically and administratively much simpler than current systems.”

It is tempting to look at the simplicity of a mutual-credit system and assume that its design could be scaled easily with minor tweaks and network or sociotechnological features.  I had the same hopes about five years ago when I started looking at currency systems, but I have since learned to embrace the challenges of dealing with complexity. It is true that the basis of any system might be simple and easy to understand. However, the policies and technical standards that are required to implement a simple system into large-scale, decentralized setting imply continous effort towards solving small and complex problems that come up regularly. In my opinion, a decentralized currency system that does not have an effective approach to auditing and indexing a diversity of issuers will not scale and influence anyone other than its limited membership base.

To summarize the counterpoints to the above myths:

– Even if currency issuance is decentralized, it is possible to encourage self-regulation and discourage inflationary tendencies by making currency traceable to specific issuers and not having guarantees of future currency acceptability between issuers

– It is possible to design a currency system where the currency lifecycle (e.g., budget creation, assignment and cancellation) is emphasized instead of currency circulation (e.g., credit transfer and velocity)

– Emergent complexity is inevitable in large-scale currency systems or frameworks, and must be carefully considered in the design of supporting  information systems, policies and standards.

2010 Q1 update

I have finished coding most of the UI in Mootools, but decided to refactor the code to not use the Class object. Instead, I followed the YUI module pattern that uses closure which feels more natural since, with private variables in the outer function, I don’t have to worry about the binding of ‘this’. I wish jQuery offered this advise upfront for code organization when I was deciding between it and mootools.

I have started ‘connecting’ the UI with the php-scripted accounting backend, but then I got caught up doing other projects. So the goal for this quarter, including writing more documentation, was not met. However, I am starting to get more comfortable with a long-term view of the whole IS design and infrastructure work. Having seen what others are doing, this project is probably at par in terms of rate of progress.

More importantly, I have a clear idea of the next steps that need to be taken and will take my time getting things right and working reliably. I am not as anxious in exploring potential collaborations during these early project stages, but would rather wait until I have a working system that clearly demostrates the importance of core currency system concepts and functionalities. Otherwise, too many ideas gets thrown in the mix with no clear purpose for the collaboration.

Project Update – UI development

Quick updates on development progress: The documentation for the revised accounting system and IPP is about 30% done, but it got boring pretty quickly. So I switched to the user interface design and development, and decided to have view-related code on the client-side as much as possible. This decision necessitated the use of a Javascript library or framework for more rapid prototyping. I have tentatively settled on mootools after trying out jquery. Both libraries are relatively easy to work with, but it is easier to model desirable ‘transaction device’ UI features using mootools’ class functions.

There have been interesting discoveries along the way with regards to binding ‘this’ and lexical closure in Javascript. I’m trying not to get side-tracked into reading too much about the ‘functional’ programming approach, although Javascript may not be the best example of that approach.

After posting this, I realized that I forgot to mention other projects that I visited recently:

The cyclos documentation and interface is really impressive. Like CClite, Cyclos has the concept of a ‘System’ account-type, which gets debited when credits are issued to members (at least that’s how I understand it and I could be wrong). The System account-type is very similar to an ‘unused revenue’ budget in the revised accounting system that I am working on.

However, in a cc-implementation, a System account is primarily used to track the total credits that could circulate or are circulating in a system and tends to be a static quantity that is dependent on the number of members and debit limits. In contrast, an unused revenue budget tracks how much credits an entity intends to receive from the market and is dynamically (a) increased whenever the total expense budgets is increased, or (b) decreased when inflows are received. The unused revenue budget is expected to reflect inventory or productive capacity rather than the number of members in an entity.

The other projects that I visited in the last weeks are opentransact, flowplace and the marketplace module for drupal. There are also many discussion groups, including agile-banking and ripple-users, with participation levels that are somewhat encouraging.

Plans for 2010

The three main goals for this year are:

1) By spring: Finish coding and doc’ing the updated demonstration of a budget-centric accounting system to serve entities that issue independent currency brands. The transactional back-end is pretty much done, with inclusion of xtype accounts for double-entry of inter-entity transactions and IPP support to facilitate payments across independently administered ledgers and accounting systems. The administrative and user interface should be updated soon.

2) By summer: Conduct smaller studies prior to an actual exploratory study. I’m still working out the details of these intermediate studies, but I’m confident that these low-risk steps will yield useful information for conducting effective studies in the future.

3) By year’s end: As some of the implementation concepts and strategy take concrete shapes, a more user-friendly website is being planned to offer accessible materials to general audience types. I’m sure most readers are not interested in following the always-changing technical implementation details, and perhaps there are even less who are interested in the philosophies and principles discussed at satconomy.org. At the same time, I am not really looking forward to creating yet another website, so this is lower on my priority list.

Dynamic Binding at Transaction Time

One way to look at ‘coupling’ is the relationship that a transaction record implies between transactors. For example, the use of community currency implies membership in the same community or in communities that have an agreement in place to accept each other’s currency. In Ripple, direct transactions occur only if the transactors have preset limits with each other and payments have to be routed through pre-established accounts. These requirements may be viewed as ‘static binding’ or predetermined configurations to set limits on who could trade with whom.

In the case of mutual credit community currencies, it is not hard to see similarities with the pre-WWW philosophy that hyperlinks are to be made and maintained through a centralized database. A requirement that transactors must have an account with the same mutual credit accounting system highlights this similarity. But the similarity extends beyond considerations of ledger boundaries and into logical or abstract rules for initializing who could trade with whom. As long as the ability to transact requires a predetermined relationship, the ‘localized hyperlinks’ mindset applies even if the accounts were maintained in separate servers or accounting systems.

Under tyaga.org’s implementation scenarios, a transaction does not automatically imply that the transactors are members of the same community or that they have established credit limits with each other prior to the transaction. Anyone could potentially trade with anyone else. It is up to a potential recipient to accept or reject a currency brand at the time of transaction – essentially, the concept of dynamic or late binding as applied to a currency system design. This is similar to the WWW philosophy of allowing any web page to link to another page at-large, which is a less-controlled way of doing things but inherently more flexible and scalable. Even though mutual consent is required for an inter-entity transaction, such consent is only applicable to one instance of payment and does not imply past or future guarantees of currency brand acceptability between two brands.

Loose coupling, as described in a previous post, is expected to lower the barrier of setting up new currency brands, leading to more spontaneous currency brand creation (i.e., more ‘new web sites’ in the current analogy). Dynamic binding, as described in this post, is expected to lead to more diverse market selections and higher frequencies of inter-entity transactions (i.e., more ‘interdomain links’.)

As with all design trade-offs, however, there is a price to pay for such high expectations. Tyaga.org’s design approach for achieving flexibility and scalability comes at a substantial cost of stricter reporting requirements and greater dependence on service providers to make make sense of huge volumes of transaction data. The challenges of reconcilable reports, auditors and currency brand indices arise since each entity is allowed and encouraged to set its own currency limits as budgets, without having to predetermine transaction boundaries or specific entities as revenue sources.

Loose Coupling Between Currency Brands

In assessing my project plans for this year, I reviewed the core requirements that the implementation is trying to address. In an effort to simplify the core requirements even farther than the one-page ‘game’ representation, I have arrived at the following three main concepts:

1. An independent currency brand corresponds to, and is issued by, an entity with a self-determined mission to provide certain goods and services to the market or general public.

2. Independent currency issuance is defined as an equivalent increase in the unused revenue and expense budgets of an entity.

3. Published reports are necessary to audit the whole currency lifecyle, including the corresponding inflows and outflows between entities.

Among these main concepts, the definition of currency issuance might seem the most arbitrary to others.  I now realize that this same definition also implies the other currency activity definitions in the ocaup accounting model. So instead of having to explain and defend the whole ocaup model (which really is not that complicated), I really only have to explain why #2 is so important to the design of accounting systems and payment protocols that affect inter-entity transactions.

First, it must be noted that all currency design require an accounting restriction of some sort. Community currencies impose geographic or shared-interest boundaries on where currencies might circulate. Ripple requires payments to be routed through a pathway of neighboring nodes. Traditional currencies impose restrictions on who could issue fiat notes into general circulation. So having a set of accounting restriction to guide the issuance and use of currency is nothing new and all are likely to be viewed as arbitrary. But why insist on #2?

The short answer is that #2 leads to looser coupling between currency brands. Loose coupling facilitates the ability to noncooperate with a particular entity by not accepting its currency brand.

For example, imagine a politician with a campaign budget that is funded by donations. If the politician’s ability to raise her campaign budget is tied to the ongoing donations that she receives, then she is more likely to care about satisfying the special interest of big donors such as lobbyists. In contrast, if she is able to fund her campaign budgets independently of donations that come in within a given period, then there is less pressure to attract or retain large donors. She would worry more about the acceptability of her currency brand to market participants and the general public. Because of #2, her currency activity is tied to the self-determined limits that her organization has set to conduct its campaign.

The other implication of #2 is that inter-entity currency flow is allowed as long as the payments do not lead to an increase in the unused budgets. In fact, considering that each entity fulfills a specialized role, #1 and #2 acknowledge that inter-entity transactions are to be expected and supported. Loose coupling does not have to lead to isolated currency systems.

When each market entity decides to issue its own currency as unused budgets, it would be impossible and counterproductive to predict which currency brand is going to be offered as payment for a transaction at any given time. Even if each person carries only one or two currency brands, a seller is faced with the prospect of receiving payments in many different currency brands from different customers (employees of google.com, seattle.gov, etc.) Clearly, an inter-entity payment protocol must factor such currency brand diversity in implementation use-case scenarios. Real-time advisories on currency brands would be the best approach since revenue sources would not be unnecessarily restricted through pre-emptive brand rejection based on potentially stale information.

To summarize, currency traceability to an entity, loose coupling between currency brands, and auditable reports of currency activity are important design goals that facilitate informed cooperation and nooncooperation with specific entities.

Web Content and Currencies

Imagine that the process of creating a currency brand is analogous to establishing a blog or web page. In addition, issuing currency units or a budget is similar to putting content on the web page, and that using the currency or budget is similar to having that content read by someone else.

What if there is a requirement to have someone else approve your content before you could put it on your web page? This requirement presents a burden to the author’s provision of content, and is analogous to having an unnecessary approval process for issuing one’s own currency brand. The proper approach that we see on the web is to let anyone write what he or she wants, and others do not have to read or visit that web page. Similarly, let anyone issue their own currency – if you don’t believe in what that currency brand represents, don’t accept it. 

Additionally, the pre-approval requirement presents an unnecessary burden to the content reviewer as well. Let us say that I agreed to be the reviewer. Instead of worrying about the quality of my own content, I also have to worry about reviewing and approving someone else’s content. This concern is analogous to: Instead of worrying about my own budget, I also have to decide what someone else’s budget should be as it relates to me. Let each currency issuer worry about setting its own limits and others could decide on the acceptability of a currency brand later if it gets offered as payment.

What if there is a requirement that registration with a certain web page is necessary before you could read its contents? While this requirement is understandable in a social network context where privacy is an important issue, it does not make sense in requiring co-membership if the purpose of publishing a web page is to share information.

Such a mentality of restricted usability also does not make sense when it comes to currency and budgets, which should be used based on perceived needs and not on having preconceived agreements to share and use a particular currency with others. This flexibility and openness is an important aspect of entities that cater their products and services based on goals to serve the general public or market. For consumers, currency that is limited to a particular community leads to limited market access. For providers, limiting service to pre-specified beneficiaries implies a conscious decision to limit potential sources of revenue.

The mentality that is advocated in satconomy is to minimize the barrier for an entity to independently issue its own currency brand. Issuing currency should be as simple as issuing unused expense and revenue budgets.  A fledgling entity should not have to determine beforehand who is going to accept or reject its currency brand, but should work steadfastly to establish a good brand reputation and increase its likelihood of being accepted by other entities. If an entity’s currency brand is found acceptable as payment, its unused expense budget and the unused revenue budget of the other entity is reduced by the same amount.

Some of the implementation concerns involve the technology for providing reliable and auditable information related to currency brands. There should be accounting conventions when currency is issued as budgets – this concern is addressed by the ocaup accounting model. Payments should be facilitated between accounting systems of different entities – this concern is addressed through the evolving protocol that is now tentatively called Inter-entity Payment Protocol (IPP). Finally, just as a search engine helps a reader decide which web resource to visit, a currency brand index should also be available to help entities decide whether to accept or reject another entity’s currency brand. The hope is that, just as there has been an explosion in the number of web resources due to the ease in which web pages, blogs and profiles are set up, there would also be a surge in the number of independent currency brands that are established using easy to use accounting software, uniform payment protocols and effective currency brand indexes.

The Year 2009 in Review

Since there are not a lot of development updates for this quarter, I will spend some time looking back at 2009 development ‘highlights’ instead. (The embarrassing fact that these are highlights says something about my odd interests in life.)

While tyaga.org’s philosophical foundations have remained stable and consistent (see satconomy.org), the technical details of the implementation have not always been easy to follow. There really is a lot of art involved in system design, even in an ‘objective’ technical field such as information systems. On a more encouraging note, the accounting system, which was called Entity Module in early 2008, has really become more stable this year. The code is much easier to read and the naming conventions have been mapped to the revised ocaup terminology. The seemingly unnecessary effort to implement transaction recovery outside of built-in database functionality is also paying off, especially as the protocol emphasis shifts towards allowing long-duration web-service type transactions. I still have not released the revised code pending the addition of other functionalities, primarily held up by the issues discussed next.

The effort to build on top of the Prowl demo was, to put it mildly, not very successful. In hindsight, it is easy to see that by using the publication of records as a form of ‘instantaneous reporting’ at the time of transaction, the payment messaging requirements had become too tightly coupled with reporting requirements. To drastically lessen this dependency, I am currently investigating a different approach that should be better in many ways than PaCT. In general, the same conceptual ‘parts’ are used but re-arranged for better modular ‘fit’ and orthogonal development. I expect this new approach, tentatively called Inter-entity Payment Protocol (IPP), to be demonstration-ready by early next year.

Finally, there have been brief but encouraging discussions with other currency design enthusiasts. The potential for collaborations is definitely brewing, but there has to be a good, even if not exact, matching interests on the importance of representing market entities in a currency brand index. More often than not, other projects emphasize visualizing individual contributions and personal reputation metrics, while the emphasis in this site has always been on enabling performance evaluations of specialized organizations that provide products and services to the market. In other words, tyaga.org’s information system design focus is on auditable budgets and inter-entity transactions between organizations, NOT internal transactions between members of the same organization or barter community.

That is pretty much 2009 in a nutshell. I will outline general projects ideas and work plans for the year 2010.

Reporting System Requirements

Now that I have finished concentrating on other projects and commitments, I look forward to continuing tyaga.org’s development work. One of the web sites that I visited recently was the community way (CW) in Comox Valley. The information design aspect that caught my interest was the ‘current numbers’ page with links to a graph and spreadsheets.

What follows is not a critique of the reporting system design as used by CW – for all I know, that design serves CW’s needs perfectly. I also do not question the community emphasis of the CW currency system and I sincerely would like to see such a system succeed wherever it is implemented. My goal in offering the following comparative analysis is to better explain the technical nuances behind tyaga’s evolving IS design requirements.

It has become obvious to me that the use of offline transaction instruments, such as minted notes, checks, or store-and-forward devices, could not be tracked efficiently and would not be conducive to the development of dynamic currency brand reporting systems. So while my earlier design notes referred to the importance of offline devices, I have since revised the technology requirements to focus on online devices. The most promising device in this regard is a basic cell phone with SMS capability, which is already widely deployed and inexpensive to own. While a QR-code app is not required to post transactions through SMS, a camera phone with that capability would simplify data entry and transfer between transactors.

Another design change, as described in a recent post, is the use of public keys for better non-repudiation and auditing capabilities. The example index on this site clearly illustrates the required tracking and metrics at the level of an entity, as represented by its currency brand, and not simply aggregated for a whole community as shown in CW’s current numbers graph. I am not sure of CW’s requirements for auditability, but tyaga’s design requirements include the auditability of any published performance and evaluation information for each entity.

Finally, it is clear that an under-developed reporting system does not hinder CW’s implementation. In contrast, a robust and dynamic reporting system is required to implement tyaga’s concept of spontaneous, targeted non-cooperation against specific currency brands. A currency brand index, constructed with dynamic information from reporting systems, should help participants make informed decisions on whether to accept or reject a currency brand in a transaction.

Again, I applaud CW as one of the rare, actual, working implementations of alternative trading systems. At the same time, I am reminded that there are not many development or implementation efforts that seek to address tyaga’s main information systems requirements.