tyaga.org

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.  

Not a lot of development updates this time, just some thoughts after taking a break from this project. The recurring question, as always, is how to move forward. The project might be described as attacking a specific problem and a more general problem.

Looking at the specific problem of information system design -  the product view - the strategy has been narrowed down adequately. There will be orthogonal components or modules for:

• Entity or Publisher: currency issuance and accounting controls
• Reporter: currency brand evaluation and monitoring 
• Device: user interface for conducting transactions, most likely to be mobile applications

The Prowl protocol is an attempt to provide the necessary interface between the orthogonal Publisher and Reporter components. The demonstration is admittedly rudimentary, but the overall design principles should be apparent in the demo: Loose coupling, separation of concerns, late binding as to where additional information might be found through the use of the search-assist string.

The general problem of widescale implementation - the market view - gives the context that will guide the production scale design of Prowl-compliant applications. So far, the general problem has been treated lightly while the product design strategy was being worked out. Although effective system design is not trivial, it is obviously more straighforward than the market implementation aspect.

Right now, a multi-stage market study seem to be the best approach for breaking the general problem into more manageable pieces. More updates will follow once I am done drafting the details of the proposed study.