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!

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.

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:

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.

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 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.

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.

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.

For the rest of the year, I will investigate a substantially different approach to PaCT. I have learned important lessons while working on Prowl and PaCT this year, which has prompted a series of changes since early this summer.

The main lesson has to do with the importance of non-repudiation in a payment protocol such as PaCT. I have been trying to avoid designing PaCT around asymmetric encryption, with the idea that anything involving public key distribution, verification and revocation would lead to too much system complexity. Unfortunately, the ‘independent-witness-on-demand’ idea produces its own set of complexities while not giving as strong a sense of non-repudiation as a digital signature from each entity. In addition, it is more appropriate to move the concern of transparency to the separate stage of periodic report publication and audits.

I plan to revise code and documentation to reflect a refined strategy to be built around a core manifest or declaration document. Each entity with its own currency brand publishes a url to its manifest. The manifest will contain three main elements: certificate, accountant and report.

• Certificate element: describes an entity’s public key and a list of certificate urls (x.509, pgp or some other format) for verification purposes. As with any pki or web of trust schemes, a seller must trust the issuer or endorser of the certificate and support the representation format used.
• Accountant element: describes an entity assigned url for submitting transaction records. A designated accountant will be able to produce or verify digital signatures on an entity’s behalf. There may be a list of urls when different accountants are used for different currency units and transaction processing protocols.
• Report element: describes the corresponding urls to a list of audited and pending reports. Child elements will include transaction period, currency unit, auditor, content-type, etc.

More details to follow in upcoming posts.

For Q2, I finished working on several documents as planned. The OCAUP document has been revised, and there are now more detailed presentations of the IS Plan and PaCT. The recent study plan outline rounds out the suite of documents that outline tyaga’s approach from core principles to initial packaging strategy.

For Q3, I will continue updating an accounting system to support the updated OCAUP model and PaCT payments. The Prowl protocol document will be overhauled to more fully explain the domain-as-currency-brand approach, the need for a simple payment witnessing protocol such as PaCT and reporting requirements regardless of the representation or content-type used (html, xml, json, etc.).

Hopefully, there will be packaged information systems ready for use in exploratory studies starting next year. To find out more, please read the study plan and a related post about currency indexes.