In the metacurrency world, one of the key things we need is a grammar to that allows us to specify what a transaction will look like for a particular currency. Yesterday Art & I had a wonderful conversation with Eiso and Mac from Twollars about how this might be accomplished in a mult-currency Twollars universe. Twollars is based on parsing tweets from the public timeline looking for a particular format that indicates that the tweet is supposed to be a transaction. Here's an example tweet that Twollars recognizes:
Give @artbrock 2 Twollars because he's brilliant
Grammatically this translates to:
Give [subject] [quantity] Twollars because [reason]
Twollars could become deeply multi-currency if instead of there being just that one hard-coded grammar, anybody could specify a grammar for the Twollars server to recognize as a transaction for their currency. All that's needed is to throw in a hash tag to specify the currency. Here's an example:
Twollars: #zippybucks Give @artbrock 2 because he's brilliant.
The meta-grammar here that the Twollars server could parse is:
Twollars: #[currency-name] [transaction]
And then the [transaction] part gets parsed by the currency specific grammar which is:
Give [subject] [quantity] because [reason]
Now there's one other thing that has to be added for this to work, and that is a notion of what state a transaction is transforming. I.e. what's the aggregate result of many transactions. In the case of the current Twollars, the state is the balances of tweeter and the tweetee, and the transformation rules are simple:
1) Tweetee balance is incremented by [quantity]
2) Tweeter balance is decremented by [quantity]
But this too should be up for grabs and specifiable by the currency creator. The way Twollars has started out, users are issued 50 Twollars to begin with. This means that the total amount of thanks that can circulate in the system is 50 times the number of users. Think about it. Does that really make sense? Not really because my capacity to be grateful and acknowledge value given to me isn't hard limited like that, which is not to say that it's infinite. Eiso and Mac have very good reasons for starting out Twollars as they did, so I'm not knocking that at all. I'm just pointing to the fact that in the multi-currency world we want communities to be able to specify the circulation properties of the currency as suites them best. So, lets imagine a different "thanks" currency where you can "give" different words of gratitude (or ingratitude for that matter) and instead of a balance in that currency, what you have is a count of those words given and received. Here are some sample transactions:
Twollars: #thx Thanks @zippy314 for his amazing...
Twollars: #thx Appreciates @fer_ananda for her....
Twollars: #thx Scolds @artbrock for ..
Now when specifying such a currency we need to give both it's grammar:
#thx = [action:Thanks,Scolds,Appreciates] [@] for [description:what]
and define what the states are, which for this currency are simply 6 numbers, the count of thanks/scolds/appreciates given and received, and also give the transformation rules which are just:
1) Tweeter [action word given count] increased by 1
2) Tweetee [action word recieved count] increased by 1
Of course the Twollars interface should hide almost all of the underlying details of the states and transformation rules, by giving us a simple AJAXy way of defining our little transaction grammars and choosing various state transform options, and it would all be really easy, fun and cool. From the sounds of it, you might see something like this on Twollars no too far in the future…
Here are some more examples of other such currencies that Art & I came up with:
A simple LETS currency:
#lets = [action:Pay] [@] $[qty:int] for [description:what]
State transform: qty adjusts Balances
Twollars: #lets Pay @artbrock $2 for currency consulting
A Kilowatt Hour currency:
#kwh = [action:Energize] [@] with [qty:int]kwh for [description:what]
State transform: qty adjusts Balance [where balance max = infinity & balance min = 0]
Twollars: #kwh Energize @artbrock with 2kwh for currency consulting
A LOL Cat acknowledgement currency:
#lolcat = [action:can haz cheezburgr, cant haz cheezburgr] [@] forze [description:stuff]
State transform: action adjusts Counts: e.g. 20 can haz. 0 cant haz
Twollars: #lolcat can haz cheezburgr @zippy314 forze cieling cat prayrz
A currency for rating political debates:
#DebateVote = [action:rates] @obama [rating] stars @mccain [rating] stars
State transform: rating adjusts Average
Twollars: #DebateVote rates @obama 4 start @mccain 1 stars
Thursday, March 19, 2009
Metacurrency grammars and Twollars
Subscribe to: Post Comments (Atom)
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 ?
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.
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.
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!
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.
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?
Sorry, unlike Eric's exact examples, I got a little bit sloppy with my example for #[grammar+accounting convention], which should have read:
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.
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!
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
Post a Comment