- From: Michiel de Jong <michiel@unhosted.org>
- Date: Thu, 20 Sep 2012 17:10:02 +0200
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Web Payments <public-webpayments@w3.org>
we have the same problem as earlier: a payment is the *opposite* of an IOU. Alice pays Bob 10 euros. means she owes Bob -10 euros. Take for instance http://expenses.michiel.5apps.com/#20120909 most lines there are declarations from one person to the pot. a positive number in your column means you are owed money. it works as follows: i get my bank statement from my bank. on there is a line like the one you get out of paypal: PAYMENT: from: my bank account to: Zagreb Airlines amount: 30 currency: EUR this is a payment from my bank, the IOU is to my bank: Zagreb Airlines now owes money to my bank. unless i dispute this line on my bank statement, the understanding between my bank and me is that i accept a cycle resolution: me -> my bank -> Zagreb Airlines -> me for the same amount. So after that, I instead of Zagreb Airlines owes my bank 30 euros, and Zagreb Airlines owes it to me instead of to my bank. I was basically made in intermediate hop, splitting the IOU into two IOUs. Now i copy that line from my bank statement to my travel expenses sheet. So now the unhosted project comes inbetween me and Zagreb Airlines. So Zagreb Airlines owes the unhosted project, and the unhosted project owes me. When i take the actual flight, and the unhosted projects benefits from that, that is a second transaction. Value passes from Zagreb Airlines to the unhosted project. This is a second cycle resolution, in which Zagreb airlines falls out of the equation. Once that has happened, the eventual chain of IOUs ends up being: the unhosted project -> me -> my bank. now let's say someone donates to the project, and I end up receiving that money in my bank account. That then leads to a third cycle resolution, and we're all quits again. in between those events, there is an outstanding balance, that is represented by the sum of all current uncleared IOUs. That's the blue line you see in the expenses app. All of this works best, in my experience, if our atomic unit of data is a transaction plus the resulting balance between two peers. by including the balance on the line, you can detect when a line is duplicated or missing. So i would add a column to your csv format: "resulting balance". hth, Michiel On Thu, Sep 20, 2012 at 11:46 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote: > I was looking recently at the way that paypal handle bulk payments ... a > screenshot is below > > https://www.paypalobjects.com/en_US/i/demo/batch_format.gif > > <user1> <amount> <currency> <user2> <comment> > > I realized this is very close to the webcredits fields without the > timestamp, and some of the meta fields (eg id, type, context, scheme) > > I figured this might be a nice shorthand to store IOUs e.g. on paper, or on > a phone etc > > Alice 10 USD Bob pizza > > For example could be a line easily transerable to a universal webcredits > format > > > Rules: > > Alice -> Is looked up to go from a local identifier to a universal on > processing > 10 -> is validated as a float > Bob -> Is looked up to go from a local identifier to a universal on > processing > pizza -> is processed for escaped characters and recorded as a string > > Two questions > > 1. Which delimiter to use, or leave it open as per csv > 2. Add timestamp as optional or just take it from the file?
Received on Thursday, 20 September 2012 15:10:36 UTC