simplified API?

[Miles Thompson]

Hey all,

 I think what you've been doing with Prowl is very neat and wanted to sort of encourage this just by engaging in conversation.

I apologise that I haven't read everything and probably only understand a tiny part of what prowl is about, but thought that I should engage in this conversation anyway.

What is interesting is when there are new groups, coming at things from a different but very similar perspective who may want to implement something similar and so the suggestion is that they 'implement your API'.

I think it would be great if 1. there was a reasonably widely implemented API that kinda specified the minimum number of operations that a currency provider would need to implement for 2. various other system to crawl the publically published information about those currencies and provide summary statistics that could let you know the 'health' of that currency at a given time. So, basically, Prowl.

There is of course, always a massive 'not invented here' bias to deal with which can make things tricky, politically, but still of course it does happen so one has to think about what would make that possible.

I am a bit worried that Prowl has an image problem that it is too complicated / too academic (even though you have a very real implementation). That is that it might be perceived as the CORBA to other people's ideas that might be a much simpler way of approaching the same thing. UNfortunately the simpler versions usually haven't been as well thought through - what would be most awesome is something really carefully thought through that was also simple, or at least extensible.

I wondered if one of the things that might make it more likely to get implemented 'by others' would be if you could come up with a simple description of the Prowl API or maybe a new 'lite' version that:

 - is a bit more separated from your academic explanations of  'currency as brand' OCUAP and such (since that's interesting but not necessarily where people are coming from) but refined down to really just the technical stuff

 - very clearly a REST protocol and as simple as possible - simple, simple, simple

 - having a seperate  page (with examples) devoted to explaining how simple and easy the protocol is and what the various calls would be

--

I'm thinking of open money crowd (of course) but also of, say,  twollars and their talk of adding new multi-currency support later.

What's going to make folks think.. oh OK sure I can grab this suggested API and implement it and then folks will be able to see how healthy my currency is.

For example, right now twollars is ridiculously simple - too simple of course, well in my opinion too simple /potentially unbalanced for it to really 'work' - but yet simple is beautiful isn't it?

It would be neat if the next iteration of twollars (or some third party crawlring the twitter stream) was able to implement a PROWL type or Prowl Lite type API that would then mean I could go to a page and very quickly see the total negative balance, total positive balance and various other stats that would be useful to help determine the 'health' of that currency.

For example a currency with large negative and large positive blaances is probalby not great. A currency with an imbalance between positive and negative balances (not offset to some other place) is even worse.. etc etc.

Apologies if /that this email is a bit incoherent, dashing something off at work, but thought I'd throw it out there see what your thoughts are.

Thanks

miles





 

[Guillaume P. Lebleu]

On Mar 25, 2009, at 4:33 PM, Miles Thompson wrote:

> I think it would be great if 1. there was a reasonably widely
> implemented API that kinda specified the minimum number of
> operations that a currency provider would need to implement for 2.
> various other system to crawl the publically published information
> about those currencies and provide summary statistics that could let
> you know the 'health' of that currency at a given time. So,
> basically, Prowl.

Miles,

I concur. I'm working on starting such an effort by "paving the cow
paths" set by PROWL, Twollars and others. See [1].

Guillaume

[1] http://lebleu.org/blog/2009/03/12/open-money-foundation-update-and-logo/

[Edgar Sioson]

This is great, and I really appreciate the feedback. Guilluame and I had conversed a bit about REST-type APIs, but have not started on anything yet, so your involvement would be much welcome.
 
While it might seem like Prowl is academic, my main point was to illustrate the separation of fundamental, orthogonal concerns, as follows (we could rename these concerns whatever we want to in a collaborative spirit):
 
1) "Publication Representation" - transaction record could publish in twollar, metacurrency or prowl formats, and could be encrypted-type if so desired, so that anyone's parser would be able to understand a text stream ESPECIALLY for witnessing or notarization
2) "Accounting Models" - this is really the means through which currency 'brand' diversity is generated; I think the 'brand' terminology is the most appropriate, but we could discuss alternative
3) "Reporter Functions" - how to submit queries that anyone's publication platform would understand
 
If Twollar or metacurrency does not need notarization of published records, they could publish a record however they want. But if any other scheme wants the ability for any 'reporter' to witness/audit/evaluate transaction data, I think we better get together to decide how that could be done with interoperability as a prime concern. Notarization would have important consequences to auditability and aggregation of published data - I'm more than willing to present my side and listen to others viewpoints on this.
 
Again, thanks for the comments and interest.
 
Edgar

[els]

About OCAUP: no one else has to follow this accounting model, they
could start out with cc or simple mutual. Each accounting model such
as OCAUP is mostly a specification on how to specify limits and
calculate balances when all you have is a sequence of posted records
for a given period.