tyaga.org

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.

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.  

I have revised the hastily drafted game-design representation of tyaga’s goals. In reviewing the simplified “game rules”, I was reminded of the standards that underlie the success of the World Wide Web. The web standards, listed in order of importance by Tim Berners-Lee, include the URI, HTTP and HTML. In other words, the Web is primarily defined by the use of URIs, a standard that is easily taken for granted while HTTP and HTML receive more attention.

It was also no accident that URIs use the Domain Naming System, which was designed to be globally scalable and was already widely supported. For the same reasons, Prowl also specifies the use of domain names to simplify the implementation of the similarly crucial concept of Independent Currency Brands (ICBs). The use of separate registries would have added unnecessary complexity and led to collisions as more market entities establish independent currency brands.  

After the concept of ICB, the second-most important design aspect in Prowl relates to accounting models. Just as web and gopher clients offered interoperability in each other’s early protocol versions, Prowl is also designed to understand different market transaction requirements and effects on account balances. For example, would transactors have to be members of the same community to transact (mutual-credit, cc model)? Would the ‘buyer’ accrue debt which would have to be settled later (lender-borrower model)? By default, Prowl reporters are expected to support the cross-verification of OCAUP-based transactions, where the buyer entity’s unused expense and seller entity’s unused revenue budgets decrease by the same amount. The default notary support for OCAUP is similar to the default support for HTTP in web browsers.

The third-most important design aspect in Prowl relates to the representation of transaction information. Prowl specifies default published record syntax, report structure and query-response conventions. However, Prowl should support other representations as they emerge. As inter-regional trade in ledger-based currency grows, Prowl would need to support currency activity representations in different dialects. 

The game-design representation also shows tyaga’s infrastructure building blocks as a list of ‘game equipment’. Through Prowl standards and PaCT payment sequence, establishing and using independent currency brands should become simpler and more fun. 

In an effort to facilitate the discussion of open money standards, I have created two diagrams that others might find useful, proposed architecture and prowl vs. twollar layers.

If you have questions or strong opinions about the proposed architecture and comparison diagrams, please join the discussion at http://groups.google.com/group/prowl-users?hl=en. Just recently in that forum, I have tried to discuss some details of the Prowl design that concerns potential collaboration areas with other currency projects.

I have tried to catch up with some Prowl related updates, most of which have been in places other than the discussion group. So I just took the liberty of copying and pasting excerpts to help consolidate previously scattered discussions in one place. I also included some email excerpts that I thought might be interesting to others. Please feel free to ask questions or post comments that will help clarify not just Prowl, but the whole currency design.

I have to admit that I was surprised to find, in another site, the same core ideas expressed in here and satconomy.org — traceability, accountability, transparency, auditability, even certain implementation aspects, repeated within the same context albeit in fancier words. The surprise mostly came with disappointment that while there was some mention of Twollars as an inspiration, apparently Prowl’s earlier announced release and demo failed to spark the same insights that I have been expounding and struggling to embody for a long time now.

But I’ll remain committed to openly discussing updates, example codes and potential strategies, which others are encouraged to build upon or tweak as necessary. There are many opportunities to develop your own designs on the evolving Prowl-like currency services that are sure to come within this year. I would especially like to see designs that cater to unsophisticated user groups - that’s a key aspect that people often forget.

Would it be possible to reconcile the fundamental differences between the following two approaches:

“Currency designed for transactions between members of independent entities or brands”

and

“Currency designed for transactions between members of the same entity or community”

My doubts have resurfaced after reading some recent online discussions related to currency information systems. At issue is the importance of interoperability between different currency entities as supported by adhoc service providers.

With community-oriented currencies,  the expectation is for the majority of transactions to occur between members of the same currency entity, so the administrative system of one currency does not have to worry about understanding information from another currency system. This obviously has the advantage of freeing each currency issuer to configure their currency and transaction grammar as needed, without worrying about what other issuers are doing.

In contrast, tyaga.org expects that separation of concerns and scalability would inevitably lead to a majority of transactions occuring between members of different currency entities. Where each entity specializes in serving a particular market need, access to product diversity is only possible through interentity trades. Each entity could still configure currency settings and use proprietary messaging/record formats. However, the need for publishing and reporting conventions is going to be unavoidable under a scenario of global interentity transactions.

It was interoperability concerns that led to the development of Prowl as a potential starting point for discussing uniform representation and standardized accounting terms, while still allowing for variations in parameters and calculation specifications. Without interoperability, it would not be possible to achieve traceable and auditable currency brands.  

Prowl was designed to take advantage of existing web conventions and to minimize the need for a common “boundary” or technology between transactors. That is, market participants do not have to be members of the same community or to pre-approve a credit limit towards other participants in order to complete a transaction. Also, transactors do not have to use the same software application or type of transaction device. 

The goal is to minimize the hassle of using ledger-based currencies, and ubiquitous web publishing is the most practical approach towards that end. Essentially, a URL domain name becomes synonymous with an independent currency issuer — an entity that publishes its willingness to bypass traditional currencies when transacting. The publication of such intention and the auditability of its fulfillment is important to the sustainable spread of ledger-based currency systems.

Some might be wary of losing privacy when using Prowl, but a URL domain name does not have to reveal anything about a specific market participant. In fact, recorded URLs domains do not even have to identify transactor account numbers - what matters is that matching copies of the same record are published, not the level of detail indicated in the transactor URL domain name. 

Another concern is the accumulation and maintenance of records. Prowl does not assume permanent record retention, but instead has a mechanism for auditing parameter values that are carried over from one period to the next. Published records are expected to be purged periodically, and reports may have to be kept based on applicable customs for retaining account books. Publishing reconcilable records and reports is simply a means toward building auditable market history and reputation.

The search-assist string is shown as a link on the sidebar. This post was created so that the link would have something to point to. The search-assist string could also be declared as a meta-data or as a hidden text input, if a user has that level of control, as long as the string is visible from the home page source code.

2009-01-04 set tyaga.org reporter.hour to tyaga.org.

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.