The itemized inflow/outflow and online donation links have now been corrected on this site’s ledger page. I must have introduced the form action error after the script had passed multiple tests.
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).
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.
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.