tyaga.org

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.  

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.   

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.

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.  

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.

Since the beginning of the year, I have concentrated on using implementation examples to explain the various components of the satconomy framework. I hoped that through these demonstrations, a more complete picture would emerge in the reader’s mind, showing how the various pieces relate to each other. Of course, the satconomy.org site also discusses the framework’s conceptual bases, but I have always felt that observable practice is always more effective than verbally communicating abstract ideas.

I still feel that way, but at this point, I also see the need to supplement the simple implementation examples with more definite guidelines and specifications. So, I am now in the middle of drafting documents to address this perceived need. Whereas before I thought it would be counter-productive to create specifications that might narrow the appeal of the satconomy framework, I have since realized that there are ways to draft highly flexible guidelines and specifications that broadens the framework’s inclusiveness to diverse technology platforms. I liken this approach to using the minimalist protocols that gave birth to the ‘world wide web’, as explained by Tim Berners-Lee in his book “Weaving The Web”.

The specifications will cover the basic features that must be offered by accounting systems, transaction processing and publishing/reporting mechanisms in order to comply with framework implementation requirements. Using the specification documents and online examples as guidelines, each system component or module could be independently developed on its own. Specifications-compliant components would then be assured of compatibility with each other, facilitating the implementation of a robust system from readily available applications.

Come to think of it, there are some similarities between this approach of developing independent software components and the establishment of independent currency brands. Both conceptual frameworks encourage independence while offering a way for the independent pieces to work with each other. Software components offer specific services outputs which are used as inputs by other components, which is basically the same concept behind inter-entity market trades. Another similarity is that whereas software development is expected to be self-regulating against open specifications, entity and brand establishment is expected to be self-regulating against public opinion within a satconomy framework. In both cases, it is expected that the transparency and diversity of interacting components or brands will enhance framework adoption and robustness.

The 3Q goals are:

1) Demonstrate a proof-of-concept for the online publishing of interentity currency flow between independent currency brands - It must be noted that although currency flow is currently demonstrated through the online tracking of TDS business and personal transactions, the other party in each of the Q1 and Q2 transactions do not publish its ledger records and those transactions are still backed by ‘cash’. 

Most likely, ledger-based currency inflow to tyaga.org would occur in the form of an online donation. I am also currently working with a nonprofit group, so it is also probable that I might be able to convince them to simply publish the amount of hours that I spent working on their behalf - that amount would be a currency outflow for them and an inflow for tyaga.org. I am also looking forward to finding other market entities that would be willing to accept my currency brand for their products. With this goal, the results not only depend on tyaga.org’s intraentity activities but also on its interaction with other entities. As such, I will begin a simple outreach effort to early adopters of other ledger-based currencies.

2) Continue the development of an online accounting system that satisfies the satconomy framework requirements. The accounting system includes the modules for accounts maintenance, transaction processing and ledger publishing. A recent feature under development is the online donation processing that would include an automated reconciliation routine using the Prowl protocol. For those interested, the details of the satconomy market framework, which guides tyaga.org’s development and implementation activities, are summarized in this document. A brief explanation of the proposed Prowl is also provided in this document.

The Q3 goals will be much simpler than previous seasonal goals, mainly due to the time that I plan to spend on developing a simple blog for a nonprofit. I will also try to post on other topics, news and developments for the remainder of this quarter.

Based on 1Q results and lessons learned, the 2Q Goals were revised:

1) Organizational Meta-Structure: Two loosely connected brands will be assimilated under tyaga.org. The first brand, satconomy.org, will become an independent ‘division’ that will continue to focus on the principles and requirements for the philosophical practice of the satconomy market framework. It is important to differentiate the satconomy.org brand with the comprehensive principle called ’satconomy’, just as the brand capitalism.org is different from the concept of capitalism in general.

The commercial activities of the second brand, TDS, will now be tracked for the purpose of showing actual currency flow into and out of the tyaga.org entity. This meta restructuring is necessary in order to align the three brands’ missions toward the same direction and minimize conflicts of interest. This will also simplify the demonstration of the prototype Entity Module, since the current tracking of business activities will provide ongoing information for the effective development and testing of prototype systems.

2) Development Focus: There will be two focus areas for the second quarter:

a) Currency US$:Hour Unit Conversion - A user/reader friendly means for converting the currency inflow and outflow of US$ into tyaga.org hours will be developed. The most likely path would be to create separate tables for each currency unit that is recorded by an entity, in order to easily arrive at the cumulative currency activities separately and maintain the business tracking in conventional currency units that would have to be done anyway. The reader would be able to specify his or her own perceived US$:hr conversion rate, which the web application would then use to calculate and display the inflows and outflows, and credit and debit balances.

This change in approach could be likened to the adoption of a ‘transitional’ versus a ’strict’ system specification. The former encourages existing market entities, such as TDS, to start issuing and accepting alternative currency brands asap even while transacting in conventional currrencies. The latter will provide better future compatibility but perhaps discourage early overall adoption of the satconomy framework.

b) System Configuration for a Sole Proprietor-type Entity - The effort to provide an open-ended, highly configurable system is not a sustainable means for developing and testing prototypes at this stage. This strategical shift drops the current considerations given to enterprise-like systems and reporting mechanisms, for which basic prototypes have already been developed but cannot be fully tested due to the lack of a user base. Instead, the TDS entity will be used as the basis for system development and configuration. This would simplify development since TDS only offers customized report writing and technical documentation service on a contract basis, so there are no inventory tracking issues to worry about. In addition, the accounting method used is cash-based.

With these revised goals, tyaga.org hopes to demonstrate how a market entity might begin transitioning into being able to issue its own currency brand, openly publish its inter-entity transaction books and promote its relevance to market sellers who just might be convinced to accept alternative currency brands.

1Q Results: Two out of three goals were met at the threshhold level: a demonstration page within this site was launched and the source code was made available in the downloads page and in sourceforge. The third goal is probably within reach as there were a few contacts made, although no formal colloborations exists as of yet. I’ll list some of the more important observations and lessons which were used for revising the 2Q Goals.

The demonstration ‘Currency’ page, although functional from the administrative point of view, was found to be giving readers a misleading picture of the actual level of currency activity within tyaga.org. It makes it seem like the quantity of tyaga.org-issued currency, in units of hours, is not changing and that there are no currency inflows and outflows, when in fact there has been ongoing business revenues and expenses as demonstrated by current member tax filings. The main problem is the tracking of currency flow in units of US$ and the lack of a conversion mechanism between that conventional unit and tyaga.org’s currency units of hours. This disconnect will be addressed in 2Q.

The source code, although available in sourceforge and the downloads section, has seen very slight traffic based on online statistics. Maybe it has something to do with my lousy coding style, php’s lack of credibility in some circles, etc., but whatever the reason for the slow adoption by developer enthusiasts, I’m not too worried as I didn’t really know where that was going to lead in the first place. In response to these results, I have limited my development goals to a more specific configuration market for 2Q and beyond.

Finding and developing effective colloborations are very important activities in the future, but it will probably just take time to get there. The lack of immediate success within three months is not alarming, just a helpful nudge to restrict the vision for tyaga.org’s organizational structure.