Archive for June, 2009

Alignment of Concerns

Tuesday, June 23rd, 2009

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.

XML/JSON Representation of Prowl Reports

Tuesday, June 9th, 2009

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.