Re: Payments as a CSV

On 20 September 2012 17:10, Michiel de Jong <michiel@unhosted.org> wrote:

> 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
>

Just a side comment on the URI.  I understand why you use # here as A) in
order to hide some information of the HTTP request from a server you dont
fully trust, B) well, it looks cool

But using a # here is an anti-pattern.  How are you now going to refer to
data items in the document, in this case transactions.  You urgently need
to remove this anti pattern from unhosted in general, but anything
financial, this is a road to disaster, almost guaranteeing that useful apps
will need to forked.  Use a ? instead.  If you *MUST* use #, build it so
that the javascript can handle a ? too.


>
> 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".
>


Almost all money in existence today originates in the form of an IOU.  In
particular, it is borrowed from a commercial bank in exchange for a promise
to pay from future work.

So I will ask for 10,000 EUR on my bank account in exchange for a promise
to pay back, say, 15,000 euro over 10 years, which is an IOU from me to the
bank.

Or if I deposit my 10,000 EUR with a bank it becomes an IOU from the bank
to me.

Every time I withdraw from a bank the bank now owes me a bit less and I
have say cash which can be used to settle other IOUs e.g. for goods and
service.

Every time i repay a loan the IOU is reduced in magnitude.

In a given system all of these IOUs are redeemable with the central bank.
Historically for gold or silver, but currently it is just a guaranteed form
of legal tender meaning that merchants should accept it, or that it can be
used to pay taxes or court fines.

As you can see, this whole system, although it has a central point of
failure (trust in the central bank), is also decentralized through the
clearing process.

In order to scale, it's almost infeasible to keep one central tally of all
the transactions that ever happened.

So what you should do is to keep a record of transactions as one task, and
a record of balances (eg in a closed system) as a separate task.  e.g.
Transactions in your data, and balances in the javascript.  It's possible
to put balances in your data too, but be aware that as the system scales
the balances can get out of sync (sometimes called a break) and then you
need to resolve a conflict, which is out of scope for the core transaction
model, but possible to layer on top.

Curiously enough bitcoin does actually store every transaction and balance
ever in the block chain.  But this is also why the block chain takes hours
to load and transactions are taking longer and longer.  What they need to
do is archive all those GB of transactions and provide a snapshot along the
way.  The problem then becomes who can make a snaphot, and you've
introduced centralization!

So to summarize, augment your transaction list with balance aggregation.
Either in the JS (best imho), in the model (needs thought), or with
checkpoints which are convenient as the IOU model is so simple it has the
same fields as a balance.  The CSV as a hashed shorthand probably is not
the best place to put balances.  Timestamps I can see as useful, and the
main thing I'm thinking about is whether to add an ID.

Hope that helps!


>
> 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?
>