tyaga.org

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 just uploaded a heavily revised OCAUP document. The latest revision includes simple tables and attached illustrations. The main difficulty has been, and continues to be, finding appropriate terminology that adheres to common accounting language while purposely avoiding terms that might cause confusion with conventional interpretations.

At the moment, the most suitable terminology relates to ”budgets”. Ledger-based currency may be viewed as unused entity budgets that are periodically planned and dynamically reported as inter-entity transactions occur. OCAUP may be used to model and track how well an entity regulates against its self-determined limits. Entities that demonstrate effective self-regulation develop reputable currency brands, which should translate to better market access.  

The illustrated OCAUP currency activity and journal entry examples should help explain the “scoring rules/system” that tyaga is trying to establish. Speaking of scoring rules, I also drafted a game-design representation of tyaga’s information systems goals. The OCAUP document also has an attached table that compares mutual-credit accounting systems with OCAUP-based designs.

I have revised tyaga.org’s mission to be more concise and clear - please visit the About page for a quick look. I realize that not everyone agrees 100% with the scope of work or strategies that are outlined in this site. For those who agree with the practical aspects of Tyaga’s IS Plan, feel free to use any idea or code that you find useful. I am also very open to collaborating with those who appreciate tyaga.org’s envisioned goal, path and tools. 

Even for those who take exception to tyaga’s approach, there might be room for common lines of actions if only we stay open-minded, as discussed in a related post. I am more than willing to change tyaga’s direction based on evidence gleaned from practical experience. At this point, there is little in the way of actionable results from other projects that would justify a revision of the Tyaga IS Plan.  

The following documents are now available to help explain the Tyaga IS Plan:

• An Open Infrastructure for Adaptive Currency Information Systems: This browser-enabled slide presentation explains Tyaga’s approach to separation of concerns, with links to related demonstrations.
• Published and Cross-Verified Transaction (PaCT) Sequences: These transaction sequence examples illustrate the type of system interoperability that would be essential to the widespread use of ledger-based currencies.  

In addition, there is now a packaged version of software code, tentatively named Kit, available for download. Kit is a revised version of an earlier Prowl reporter implementation for the Apache/MySQL/PHP platform. The packaged files are also browser-viewable - please browse the filenames for methods and code snippets that might interest you (such as parser.php and the svg-graphing functions.)  The Kit 0.2 package is not refined by any means, but it offers basic reporter functionalities.

I will begin writing use cases to illustrate independent currency brand support through the OCAUP accounting model. I’m also hoping to package an acounting system that I developed from last year in order to demonstrate not only OCAUP, but also built-in support for a protocol such as Prowl. 

After debating whether to move forward by coding a market implementation package or documenting the IS Plan more throughly, I have decided to allocate more time on the latter. I intend to finish drafting additional pending documents for Q2 2009, and to move to market implementation packaging for the second half of this year.

While I feel that practical demonstrations are always more convincing and more easily grasped than written plans, there is a clear need to explain the ‘tyaga’ approach to currency design that lists information system functional requirements and shows the strategy for the separation of concerns. This need became more apparent after I drafted the prowl_layers diagram. Even though there are now more systems that use the publication-oriented approach, tyaga’s IS Plan seems to be unique in positioning the accounting system as a layer that feeds the publisher platform, rather than the other way around as illustrated in the prowl_vs_twollars diagram. I hope to explain the rationale behind this design consideration in the planned document drafts for this quarter.

For now, I will simply note that responsible market entities typically maintain independent accounting systems and ledgers. It would be easier to ask each entity to build on top of what it already uses, to independently declare its own budgets and to self-regulate against those budgets — the only additional effort will be to publish market objectives, periodic tallies and flow records in conventional formats in order to promote accountability and auditability.  In contrast, I am skeptical of the perceived benefits/costs in putting the accounting system and transaction control as a layer above the publisher platform.   

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.

As was planned for this quarter, I have finished updates of key reference documents. The most satisfying updates were the ones for the Trusteeship-Oriented Currency Design slide presentation — adding links to the project’s Demo pipeline items just shows that persistence pays off, even if the some of the demo are still clunky. Luckily, more experienced coders are starting to arrive at the general design strategies that were employed in the demo and explained in posts and documents (see Prowl-Users forum).

I was not as productive towards other goals, but I really needed some time off from the project. I am also starting to reexamine my role in this endeavor. I taught myself to program so that I could prototype and demonstrate my currency design ideas, but recent events may require me to develop and focus on other skills elsewhere.

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.

In light of recent developments in currency design, such as the tentative announcement today at the NCF blog, I have decided to publish an early draft of a paper that I have been working on. I am glad to see an increase in activity that shares more or less a similar design philosophy behind the Prowl demonstration.

Please post or send in your comments, questions suggestions and/or objections that could help improve the paper.

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.