tyaga.org

The last quarter of 2011 has been productive as I have been able to devote more of my time conducting simple studies. I have generated a lot of preliminary data from prototype tests, but unfortunately, I am not prepared to share those results yet. I am still sifting through the data and familiarizing myself with relevant analysis techniques along the way.

I am enthusiastic about my progress and of having the opportunity to learn many things along the way. Although a lot of analysis work remains, it feels good to accomplish my main goal of performing at least one study this year. It was not easy switching gears midyear to code a prototype system for conducting studies, and then again to refactor the prototype in November to improve the efficiency and reliability of getting results. The wait throughout the first half of 2011, while settling in at a new workplace, was really worth it. Amazingly, I was able to use — and is still using — many of the lessons I’ve learned from my new work responsibilities.

For example, I ended up using a JSON-based datastore since MySQL seemed too heavy for coding a quick prototype at work. This shortcut proved really handy when I began to work on my personal project again. It really helped me see why different tools are often necessary for different prototyping tasks. MySQL is not a good choice for a research-oriented database system, at least in my case, so I dropped it and everything went more smoothly with simple JSON-formatted output files.

More importantly for my continued productivity, being in a research environment helps cultivate my skills and motivation. Even the daily routine of commuting to work requires a certain level of discipline to make my spare time count, a challenge that I find rewarding. I should also mention that I tried Erlang along the way and also Git, but the learning curve made me go back to the familiar PHP and the simpler(?) Mercurial. The research/coding workflow that I have developed around performing studies really ties in well with a decentralized code versioning system. I’ve also accomplished the goal of creating a new site, actually a new blog, as mentioned in a previous post.

So, after a productive 2011, I have the following goals for 2012:

• Finish analyzing and share the results by end of Q1
• Demonstrate the study prototype in Q1
• Improve the study prototype to handle more sophisticated test scenarios by Q2
• Seek out potential collaborators throughout 2012

Looking forward to a great year!

I’m glad to report that I have very preliminary results from my planned studies. Unfortunately, the tests do not involve the NPX/IPP prototype system yet, so I’m holding off giving more details until the end of Q4. Besides, I’ve had to correct serious code error every day this last week — no need to announce unvalidated observations so far.

Still, getting to this point is really encouraging. After holding off for more than a year to get started on this next phase of the project, and after many doubts on when I’ll be able to return to this project in light of my other commitments, I’m relieved to see that the wait has been worth it.

There are also other self-imposed drivers to get results by the end of the year, so I’m highly motivated right now to just get things done. Expect more detailed updates before Thanksgiving (hopefully).

In the last month, I have been able to slowly ramp up the coding effort to about 8-15 hours a week. The rudimentary code is still exploratory, but I’m optimistic that it’s headed towards the right direction. I’m also relieved to finally be able to rebalance my work/life/personal projects after a very hectic Q1.

So, after some uncertainties in the first half of 2011, I’m looking forward to having a more productive second half. The goal for Q3 is to get actual results to blog about, not just talk about vague, tentative plans like I’ve done for the last nine months or so. The more I read about published research on various computing topics, the more encouraged I get that the approach that I contemplate taking is bound to be a worthwhile adventure.

There really is not a lot to update for the first quarter of 2011, at least not in the form of code and documentation. However, I could easily account for 15 hours a week in March spent on related research activities, which include reading, conceptualizing, and setting strategies. I have read, for example, a few of the latest IJCCR articles. Another web site that I have been reading lately is matslat’s blog. A consistently excellent resource is the Communications of the ACM, which even has an article on virtual goods and currencies in the April issue.

Why bother with ‘conceptualizing’? Mainly to avoid making contradictory or confusing statements. An example would be in this cc typology article, which is an otherwise well-written paper. Blanc’s description of first generation of CC schemes contains the oft-repeated “money is created (at) the very time of exchange.” I have written a while back that this description is misleading when there are debit limits involved in mutual-credit system. As soon as some kind of issuance or trading limit is imposed by a system administrator, the money (as limits) is only exchanged, and NOT created, at the time of transactions. Misleading notions should be carefully filtered out to clarify one what is doing and see where the pitfalls lay.

