tyaga.org

The three main goals for this year are:

1) By spring: Finish coding and doc’ing the updated demonstration of a budget-centric accounting system to serve entities that issue independent currency brands. The transactional back-end is pretty much done, with inclusion of xtype accounts for double-entry of inter-entity transactions and IPP support to facilitate payments across independently administered ledgers and accounting systems. The administrative and user interface should be updated soon.

2) By summer: Conduct smaller studies prior to an actual exploratory study. I’m still working out the details of these intermediate studies, but I’m confident that these low-risk steps will yield useful information for conducting effective studies in the future. 

3) By year’s end: As some of the implementation concepts and strategy take concrete shapes, a more user-friendly website is being planned to offer accessible materials to general audience types. I’m sure most readers are not interested in following the always-changing technical implementation details, and perhaps there are even less who are interested in the philosophies and principles discussed at satconomy.org. At the same time, I am not really looking forward to creating yet another website, so this is lower on my priority list.

Since there are not a lot of development updates for this quarter, I will spend some time looking back at 2009 development ‘highlights’ instead. (The embarrassing fact that these are highlights says something about my odd interests in life.)

While tyaga.org’s philosophical foundations have remained stable and consistent (see satconomy.org), the technical details of the implementation have not always been easy to follow. There really is a lot of art involved in system design, even in an ‘objective’ technical field such as information systems. On a more encouraging note, the accounting system, which was called Entity Module in early 2008, has really become more stable this year. The code is much easier to read and the naming conventions have been mapped to the revised ocaup terminology. The seemingly unnecessary effort to implement transaction recovery outside of built-in database functionality is also paying off, especially as the protocol emphasis shifts towards allowing long-duration web-service type transactions. I still have not released the revised code pending the addition of other functionalities, primarily held up by the issues discussed next.

The effort to build on top of the Prowl demo was, to put it mildly, not very successful. In hindsight, it is easy to see that by using the publication of records as a form of ‘instantaneous reporting’ at the time of transaction, the payment messaging requirements had become too tightly coupled with reporting requirements. To drastically lessen this dependency, I am currently investigating a different approach that should be better in many ways than PaCT. In general, the same conceptual ‘parts’ are used but re-arranged for better modular ‘fit’ and orthogonal development. I expect this new approach, tentatively called Inter-entity Payment Protocol (IPP), to be demonstration-ready by early next year.

Finally, there have been brief but encouraging discussions with other currency design enthusiasts. The potential for collaborations is definitely brewing, but there has to be a good, even if not exact, matching interests on the importance of representing market entities in a currency brand index. More often than not, other projects emphasize visualizing individual contributions and personal reputation metrics, while the emphasis in this site has always been on enabling performance evaluations of specialized organizations that provide products and services to the market. In other words, tyaga.org’s information system design focus is on auditable budgets and inter-entity transactions between organizations, NOT internal transactions between members of the same organization or barter community.

That is pretty much 2009 in a nutshell. I will outline general projects ideas and work plans for the year 2010.

For the rest of the year, I will investigate a substantially different approach to PaCT. I have learned important lessons while working on Prowl and PaCT this year, which has prompted a series of changes since early this summer.

The main lesson has to do with the importance of non-repudiation in a payment protocol such as PaCT. I have been trying to avoid designing PaCT around asymmetric encryption, with the idea that anything involving public key distribution, verification and revocation would lead to too much system complexity. Unfortunately, the ‘independent-witness-on-demand’ idea produces its own set of complexities while not giving as strong a sense of non-repudiation as a digital signature from each entity. In addition, it is more appropriate to move the concern of transparency to the separate stage of periodic report publication and audits.

I plan to revise code and documentation to reflect a refined strategy to be built around a core manifest or declaration document. Each entity with its own currency brand publishes a url to its manifest. The manifest will contain three main elements: certificate, accountant and report.

• Certificate element: describes an entity’s public key and a list of certificate urls (x.509, pgp or some other format) for verification purposes. As with any pki or web of trust schemes, a seller must trust the issuer or endorser of the certificate and support the representation format used.
• Accountant element: describes an entity assigned url for submitting transaction records. A designated accountant will be able to produce or verify digital signatures on an entity’s behalf. There may be a list of urls when different accountants are used for different currency units and transaction processing protocols.
• Report element: describes the corresponding urls to a list of audited and pending reports. Child elements will include transaction period, currency unit, auditor, content-type, etc.

More details to follow in upcoming posts.

For Q2, I finished working on several documents as planned. The OCAUP document has been revised, and there are now more detailed presentations of the IS Plan and PaCT. The recent study plan outline rounds out the suite of documents that outline tyaga’s approach from core principles to initial packaging strategy.

For Q3, I will continue updating an accounting system to support the updated OCAUP model and PaCT payments. The Prowl protocol document will be overhauled to more fully explain the domain-as-currency-brand approach, the need for a simple payment witnessing protocol such as PaCT and reporting requirements regardless of the representation or content-type used (html, xml, json, etc.).

Hopefully, there will be packaged information systems ready for use in exploratory studies starting next year. To find out more, please read the study plan and a related post about currency indexes.

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.