tyaga.org

Here are the Q2 results.

1) Brand Restructuring - The year-to-date TDS transaction information has been migrated in order to demonstrate ongoing currency activity tracking. See http://tyaga.org/ledger.php for more details. 

2) a) US$:hour conversion - I started working on this only to pull back as soon as I realized that it’ll be more likely to confuse than aid in the evaluation of market performance. I might still publish transacted amounts in other currency units in cases where the other entity uses different units to publish its transactions with TDS or tyaga.org. Instead of working on the US$:hour conversion, some time was instead spent on developing an online donation system, for those who would like to use alternative currency brands to support tyaga.org. See http://tyaga.org/donate.php for details.

b) Sole Proprietorship Accounting System - I have succesfully modified the code to tailor it for use by sole proprietors, using object-oriented approach and slightly more optimized database table structure. The user interface, however, is still very rudimentary. This will be a work in progress as further refinements are incorporated in an alpha version.

Q3 Goals will be posted in about a week.

I have started migrating the new database format, ledger entries and object-oriented web app this past weekend. I will be providing a summary of 2Q results this coming weekend. By next week, the ledger should be publicly auditable by anyone through the internet. I’m also hoping, soon, to be able to demonstrate tyaga.org’s market performance using metrics that fluctuates according to its currency brand activity, based on actual transactions conducted through TDS and other means of recovering credits. More updates later.

My on-loan laptop is currently being serviced by my client company, so I’ve had a few days of downtime to work on my 2Q goals. I am currently working on a short document to capture and explain the most important concepts that I have been implementing. In the past and similar to other alt/cc/open currency advocates, I’ve tended to waste too many words on answering theoretical questions, such as ‘why work on alternative currency brands’. This tendency, coupled with little practical implementation experience, has resulted in barely readable text that hardly offers any new insights. With the benefit of hindsight, I am more optimistic that this latest written endeavor will result in a much more concise and highly informative document. In particular, I’m consciously trying to outline the assumptions behind the conceptual models and implementation strategies.

As far as web app development, I have a class for each type of ledger transaction record - currency creation, assignment and use. A bit more testing, and everything is ready to go as as a custom application. For 3Q, I’m already planning on tidying up the web interface for a more satisying user experience.

Just a quick update - I have been able to recode the transactions using an object-oriented approach. I’m still testing the accounting module, but there has been some delay since my power supply and p4 motherboard got fried last week. (I have to remember to vacuum behind my desk where the tower case sits…) So I ended up completing an upgrade of the mobo, ps and cpu, plus recovering the data.

I feel that I am still on schedule to meet the modest goals that I have set for this quarter. I’m just trying to pull back and relax when I can, especially after the unexpected computer upgrade and start of summer coursework. I have been casually reading a lot about Git, and the idea of distributed repositories is really appealing. I am thinking of ways to incorporate the use of such repositories for my work as a technical writer, but I’ll wait until after this quarter before exploring other development projects.

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.

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.

The main development focus at this point is on being able to demonstrate prototypes or proof-of-concept systems. The Entity Module as a prototype was not designed as a production-scale currency tracking system for a huge multi-national corporate entity, but it should work fine as a lightweight demonstration system. The same approach is being used in the development of the Reporter Module.

Right now, the preferred mechanism for reporting inter-entity currency activity has shifted to a ‘pulled’ report. That is, in contrast to an entity registering with a Reporter site in order to ‘push’ or publish its inter-entity transactions, an entity would instead grant a Reporter site access to its publishable transaction information. The Reporter site would then periodically visit member entity sites and other Reporter sites for transaction updates, similar to a feed system. The transaction records in each update feed would then be automatically reconciled with the reports coming from other entities - a reported credit inflow by one entity should have a matching credit outflow report by another entity. Once such a match is found, a Reporter site could periodically publish verified transaction summaries for its member entities. It is important to note that in this prototype system under development, the Reporter site is merely a passive medium that the public could use to examine the veracity of published inter-entity transaction data. In this system, each entity maintains its brand independence; members of an entity do not need the participation of other entities to issue, assign and use their currency brand.