What about strategies? To use an analogy, strategies are not as crucial in a 100m dash as they are in long distance races. Working on nontraditional currency designs is like a marathon, a long term endeavor where the goals are not clearly in sight and various paths, some untried, are open for exploration. I have long ago shed any misconception that I could code an idea quickly and hope for spontaneous transmission (’viral’ is another oft-repeated but misleading description thrown around by enthusiasts.) The work requires commitment and endurance, luck and inspiration. It certainly helps to be in a community of similarly-minded advocates, but shared interest is actually less important to me than having a shared notion of what constitutes quality effort.

I have noticed that, lately, my posts regarding implementation plans are becoming more vague. The main reason for vagueness is to minimize the need for explaining changes in strategy, which — readers of this blog should know — happen quite often. I prefer to spend my time coding conceptual plans, rather than talking about them. Nothing communicates the current approach or preferred path better than demonstration of working code.

Still, there is value in sharing general plans, concrete experiences and practical lessons learned. Here are related updates:

Q3:

As I mentioned in a previous post, I am really proud of how the NPX system and mobile-inspired UI came together. I have decided to not announce this development in other forums because I predict eventual loss of interest similar to what happened when I announced Prowl early last year. If I do not provide working prototypes of two other major infrastructure components, the enthusiasm would simply wither if there are no sustained means of visualizing ‘what-could-be’.

Two technical features highlight my growing reluctance to give more detailed plans. One of the features involved the use of asymmetric encryption to strengthen non-repudiation. Although blog posts from last year emphasized PKI-type verification, the plan changed early this year based upon farther reflection on OpenTransact’s approach, which is to leave payment verification details to OAuth specs. That approach allows OpenTransact development to proceed faster as an orthogonal concern.

I decided to use a similar approach to speed-up my own development effort for an InterEntity Payment Protocol (IPP). However, instead of tying IPP implementation to a particular verification scheme such as OAuth, it seemed that IPP should be able to accommodate different verification schemes depending on the capabilities and preferences of accounting systems. The end result is that PKI-type verification is just one of two schemes that I have prototyped to work in NP, the other a simpler scheme of querying the accounting system directly through HTTP. Different types of verification schemes could be added and modified later, the important thing is that there is a working payment protocol between independent ledger systems.

The other technical feature example is seller-credential-caching at the user-interface level, like bookmarked information for sending payment at-will to a favorite merchant or charity. Although I was initially excited about this feature, I did not announce it since it might prove to be a not-so important feature eventually. And that was what happened. After spending much time developing code and related icons, I ended up discarding that feature based on usability concerns such as expired credentials, mobile display, etc.

Q4

I am still taking my time with other commitments before going back to coding projects. Although I have been eager to prototype another infrastructure component since the end of last year, I really held back so that I could concentrate my spare time completing the NPX prototype. I realize that I am being vague again regarding the next steps, but I will provide more details based on actual experience and whether or not my conceptualized approach turns out to be feasible. Right now, I am still trying to determine how much time I could realistically devote to the project next year and how to organize my time in order to successfully prototype the other major infrastructure components.

I have finished documenting most of the user how-to and UI code. While writing the server code/API overview, I decided to change the transaction API to make it simpler to follow. I am currently revising my implementation of IPP to use status/error codes and to more clearly highlight important patterns. One more month of tinkering, another month of looking things over, and then the updated accounting system package will (likely) be released by the end of Q3.

Just to be clear: Although there is a lot of ledger admin tools for managing and evaluating a particular currency brand in the current package, it will not include a demonstration of a working currency brand index. That’s the next step after the budget-centric ledger/payment/currency system is prototyped.

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.

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.

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.

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.