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.
The year 2010 went by fast. Looking at the three goals for this year, I was only able to accomplish goal #1 which was to code and document a budget-centric system. I was not able to implement even one smaller study (goal #2), although I was able to refine my conceptual approach throughout all of last year. So even though I was not able to work on actual studies, the framework for conducting studies should lead to better implementation and more convincing results. This goal is now 2011:goal #1.
As far as the third goal of recreating a more-user friendly website, I did not make any progress on that at all. It was just really at the bottom of my priority list. This goal will become 2011:goal #2.
After much thought regarding my limitations and abilities, I plan to commit 15 hours a week on currency-related projects this year, starting possibly in March. I am still settling into a new routine, so it is hard to be more definite about this year’s plan. Despite having a good view of long-term goals, I have to be able to fit personal projects around newfound opportunities in order to have a realistic chance of success. I’ll post more informative updates once I get a clearer picture of various responsibilities, schedules, and paths forward.
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:
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.
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.
The much revised accounting system is now available at the “NPX” homepage, or you could go directly to the mobile-user interaction prototype. The corresponding code repositories are accessible at github.
Although I am quite satisfied with the results so far this year, the project is still behind in terms of exploring other areas of study as alluded to in earlier posts. I have been putting off those studies until I get a working prototype of a ledger system that could transact with other ledgers through open payment semantics/protocol.
My plan for the remainder of the year is to establish a more stable work-flow to sustain project development and studies. Basically, I’ll take a step back from actual coding (which I’m not that proficient to begin with) and take care of somethings now in order to be more efficient next year.
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.
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.