Comments on New Currency Frontiers: Metacurrency grammars and Twollars

Had a second look at the grammar Eric posted here ...

2009-05-26T17:01:22.978-07:00

Had a second look at the grammar Eric posted here and then the Twollars page that mentions the MultiCurrency experiment. My previous post was how [reason] part may get parsed by an ecological currency specific grammar yet further. ie

#ecoTwollar[savingof:resource,pollution] by [savingby:...]
where resource,reason and savingby parameters would be parsed further. The idea is that the reward would be for actual saving that truly matter.

However, this is too much running ahaed so for the time being I also eagarly await what will transpire from the MetaCurrency experiment Eiso mentions on the new About page of Twollars v2.0
Warmly,

2009-05-22T05:23:41.548-07:00

This comment has been removed by the author.

Hey Edgar, I really like the distinction you are m...

2009-03-25T20:56:00.000-07:00

Hey Edgar, I really like the distinction you are making between identifying a currency (#[currency-name]) and identifying a grammar (#[grammar-accounting
convention]) or perhaps what could be called a currency type, to aid parsers in reading these published records in the stream.

When I was throwing this together with Art my aim was only to try and make it as simple and natural language like as possible for users to type them into the twitter stream using the current Twollars interface.

You are addressing the deeper issues that need to be in good flexible protocol that achieves proper separation of concerns. Thanks for this!

Sorry, unlike Eric's exact examples, I got a littl...

2009-03-20T20:45:00.000-07:00

Sorry, unlike Eric's exact examples, I got a little bit sloppy with my example for #[grammar+accounting convention], which should have read:

#Prowl+ocaup
or
#Twollars+mutual-credit
or
#x12+GAAP
or
#Prowl+cc

And as a farther clarification, my concerns mostly stems from the possibility that that subjects in a transaction may belong to different entities, e.g., one is registered with twitter.com while the other is registered with anotherentity.org, AND each entity maintains its own ledger independently.

Please let me know if this is too much info and I ...

2009-03-20T16:24:00.000-07:00

Please let me know if this is too much info and I would be glad to take my concerns elsewhere.

IMHO, interoperability means much more than just avoiding collisions. To me, it also means minimizing the vocabulary that my parser and someone else's parser have to know to process transaction records that are generated by different systems.

E.g., if the transaction record formats are unique for each [currency name], the parser code will have to accomodate all applicable grammar separately.

It seems that #[currency-name] should be #[grammar-accounting convention] instead, so that the grammar-accounting options for each currency would be limited by a preset conventions that parsers would have an easier time accomodating. This would also simplify currency set-up for new currency admins. An example grammar-accounting convention is something like Prowl, Twollars+mutual-credit or x12+GAAP (abbreviated as needed). The convention being in front is similar to having HTTP or FTP in front of a URI.

To simplify coding farther, each grammar convention should have few verbs or keywords, and allow for noun or subject diversity in a standard format. For example, I would prefer if the [subject] is expressed as a domain name, so that my code could use plain HTTP to find where I could cross-verify that the credit recipient (e.g., artbrock.com) has accepted a transaction record. This way, I don't have to know a registry's IP address or program another step just to find @art. Domain based names also guarantee uniqueness.

This requirement may be specific to my currency design, but if cross-verification is not possible, there would be no auditability.

To specify a currency community, the field after the amount could be combined as [currency-name+units], as in USdollars.

I realize these are all preliminary, but while some suggestions such as using domain based names may seem clunky, my intent is to help minimize coding and coordination.

But this is mostly just the publisher part, what about the possibility of auditing the back end or ledger reconcilability? This is not just a prowl concern, see http://copsewood.net/mrs/mrsspec.html#4.4. For example, what if I wanted to graph and compare the periodic performance of a currency that I am following?

This is fantastic! I hope we can get some momentu...

2009-03-19T10:44:00.000-07:00

This is fantastic! I hope we can get some momentum to implement this soon. One thing to keep in mind: the grammar will have to be practically transparent. Eiso and Mac tried to incorporate all variations on the normal twollar transaction format. We will need similar attention here.

Also we will need a no-brainer UI. I suggested to them "presets" as a good starting point. For example: "time-bank" could be a currency preset. Or for that matter, once twollars can handle multiple account types: community way. I think getting mutual-credit going will be a first key step in this process though.

Marc,

Yes it certainly makes sense in some ...

2009-03-19T09:47:00.000-07:00

Marc,

Yes it certainly makes sense in some contexts to have an sense of relative difference between levels of a non-continuous valuation scheme. But in other situations it might not make sense at all. Hence the need for the multi-currency world!

-Eric

You can add twollers to the system by buying t-shi...

2009-03-19T07:44:00.000-07:00

You can add twollers to the system by buying t-shirts too, which I think I might do soon.

But you point is well taken that they need to have more ways of issuing currency.

Another point is that twitter space is a global space, so if other groups are also creating currency syntax we had better make sure they don't collide. Note that there are a number of GIS based sites that tag with location too, and we can define plays in terms of location too, so the expansive definition of currency takes in a lot.

Anything you can reliably parse out of the twitter...

2009-03-19T07:39:00.000-07:00

Anything you can reliably parse out of the twitter stream can be a currency. I'm thinking that we need a formal syntax for precisely describing a currency play as well as being able to parse more natural language ones from context. Already there could be confusion from talking about twollers vs. plays in twollers.

I like something like $<currencyname>(@<recipiant>,<value>[,<value]*) for xyz

The ideas is to have a currency symbol that works like the hash symbol in hashtags and atsign for twitter identities.

The main point is that you have to be very careful in designing a grammar or you will create more ambiguity and confusion. In the metacurrency context, we need a grammar that can at least handle all currency plays. Another twitter grammar for currency definitions might be fun, but let's hold off on that part of the design.

Thanks.
Just a question/remark about tha gramma...

2009-03-19T07:32:00.000-07:00

Thanks.
Just a question/remark about tha grammar and counting words instead of quantities.
In the #thx example you have 3 actions. 2 of them are very similar: "thanks" & "appreciates". We could also imagine having "likes" and/or "Loves" actions and let the currency creators decides of an equivalence between those actions.
For instance 1 Love = 5 Likes
1 Love = 10 appreciates
1 thanks = 1 Appreciates
Does it make sense to you ?