W3C home > Mailing lists > Public > public-webpayments@w3.org > September 2012

Re: Payments as a CSV

From: Michiel de Jong <michiel@unhosted.org>
Date: Thu, 20 Sep 2012 17:10:02 +0200
Message-ID: <CA+aD3u0ZR-bDtF6FYRbAYkQD5tmh+fjGACm4rbsvpieS=VHu3Q@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 20 September 2012 15:10:36 GMT