tyaga.org

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.

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. 

As was planned for this quarter, I have finished updates of key reference documents. The most satisfying updates were the ones for the Trusteeship-Oriented Currency Design slide presentation — adding links to the project’s Demo pipeline items just shows that persistence pays off, even if the some of the demo are still clunky. Luckily, more experienced coders are starting to arrive at the general design strategies that were employed in the demo and explained in posts and documents (see Prowl-Users forum).

I was not as productive towards other goals, but I really needed some time off from the project. I am also starting to reexamine my role in this endeavor. I taught myself to program so that I could prototype and demonstrate my currency design ideas, but recent events may require me to develop and focus on other skills elsewhere.

Before proceeding with publishing revised code, I’m hoping to clean up and reorganize the site this quarter. This will involve not only archiving older documents, code and posts, but also developing a strategy for building a repository of loosely-coupled, service-oriented components.

While I have looked into and could have tried various packaged web-application frameworks, I have not really been keen on features that mostly hide HTML and SQL coding to reduce programming at the expense of future flexibility and interoperability. For example, if I wanted to borrow or share components with others, I would prefer not being forced to install a whole framework package in order to do so. In other words, I would like to be able to cherry pick those tools that do not embed customized nomenclature and method calls in a project’s source code.

I will try to implement orthogonal design principles this year. I found good articles that reflect my preferred approach in articles from infoQ, dsonline, and artima.

I am about halfway through coding a common parser for the witness, audit and evaluator functions. This should make it easier to accomodate future changes to the record syntax and report structure. For example, it might be simpler to change the Accounting Model field into a Account Type field, which might imply breaking reports into separate accounts in cases where separate unused  budgets are tracked. The only downside is that an evaluator feature would have to do more work in pulling different types of accounts when calculating metrics such as inflow/outflow ratios.

A heavily revised Prowl protocol is now available for demonstration.  An announcement is available at a prowl-users group, which was set up to encourage discussions on publisher and reporter standards that different currency platform applications could support. It is hoped that different accounting models, with specifications on what parameters to track and metrics to calculate, will be developed and supported by Prowl reporter applications.

Please find time to try the demo and send in your comments.

While I would rather work on the development of the Prowl protocol, I have other more pressing deadlines at the moment that I need to focus on. I will resume work on the Prowl syntax and yet-to-released demonstration by next week.

The project status so far: I have been trying to simplify the publishing syntax to the most essential form and have running code for reporter functions such as witnessing, auditing and evaluating published transaction records. The remaining work is not so much about polishing, but rather consolidating the different components of the protocol into a coherent presentation.

I am still working on an extensive revision of Prowl. I am quite optimistic about the latest changes, as I’m beginning to see how the use of a publisher-reporter model to coordinate separate development efforts could help encourage collaborations across different currency or payment frameworks. More details to follow in about two weeks.

I have a created a mock-up of an independent currency brand (ICB) index here. The ICB index is a desired end result of the Reporter Module, as far as back-end programming is concerned. This demo is not as interactive as I initially planned, but it should do for now. The fourth quarter is coming up, so I need to review my Q3 results and reprioritize once again. More updates later.