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.
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.
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.
I have uploaded a bunch of documents here. I don’t really want to spend too much time polishing the documents, as I am in the middle of developing an interactive demonstration for all the implementation project examples on this site. I have high hopes that the interactive demo, once active, will really clarify how everything fits together in the satconomy framework.
The Prowl implementation example has been revised to comply with the slightly extended version (see Prowl specs in the docs folder.) It shows an example for each of the three query strings that should greatly simplify the automation of inter-entity ledger reconciliation. The source code for the example is also available in the linked page.
Having had the last few months of prototyping experience with the Entity Module, I am almost ready to switch to the development of an alpha version. I have decided to delay the migration of the TDS ledger information until I have revised the MySQL tables to a leaner structure and the php code to an object-oriented approach. It didn’t make sense to migrate data into a prototype system that I will be replacing soon after with a much improved sytem.
The most important update has to do with being able to express, more clearly and with more certainty, what it ‘is’ that I’m trying to develop. In the past, I have tried to explain what I am trying not to do by comparing the prototype systems with the likes of LETS or Ripple. Here, I’ll give a preview of the system and framework that I have in mind as suggested by the title of this post.
Open Web Ledger (OWL) Systems – There is nothing new about implementing a web-based accounting system. However, most of those accounting systems are designed to keep the ledger information strictly for private viewing only. What I was trying to demonstrate with the Entity Module prototype was a ledger system that is open for inspection and auditable by anyone. So far, I have failed to fully demonstrate how this openess was to be achieved, or what ‘open’ means. One of the main reasons for this failure was I didn’t have ongoing ledger data to publish, and that’s why the decision to migrate the TDS ledger information was made. That decision made it easier to move from assumptions to a working model which I feel comfortable with as an actual user/proprietor.
With the still unreleased version being developed, I have been able to come to this definition for openess: a ledger is sufficiently ‘open’ if information about an entity’s currency inflow/outflow is auditable by amount and the transacting entities. It is not necessary to divulge the dates, individual account numbers or receipts that are represented in a ledger entry, as long as the cumulative inflow and outflows between the transacting entities reconcile. Transaction details are only necessary for troubleshooting ledger inconsistencies.
P2P Reconciliation – Suppose Alice uses 100 units of her ABC credits to buy bread from entity XYZ. Entity XYZ then publishes an inflow or revenue of 100 units in its ledger, assuming that ABC and XYZ uses the same currency units. What if Alice was careless or dishonest and reports only 80 units of ABC outflow to XYZ? Or what if XYZ inflates its revenue stream from ABC to 150 units instead of the actual transacted amount of 100 hours?
Of course, a web surfer could easily detect such inconsistencies by visiting each entity’s web ledger, but a manual or user-dependent procedure for ledger audits would be unreliable and impractical at large scale. Ledger inconsistencies could result in the accumulation of errors in account balances which would be difficult to undo if not caught early enough. Gross accounting inaccuracies and misrepresentation eventually result in the loss of market confidence in an entity, such as in the case of Enron. The effect would be magnified for a satconomy entity that relies solely on its currency brand reputation for market access. A majority of sellers could all of a sudden decide not to accept that entity’s curreny brand if it cannot prove how it fulfills its self-declared obligation to the market.
One solution would be to automate the verification of unreconciled web ledger entries between the transacting entities. Such automation would then allow only verified ledger entries to be published and would prevent the accumulation of errors in account balances. I initially wanted to jump straight into prototyping a Reporter Module for this purpose, but platform and security considerations necessitated a more careful analysis. So far, I have a design idea for a peer-to-peer ledger reconciliation framework that could be extended for use in a Reporter Module. The Prowl protocol uses HTTP Get Request and a sha-1 digest of transaction data to perform asychronous reconciliation in the background. Instead of providing more details here, I’ll wait until the alpha version is released this quarter in order to demonstrate the features and functionalities of a Prowl framework.