tyaga.org

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.

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.

I have a design idea for implementing the pulled currency inflow/outflow reports, I just need to formalize it and squeeze some time to work on it. At least one more month is needed, as I am a little bit pressed for time with other things. If anyone would like to help, just email me.

While I’m working on the currency brand reporting mechanism, I’d like to take some time to highlight the efforts of a family that I’ve been following off and on since early 2005.  Started as www.pathtofreedom.com or PTF, I now read their homegrown exploits at http://urbanhomestead.org/journal. Perhaps it might still be too early to expect a ’seedling’ organization to issue its own currency brand, but when that time comes, I could see the Dervaes Institute as a prototype for such independent currency issuing entity. I’ll list the reasons.

1) PTF has a clear, compelling, self-determined mission. PTF’s mission statements and goals provide a clear yardstick for the market to assess its performance.

In a satconomy framework, each currency issuer declares an obligation to provide specialized services/goods to the market, which in PTF’s case includes public outreach and exploration of sustainable solutions (e.g., 10000 lbs of garden produce). All contribution towards the fulfillment of that self-determined obligation is represented by self or entity-issued credits, which brand members could use to purchase the products of other currency issuers and in the process cancel the seller’s self-declated debits. Credits are always issued with an equivalent number of entity-issued debits.

2) PTF is a very transparent organization. Not only does PTF offer a clear yardstick for evaluating its performance against its self-declared goals, PTF also offers the public the ability to closely scrutinize its actual week-to-week performance through regular blog updates.

In satconomy framework, it is not enough for market participants to agree with an entity’s mission and goals - the market must also determine the sustainability of an entity’s market contributions. It is easy to see PTF’s weekly challenges, successes and even the few failures (e.g., failed crops or unproductive yields). The blog updates are comparable to the press releases of a publicly traded, stock-issuing corporation.

3) PTF already offers ways of quantifying the market’s support of its activities. For now, PTF has the ‘grow-the-future’ metric of total donations in its journal site. PTF also measures the ongoing quantity of its produce, by weight, against the target 2008 harvest yield that it has set for itself.

In a more mature implementation of satconomy framework, a currency issuing entity would also provide regular, timely and verifiable updates of its currency activity. This reporting mechanism is what I’m currently trying to prototype.

Whether or not the use of alternative currency mechanism is in PTF’s future, tyaga.org hopes to see it flourish like the lush plants in its urban garden.