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 link to older document versions was inadvertently left unchanged with the latest Prowl announcement. The correct link to the latest Prowl document versions is http://tyaga.org/prowl/documents.php.

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.

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 have been working mostly on the implementation side, so I have been unable to spend time posting here. The good news is that I am getting closer to a usable demonstration system, hopefully to be released in December after I revise the protocols to reflect the extensive architectural changes that I have made. For system development and implementation updates, please visit http://tyaga.org/. What follows below are mostly personal thoughts.

Within this year, I have visited the user demos of cyclos, ripplepay and three alpha-sites of open money systems. I have also read the MRS server-client specification, IRTA, some of the unmoney convergence session notes, as well as the more accounting-oriented approach exemplified in ledgerism.net (now defunct). All of these sites are quite inspiring, and I’ll continue to follow the updates on those projects. I have general observations that I’d like to share.

Why do most ledger-based currency systems focus on monetizing community and personal relationships? I still don’t quite get that angle, and besides IRTA, only ledgerism.net had focused on serving business-type needs and/or settlements. When I think of money or currency, I think of organized work and of regularly earning it, not so much the use of it which would just come naturally in a market, community or personal setting.

Why do most systems focus on tracking account net balance, when ‘cash’ flow budgets seems more appropriate for triggering and regulating market activity? Organized work in business, government and nonprofits are driven mostly by serving specific needs, and is typically regulated against revenue targets and controlling costs. It just seems that a particpant or organization that focuses on breaking even (zero net balance) will not have much incentive to innovate and proactively produce value, to take responsible risks.

Why do developers focus on system configurability instead of simplifying the accounting bases of the system? When reading related discussions on the principle of requisite variety, I find it surprising that the focus is mostly on giving the user a myriad of options in configuring an account, such as the use of obscure units, floating exchange rates and leakage settings, which makes the system more intimidating and the accounting more complicated than necessary for a typical user. I realize most users would forgo such options, but it might make the simple users wonder if they are somehow being put at a disadvantage relative to a more configured account. 

To me, requisite variety should come from having a diversity of specialized organizations that issue its own currency and which could either be rejected or accepted by market participants, similar to companies issuing its own shareholder stocks or bonds and people either buying or avoiding those shares.

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.

The goal for the remainder of this year is to create a functional online transaction mechanism between two independent currency brands. In order to do this, the following implementations must be developed and refined:

1) Reporter Site – Only a demo of intended inter-entity trade results is available so far. The actual Reporter mechanism will be distinguished from a LETS-type or Ripple administrative system as follows:

• A Reporter simply acts as an observer to this event: matching copies of a transaction record have been independently published by both entities involved.
• The Reporter’s recorded observation of that event would be available on-demand and have durability. (This feature should address potential concerns of unreliable record maintenance within each entity.)
• A Reporter does not have any idea of the spending or revenue limits of transacting entities. Those currency limits are independently determined by and within each entity.
• A Reporter’s currency brand limits must not be affected by any transaction that it observes. No payments goes through the Reporter – it simply witnesses that a specific payment has been made between two entities.

 In the past, it was simply assumed that a Reporter would pull batches of published server data on a pre-determined, regular schedule. The goal for this quarter is to prototype a Reporter that could act as an observer on-demand, with copies of a specific transaction record pulled at the instance of being completed and published.

2) Prowl Updates – The Prowl standards will be abstracted even more. The reporting standards will be more generalized in order to accomodate available and future server platforms. The on-demand Reporter must be able to recognize Prowl standards in order to generate its own record of published transactions.

The Q3 results are not exactly inline with my initial goals. I still have not conducted a trade with another independent currency brand (not really surprised), and I am still working on the implementation. The Q3 highlights are:

1) There are now supporting documents of proposed standards, plus slide presentations.

2) A Reporter-ICB Index demo has been created.

I will post my Q4 goals within a week.

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.

I have just uploaded a browser-compatible presentation – The NASDAQ of Independent Currency Brands -using Eric Meyer’s S5 system. I also tried Slidy and DOMslides, but eventually found S5 to be simpler to use. The new presentation has only 18 slides and gives what I think is the best overview so far of the satconomy framework and implementation. Even though there is no audio on the slides, a lot of the bullet points are self-explanatory. So please take a look and enjoy the presentation.