Prowl layers/"filter stack"

[els]

****From Miles:

I think you said
3. We should distinguish between three stages
- 1 - information whilst it is being transmitted from end users
to
their 'accounting system' or currency provider
- 2 - information being published by currency providers/
accounting
systems (presumably for open auditing purposes)
- 3 - aggregated data (tallies and such) that might be the
result of
such auditing procedures

...

****

Just to clarify: From my architectural viewpoint, there are really two
stages in your list no. 3 -2-. To help visualize my explanation of
this topic, please see the proposed architecture diagram @
http://tyaga.org/docs/pix/prowl_layers_20090405.jpg.

Please note that there is a potential for misunderstanding that could
arise from the different layering of modules as shown in the diagram @
http://tyaga.org/docs/pix/prowl_vs_twollar_20090405.jpg.



In the prowl_layers diagram, I have indicated the various stages which
require some kind of transaction record representation. I will expand
your list of stages as follows:

-1- information *submitted* from end-users to their *respective*
accounting system or currency provider. (In Prowl, transactors do not
need to share an accounting system or currency provider - the focus is
on enabling inter-entity trade with each entity self-regulating
against its declared limits and independently maintaining its own
accounting system/currency brand.)

-2- information as published by each currency-issuing entity or
currency brand (using a platform such as a blog or Tweeter) and as
verified by a Notary (a service that is currently not provided by
Twollar)

-3- information as posted in an "itemized report" (a service that is
currently provided by Twollar and also demonstrated in tyaga.org).
This is what I meant by aggregated records - perhaps a poor choice of
wording on my part.

-4- information as presented by auditor/evaluator services, such as
audit reports and market performance graphs. As you indicated in your
comments, this information format is more appropriately referred to as
"aggregated data". (This service is within the scope of Prowl but does
not seem to be offered by Twollar.)

-5- information as aggregated in a multicurrency brand index (the end
goal for all these publishing and parsing effort. This is not within
the intended scope of Prowl, although information as generated from
-4- will likely feed or be used by indeces.)


For the "om specs or standards", I was initially thinking we should
concentrate on no. -2-, but I might have to take that suggestion back
since not all systems notarize or cross-verify the publication of
matching record copies between both ends in a transaction or flow
record.

In my opinion, I think a "reporter" or "harvester" application would
be severely handicapped by not offering a Notary service. In fact, I
argue that such applications are more scalable if the main focus is on
offering Notary/Witness/Observer services at the time of publication.
I don't think that focusing on checking available balance, such as
offered by Twollars before processing a published record, would scale
very well.

Essentially, the current Twollars approach of assigning limits and
offering an accounting control service fior its members runs counter
to the goal of encouraging highly transparent, auditable, accountable
entities that each self-regulates against its own self-determined
limits and through its chosen means of independent accounting system.
Even today, businesses and organizations (govs, nonprofits, etc.) are
each expected to determine its own budget and to transparently
regulate itself against those budgets.