tyaga.org

I have to admit that, instead of coding and doc’ing (documenting) indoors, I have been mostly enjoying the long string of sunny days in Seattle. The slowdown was prompted mostly by having a settled mind on the general course of action for this project. In particular, I am planning the information system around exploratory studies, and the earliest study is not likely to occur before the middle of next year. So while the expectations and excitement remains, the timeline for implementing currency ideas is not nearly as pressing as other project priorities this year.

In the meantime, besides sporadically working on the development of currency system tools, I will spend more time exploring the nuances and likely concerns in a trusteeship-based economy. For starters, I have written about addressing potential issues involving durable goods transactions. These analyses will likely come in handy when confronted with valid concerns and skeptical participants.

A series of flowcharts is now available to guide the development and coding of PaCT applications. The flowcharts illustrate the steps that a reporter application takes to cross-verify and witness a published transaction record.

Automated auditing applications could then query reporter applications to ascertain that published reports contain cross-verified transactions. In this way, greater confidence could be built into information summaries as provided by currency brand indexes.

Recently, while researching reputation attacks that could threaten currency brand indexes, I happened across another perspective that I feel compelled to study and learn. 

Nowak and Sigmund’s article in Nature magazine discusses the evolution of indirect reciprocity in the context of hunter/gatherer populations. An idea that immediately comes to mind is that currency is an attempt to externalize image scores. Others have also realized that connection, and besides another blog, there is even a published article on money as externalization of confidence (unfortunately for me, I do not read Japanese).

In hindsight, I could see how Prowl is just another attempt to scale indirect reciprocity by tracing reputation to a market entity’s domain name, exposing helper-recipient interactions to declared and random observers through PaCT, and promoting auditable reputations through parsable reports. The extended sequence of PaCT even illustrates how a reporter may query for advisories on whether to accept or reject a transaction opportunity, which is analogous to the decision to help others or not. It should not matter whether a transaction is called a sale, charity or paid service — the recipient (e.g., buyer) still receives a benefit and the originator (e.g., seller or donor) still accrues the cost in hopes of improving her long-term fitness (through redeemable reputation tokens or supporting others who make life better, more satisfying.)

Reading through research and literature published on the evolution of cooperation, it’s amazing to see theories and scoring strategies objectively compared using accepted frameworks for modeling, simulation and experimental studies. I see the concept of scoring strategies (image scoring, standing, etc.) as analogous to currency design. Good currency designs, like good scoring strategies, are more likely to persist in simulations and actual implementations. 

My take-away lesson from evolutionary game theory is that overall fitness determines selection, and not the amount of tokens or currency that is owned by an individual. That perspective runs contrary to most economic game theory that uses the accumulation of money as the quantitative measure of success. Evolutionary selection by accrued fitness seems more natural. I was inspired enough to create a basic simulation program for modeling the spread of benefits/costs in a population that uses a particular currency design. However, I am still unsure of how to model selection in a saturated market population. I don’t think evolutionary selection is representative of the situation wherein market participants are cognizant of various currency designs that they would like to earn and use.  

For Q2, I finished working on several documents as planned. The OCAUP document has been revised, and there are now more detailed presentations of the IS Plan and PaCT. The recent study plan outline rounds out the suite of documents that outline tyaga’s approach from core principles to initial packaging strategy.

For Q3, I will continue updating an accounting system to support the updated OCAUP model and PaCT payments. The Prowl protocol document will be overhauled to more fully explain the domain-as-currency-brand approach, the need for a simple payment witnessing protocol such as PaCT and reporting requirements regardless of the representation or content-type used (html, xml, json, etc.).

Hopefully, there will be packaged information systems ready for use in exploratory studies starting next year. To find out more, please read the study plan and a related post about currency indexes.

I have recently come across Postel’s Law, which is typically quoted as: “Be conservative in what you do; be liberal in what you accept from others.”

This is also known as the Robustness Principle. It reflects tyaga’s vision of how independent currency brands should operate and interact: “Be strict in setting your own limits and performance, be tolerant in accepting other currency brand’s limits and performance.”

In other words, in order to promote the adoption and spread of independent currency brands, it is important to expect that most entities will likely have poor performance relative to its initial budgets. The important thing is to observe work with dedication and perserverance, and not to expect immediate success. A dynamic index is therefore a means for evaluating the progress of an entity through its currency brand, and not a means for avoiding transactions that could help another entity reach its goals. Something to think about when studying and promoting the use of dynamic indices.

I have taken a short break from coding accounting system and reporter features in order to present a rough vision for implementing the concepts and components that have been described in this site.  In this vision, the information system under development will be packaged for exploratory studies of dynamic currency brand indices.

All of tyaga’s work relates to the development of reliable and compelling currency brand indices. The impact of dynamic indices on the spread of ledger-based currencies will be comparable to the impact of search engines on the usability and growth of the Web. This is an optimistic statement that begs to be tested on empirical grounds. 

Of course, there are different ways to establish currency brand indices. Stephen DeMeulenaere / Strohalm publishes something similar once-a-year for complementary or alternative currencies, but the information is not sufficiently dynamic, and is neither easily auditable nor traceable to economic activities of market entities. When the “tower” analogy was posted in 2007, there were no apparent published efforts that appreciated the importance of this challenge. As a result, tyaga.org was established to actively research and develop strategic approaches for establishing dynamic brand indices. So far, the strategy involves the following concepts and components:

• Prowl’s publisher-reporter emphasis encourages the simultaneous development of multiple index applications.
• PaCT results in instantenously cross-verified and updated transaction information that indices could pull and evaluate
• OCAUP facilitates audits and reconciliation of information in internal ledgers, published reports and indexed evaluation metrics. 
• The concept of independent currency brands (ICB) promotes traceability to and indexing by specialized market entities, instead of communities-members or lenders-borrowers. 
• The IS infrastracture plan and diagram present the conceptual separation of concerns
• The Prism classification convention encourages new perspectives and critiques on currency design

The proposed study plan is one way to test the validity and effectiveness of various design elements, including tyaga’s assumptions made with regards to the design of information system.

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.