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.
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.
I have to admit that, instead of coding and doc’ing (documenting) indoors, I have been mostly enjoying the long string of sunny days in Seattle. The slowdown was prompted mostly by having a settled mind on the general course of action for this project. In particular, I am planning the information system around exploratory studies, and the earliest study is not likely to occur before the middle of next year. So while the expectations and excitement remains, the timeline for implementing currency ideas is not nearly as pressing as other project priorities this year.
In the meantime, besides sporadically working on the development of currency system tools, I will spend more time exploring the nuances and likely concerns in a trusteeship-based economy. For starters, I have written about addressing potential issues involving durable goods transactions. These analyses will likely come in handy when confronted with valid concerns and skeptical participants.
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.).
The accounting system demo is still being coded and tested, but is near completion. OCAUP support will ensure reconcilablity between periodic currency activity tallies and unused budget balances. PaCT support will include triggering the publication of transaction record and notification of reporters to cross-verify published transactions. The accounting sytem will also support voiding a published record that has not been cross-verified yet, but there are still some transaction sequence details to be worked out.
Based on the results of recent efforts, PaCT is evolving to look more like the ‘HTTP ‘ of Prowl. It used to be that ‘witnessing’ or ‘notarizing’ was just another reporter feature, but PaCT’s importance is really based on its potential to facilitate the everyday use of independent currency brands. Essentially, PaCT is a generic payment protocol for witnessing published transactions, in contrast to the more common approach that uses intermediaries or settlement agents through which payments are routed.
I have been holding off on working on Prowl’s report structures and details, but as mentioned in the previous post, different representations will be supported. One idea is for the accounting system to generate a report, copies of which will be audited and kept by independent audit service providers, and the URI locations of various audited copies will be tracked by a reporter in a document format similar to Git’s parent tree listing. This plan will farther simplify the role of a basic reporter (the one declared in a currency brand/domain’s home page) to letting indexers and evaluators choose the location from which to pull reports. But this is still only a tentative plan.
Many of the development work, planned changes and protocol revision will likely continue to Q3.
In the current effort to prototype an accounting system with OCAUP and Prowl support, I have had to re-evaluate the expected capabilites of reporter service providers. It seems appropriate to drop the expectation for reporters to parse published feeds or email for unmarked transaction records. Instead, an accounting system should be responsible for parsing record submissions through feeds, emails or http. The accounting system should then submit properly marked-up records to a reporter application.
This change implies that the earlier Blogger demo, which triggers a reporter ‘observer’ service through notification email, would not be supported by future Prowl versions. On the plus-side, Prowl reporters would become simpler and more flexible, especially in being able to accomodate different conventions, such as XML or JSON, when posting verified records into a report structure. Standard parsers for those report representations would make it easier to code auditor and evaluator features into reporter applications.
It is important to note that changes to query and report structures does not impact Prowl’s record publication syntax. A publishing platform such as Blogger would still be expected to publish records in a ‘canonical format’, which would simplify the cross-verification of matching copies from transactor domains.