Should the API deal with sending and receiving money instead of min/max balance?

[emschwartz]

Instead of using the min/max balance, we could make the API a little more similar to normal sockets (like @adrianhopebailie suggests in #19) by having methods like send and receive on the socket object.

Use Case	Min/Max Balance API	Alternative
Sending	client.setMinAndMaxBalance(-1000)	client.add(1000); client.flush() (or client.send(1000))
Requesting	server.setMinBalance(1000)	server.receive(1000)
Making funds available to be requested	client.setMinBalance(-1000)	client.add(1000)
Enabling refunds	(not modifying the min balance as money is received)	server.receive(1000); server.on('chunk', (amount) => client.add(amount))

You would add and remove money from the socket, instead of setting the range you want your balance to end up in. When you call receive it would reduce the socket's balance by that amount if it's already got that much or it would request more from the sender and wait until it has reached that amount.

Thoughts? Would that be easier or harder to work with?

[emschwartz]

Also, since money is fungible, calling receive shortly after add would result in:

client.add(1000)
// client starts sending and it sends 500 before the next thing happens
client.receive(1000)
// client stops sending the original amount and requests 500 from the other party

[justmoon]

I think send and receive by themselves are not enough, since you probably want the default maximum to be zero so you don't get unexpected funds. So you also need payUpTo (you call it add) and chargeUpTo (missing here?) from interledgerjs/ilp#130.

Regarding flush, I ended up with having pay and charge be asynchronous (and flush automatically) and payUpToand chargeUpTo return immediately. You could have a separate flush call for pay and charge, but I think it would be less surprising if the default was to flush automatically. When using payUpTo and chargeUpTo, you would use the stabilized event to detect when the other side is done sending/receiving.