will this work for Gittip?

[chadwhitacre]

IRC

[chadwhitacre]

Gittip runs weekly. The current algorithm is:

1. Loop over all Gittip "participants," charge credit cards, and disburse funds to other participants within Gittip.
2. Loop over all Gittip participants and disburse funds from "team" participants to their participant "members" within Gittip.
3. Loop over all Gittip participants and deposit to bank accounts.

This is all done in a way that is fault-tolerant and parallelizable.

I still run the script from my laptop. Lately it's been taking between one and three hours to run.

[chadwhitacre]

IRC

[mbr]

I've spent some of the weekend reading bits of source and a good deal
of API docs on balanced, Billy, gittip and some related software and
asked around IRC to get a feel for their problems. The result is, I
would not at the moment recommend try to aim for completely doing away
with the gittip script:

Their process currently seems to be, all internal details like current
balances inside gittip aside:

1. Calculate what payments to make.
2. Collect as much money as needed, or at least as much as possible.
3. Repeat 1 and 2 a few times, accounting for failing credit cards and such.
4. Pay out.

This is fairly complex and hard to carry over to Billy, as it is far
outside the scope of what it currently does. From my estimation it
would either subsume a lot of functionality fairly specific to gittip,
or not be powerful enough for gittip to be of enough value to make
them abandon those parts of their code and setup a Billy server.

Here are some more specific problems:

• Handling failures when holding (actually gittip currently debits,
  instead of holding?) can be
  dealt with in different ways, gittip invalidates the current graph and
  retries with modified values. That's fairly untypical, I'd wager,
  because a "normal" for-profit company would either refuse service or
  collect the money from the customer later.
• Because the amounts handled are small and fees therefore relatively
  high, gittip uses an internal accounting system. For Billy to be of
  any reasonable use in this case, one would have to add this as well;
  in consequence, gittip would be manipulating these accounts through
  API-calls instead of keeping its own internal balances. This might
  make things a good bit more convenient for other users, but in
  gittip's situation would probably shift the problem around without
  letting them get rid of their payday script entirely.
• There seem to be a lot of ideas for future features of gittip (like
  allowing users to distribute recurring funds on specific topics) that
  look like they'd all need special attention in the future.

I did think about transactions (in a database sense) and whether or
not something similiar for balanced-API calls would be a win for
gittip. A conditional transfer, for example, does have limited value
as the other "transitive tips" make it too complex to express as a
simple "if user X is solvent, transfer n to user Y".

What would be an interesting idea is probably allowing for batch
transactions, these could be optimized by balanced internally, taking
the burden of increasing throughput off the API client. whit537's
mentioned that before?

A thing that I did not mention in the chat is asynchronous
transactions, these could be side-by-side or instead of batch
transactions: Putting a hold on a card, getting a URI back to query
for the result later could speed up things.

I was interested in the runtime of the payday script at first, as that
seemed to be a good way to examine things - if this could be reduced
an order of magnitude, it would be a good indicator whether or not
things are simple enough to shift over to Billy completely.

Their payday script has at least two things that make it slow:
Implementation-detail related calculations, which I am sure they will
improve and a lot of HTTP-calls to the API (see Batch and Async
above).