tyaga.org

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.

A series of flowcharts is now available to guide the development and coding of PaCT applications. The flowcharts illustrate the steps that a reporter application takes to cross-verify and witness a published transaction record.

Automated auditing applications could then query reporter applications to ascertain that published reports contain cross-verified transactions. In this way, greater confidence could be built into information summaries as provided by currency brand indexes.

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.

I have been updating an earlier version of an accounting system from last year. The upcoming version will have built-in support for Prowl and the ocaup model. The user interface will be SMS, email and HTTP-based. 

Also planned for this quarter, the Prowl report structure will be revised to an HTML rather than plain-text representation, in order to use head-metadata tags for information such as encoding, language and record delimiters. The move to HTML representation is just one of the many changes planned for Prowl version 0.2. 

An aspect of Prowl record publication that was not explained in an earlier post concerns the authentication of transactors. When transactors do not belong to the same currency community, such as in ocaup inter-entity trade, the ability of a transactor to ‘publish’ a record in a certain domain implies membership in that domain, with the domain name being equivalent to the currency brand in Prowl. Thus, the authentication of brand membership is simplified, without requiring a centralized brand-membership registry or intensive authentication schemes. This publish-to-authenticate scheme is incorporated in the various PaCT sequences, which also includes reporter notarization to help deter fraudulent repudiation of published records.  

The following documents are now available to help explain the Tyaga IS Plan:

• An Open Infrastructure for Adaptive Currency Information Systems: This browser-enabled slide presentation explains Tyaga’s approach to separation of concerns, with links to related demonstrations.
• Published and Cross-Verified Transaction (PaCT) Sequences: These transaction sequence examples illustrate the type of system interoperability that would be essential to the widespread use of ledger-based currencies.  

In addition, there is now a packaged version of software code, tentatively named Kit, available for download. Kit is a revised version of an earlier Prowl reporter implementation for the Apache/MySQL/PHP platform. The packaged files are also browser-viewable - please browse the filenames for methods and code snippets that might interest you (such as parser.php and the svg-graphing functions.)  The Kit 0.2 package is not refined by any means, but it offers basic reporter functionalities.

I will begin writing use cases to illustrate independent currency brand support through the OCAUP accounting model. I’m also hoping to package an acounting system that I developed from last year in order to demonstrate not only OCAUP, but also built-in support for a protocol such as Prowl.