tyaga.org

While I would rather work on the development of the Prowl protocol, I have other more pressing deadlines at the moment that I need to focus on. I will resume work on the Prowl syntax and yet-to-released demonstration by next week.

The project status so far: I have been trying to simplify the publishing syntax to the most essential form and have running code for reporter functions such as witnessing, auditing and evaluating published transaction records. The remaining work is not so much about polishing, but rather consolidating the different components of the protocol into a coherent presentation.

I am still working on an extensive revision of Prowl. I am quite optimistic about the latest changes, as I’m beginning to see how the use of a publisher-reporter model to coordinate separate development efforts could help encourage collaborations across different currency or payment frameworks. More details to follow in about two weeks.

I have uploaded a bunch of documents here. I don’t really want to spend too much time polishing the documents, as I am in the middle of developing an interactive demonstration for all the implementation project examples on this site. I have high hopes that the interactive demo, once active, will really clarify how everything fits together in the satconomy framework.

The Prowl implementation example has been revised to comply with the slightly extended version (see Prowl specs in the docs folder.) It shows an example for each of the three query strings that should greatly simplify the automation of inter-entity ledger reconciliation. The source code for the example is also available in the linked page.

I have updated the ledger based on my recent currency inflow and outflow activity. While I still believe that my live demonstration of an open web ledger is a good start, I just realized that as a contract worker, my revenue stream and expenses occur in spikes, rather as a continous stream. I get a check about once a month, and I also spend in bulk, such as transfers to personal accounts, office puchases and irs estimated taxes. My business activity is not like a store or restaurant that could register highly dynamic inflow or outflow updates to the ledger, so it still looks inactive even with the TDS accounts tracking. I am still learning how to design a more dynamic small-scale implementation example.

The Prowl protocol documentation is coming along; it will be about 6 pages with generous spacing, so nothing overly technical. Just trying to arrive at a web ledger query syntax that is clear and simple to use. I have also modified the basis of the acronym to Pull-Reconciliation of Open Web Ledgers, since the “peer-to-peer” aspect might be confusing under certain interpretations. I originally meant p2p to be non-arbitrated interaction between two ledgers that have interchangeable server-client roles. But “Pull-Reconciliation” is still a more accurate description.

Lastly, I am seriously considering taking a 6-week break from contract work to spend more time on documentation and online examples during 3Q. It has been a struggle to arrive at appropriate language to describe what I am trying to do, but I think I may have found a good model to emulate and use in explanations. More on that when the documents get done.

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.

Peer-to-Peer Pull-Reconciliation of Open Web Ledgers, or Prowl. Prowl is intended to work through HTTP Get using the following query string format to verify a transacted amount:

URL appended by “?(to= or from=entity_id)&digest=unique_transaction_identifier”  The query syntax has been updated into three types: Amount query, Tally query, and Status query - See the Prowl specs in the docs folder

Follow this link to see an example of the web query result and take note of the query string in the address bar: Prowl Example

Four basic features of the Prowl protocol are:

1) Prowl is intended to be independent of the server engine and application module that is used to return the query results. Prowl is a high-level, declarative protocol above the HTTP application layer. As long as a web platform could deliver the requested query result, Prowl does not care whether a windows or linux-based server is used, or whether the data is retrieved from a file-based or relational database system, or whether the application module language used is Perl, PHP, Python, Ruby, etc. The only absolute requirement for an application platform to satisfy the basic Prowl protocol is this: given the above HTTP GET query string, the transacted amount must be automatically retrieved and returned.

2) The Prowl protocol does not care what the requesting IP does with the returned information. Most likely, it would be used in a cron job that automatically initiates the debiting or crediting of internal accounts within the requesting entity’s accounting system. A reader may also use the Prowl query results for manual transaction record processing.

3) The Prowl protocol does not care about how the transaction id is generated, or even if the id uniqueness extends to every conceivable set of recorded market transactions. The only assumed uniqueness requirement is that between two particular entities, the transaction id could distinguish between different transaction instances even if the date, amount and participant account numbers are all the same. Tyaga.org uses a sha-1 digest to uniquely identify individual transactions, but other types of identification might also be generated and used as needed. As a transaction identifier, the sha-1 hash digest of the transaction record offers two advantages: (a) the digest helps maintain account information privacy in a transaction record query, and (b) since a sha-1 digest value is most likely to be unique for a given sequence of data values in a specific transaction record, the digest could also help correct any inconsistency between corresponding interentity records for the same transaction; in such a case, only one version of a transaction record is expected to be digested into a given sha-1 value.

A proposed standard data sequence for the sha-1 hashing is the space separated values for date, instance, amount, from_account, to_account, amount and units. This data sequence may be more easily referred to as the DIFTAU standard.

4) The Prowl query string format may be extended in the future to allow the use of other attribute values. The example above happens to return a transacted amount that is retrieved through a unique identifier and the corresponding transacting entity, with its transaction role already indicated by the choice of the field name (to or from).

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.