Prowl - for publishing/reporting currency activity

[Edgar]

I'm hoping that the open money platform might consider supporting the Prowl record syntax and report structure to help promote inter-operable currency systems. Although the Prowl demo version only supports conventional DNS mapping, openmoney namespace querying/addressing could be coded (perhaps the query syntax and registry is available now? And I'm still not sure why open money should have its own namespace mapping/resolution - wouldn't simply using regular domain names be simpler?)


PROWL

Prowl is a short-hand term for Publisher-Reporter Oriented Web Ledgers. The aim of the project is to enable existing web publishing platforms to support different currency or payment frameworks through the specification of community, lending or brand-oriented accounting models.


Why Publish?
The idea is to popularize different means of assigning value to economic activities that are marginalized in traditional, centralized currency frameworks. Public awareness and appreciation of such activity is expected to grow with each record that is published and accounted in community, brand or lender currency. Over time, it is hoped that a diversity of viable, ledger-based currencies will emerge to help regulate economic stability and improve market accessibility.


How to Publish?
Prowl seeks to standardize published record syntax, report structure and accounting semantics to enable different reporter applications to reproducibly verify, audit and evaluate reports according to standard conventions and accounting model specifications. This type of inter-operability is similar to how different web browsers are able to access and render HTML pages according to standard content types and mark-up. Through web-accessible and mobile-compatible reporter services, Prowl should not require new software installation or dedicated transaction devices. End-users could simply use existing publishing platforms, such as freely-hosted blogs, and mobile devices to publish records and access report data.


Try It
Please try the demonstration at http://tyaga.org/prowl/reporter_services.php and post comments at http://groups.google.com/group/prowl-users. If you’d like to register your blog or domain as a test publisher site, please announce your URL in the discussion group. Preliminary transactions might be donation-based, such as for work performed on the Prowl project itself or other type of activity that you publish in your blog. There is also technical documentation at http://tyaga.org/prowl/prowl_doc.php, which will hopefully generate discussions towards a standardization process. Suggestions on the development of different accounting models will be greatly appreciated.

Edgar

[Eric Harris-Braun]

Hi Edgar,

I looked at the structure of your Prowl and I see some underlying philosophical similarities to the "mesh and churn" model I developed for the open money architecture whereby a wealth acknowledgement is simply recorded as entities (i.e. database records) that are simply visible via distributed bunch of REST based servers that simply "publish," as you say, those events.

Central to the open money model is that currency specification is completely left in the hands of the users. This may be similar to your sense of an accounting model, but I'm not sure. For example we see that there will be many vector currencies, i.e. ones that to capture the relevant information of the flow being tracked require more than a single data point (i.e. not just "amount"). So you will see that the open money specification itself doesn't specify things at the level of your flow records (yyyy-mm-dd " from " originator.ext " to " recipient.ext amount units [#record_id] ".") but rather abstracts out the "amount" and "units" into a "flow specification." So for a reputation currency in which the flow being acknowledged is two subjective ratings (measured as 1-5 stars) of lets say quality and professionalism and a measurable assessment of timeliness (measured as enumerable choice task accomplished in a certain time frame), the flow would look like: yyyy-mm-dd " from " originator.ext " to " recipient.ext rating1 rating2 choice

So the open money protocol aims at creating a meta-specification that allows this kind of variability.

I hope this is helpful. Your work looks very interesting.

-Eric

[Edgar]

... "yyyy-mm-dd " from " originator.ext " to " recipient.ext rating1 rating2 choice"

The record syntax is not locked in yet, so the flow-record syntax could be extended to include other options as needed. What I found in developing the syntax is that it is generally better to use separate lines for recording measurements that use different units. E.g., a published record may include more than one rating, but it should be posted as two records that share the same id, one which shows the rating 1 measurement and the other, rating 2. It may not be clear that records are published simply to allow independent verification of complementary flow-records (equivalent to the declare-accept that I remember reading in the openmoney.info site) prior to posting to a report.

This is just good bookkeeping practice and makes it easier to develop reporter applications that parse published reports.

I have read a lot of the openmoney material on the web, and to be honest, it was only recently that I might have understood what you meant by "browsing" open money accounts in another discussion thread. It almost seems like you are trying to develop an alternate domain naming system solely for locating and viewing open money accounts. I'm not entirely clear on what the advantages are of mapping something to "zippy.cc.us.ny" when conventional domains such as "zippy.nycc.org" or "nycc.org/zippy" could already be located and viewed using standard browsers. Perhaps there are some architectural issues regarding domain names that I am not seeing?

[Edgar]

"Central to the open money model is that currency specification is completely left in the hands of the users. This may be similar to your sense of an accounting model, but I'm not sure. "

I see an accounting model as a subset of a currency specification. It seems to me that a currency specification is much broader and may include philosophical approaches that goes beyond what could be tracked and calculated through accounting mechanisms. For example, the sense of "community" is not something measurable, but it may be that a CC accounting model requires setting a community parameter to designate what a reporter may audit as valid transaction boundaries for an entity or account.

For example, a CC report may be initialized with "set mystore community.subdomain to nycc.org" and thus indicate to a reporter app that it should exclude, from its audit and eval, any record that is not between subdomains of nycc.org.

[Edgar]

I have consolidated some discussions that might relate to Prowl and Open Money at http://groups.google.com/group/prowl-users?hl=en.

Also, please read http://tyaga.org/docs/Prism.pdf as a rough guide to whether or not your comments or suggestions would relate to the particular currency design being discussed on any of the referenced web sites. As noted in the Prism convention for classifying currency design, details such as units, interest rates, backing, etc. are not factored as core design elements but rather implementation stage issues that could be accomodated through flexible IS Plans.

Transparency does not mean that anyone could or should intrude on carefully thought-out discussions.