I find micropayments a really exciting feature. You are completly right that at any point of time both the user and the service provider must know their balances inside the channel, but this is part of the channel’s protocol anyway. In order to make this practicle, the:
- client needs some software that handles this for him. Think of a wallet
- the service provider needs software that is channel’s aware that produces tokens on demand
So whenever the client requests a new API token, this request consists of a some sort of a micropayment inside the channel: modifying participant’s balances or/and some off-chain contract’s balances. This is co-signed off-chain transaction. Then the service provider makes another off-chain transaction providing the requested new token and claiming the amount locked for it. It is a matter of a business model if this token can be used a couple of times or just once.
You are completly right that in some cases when there is just a few aettos locked in an off-chain contract, a force progress will be too expensive and might not be viable. It is a similar situation if one wants to force progress a really big contract - this could require much more gas to store it on-chain than one might eventually get out of the contract itself. This is up to the participant to decide.
Regarding the new types of business - I was not part of the team writing the paper, so I can speculate what they had in mind. From talks with them, I could think of some examples:
- Video/music on demand where you pre-pay for the next few seconds
- Paying/Getting paid for services per second
- Paying your rent/mortage/bills per second
All the things we are used to pay/get paid on a regular basis could easily be broken down into smaller intervals. The only reason one gets a paycheck once a month is it is too cumbersome to make it every day for example. But with channnels it is easy to achieve.