when she wants to know the state of her config or request changes to it
Would that be manually triggered by Alice herself or sent automatically by the implementation?
Implementation specific. One connector might have logic to send these things automatically based on config other might provide a UI for users to interact with the peer.
All we need to standardize, I think, is the meaning of these values and the expected behaviour when handling these messages (and other ILP packets).
The goal is that if I know those values I should be able to predict when you will send a settlement to me based on the packets we’ve exchanged.
I also have the ability to invoke a settlement from you by requesting that you change those.
An obvious safety net would be that you’d never let me change my balance, min balance or max balance and I clearly can’t put my settleTo below min balance.
The more subtle thing will be deciding on where you’ll let peers put the settleThreshold in relation to settleTo but I don’t think that’s complicated.
Could you describe an algorithm for doing it automatically? I’m having trouble figuring out exactly when it would make sense to send them.
Two different design goals I have in mind are:
- Generally keeping the API requirements between nodes as minimal as possible to implement the features we need
- Making peering and management as automatic as possible to make operating a node simpler and help us grow the network
I agree that this is what we need to standardize, but we also need to implement some behavior for it.
Let me know if I’m thinking about this wrong but it seems like to support the method of querying / requesting changes to the limits like you suggest, we would need to:
- Track the current, min, and max
settleThreshold - Track the current, min, and max
settleTo - Implement an algorithm to trigger a query or request to the peer (maybe tied to whenever you send a settlement or just when you peer initially)
- Handle the cases where the peer a) agrees to the changes b) disagrees c) sets them to something other than what you asked for (for example, meeting you halfway if the value you requested is outside of their acceptable range)
- Ensure that we don’t introduce any vulnerabilities by allowing the peer to change the thresholds inappropriately
My gut reaction is that this seems to introduce more edge cases to code for and test, as well as a potential footgun in the form of not appropriately enforcing min/max values on the thresholds the peer requests and accidentally allowing your node to be drained of funds.
1 Like
Going back up the thread, what if we just track a single net balance number and, for nodes that accept pre-payment, have a separate number to track prepaid funds?
All ILP packets would affect the normal net balance position, and outgoing settlements would be based on this position.
When you get an incoming settlement, you would clear out as much of the peer’s debt as the settlement covers and any extra would be put into the prepaid funds account.
To be on the conservative side, if you’re pre-paying, you may want to have an explicit check to make sure you avoid the settling back and forth forever issue (there may be a better check but if you’re sending and receiving settlements with the same peer without having sent ILP packets, you may want to stop).
This still begs the question of what a positive vs negative balance represents 
Update: I agree with @sappenin’s original comment that a positive balance should represent a liability. That way, both the balance and the prepaid amount are tracked in the same way.
1 Like
QQ: Considering privacy: Should Bob at all be authorized to check Alice balance? Wouldn’t that raise security concerns?
Bob can check his balance on Alice’s system (assuming she exposes an API for that) but not anyone else’s
Thank you @emschwartz. Considering Bob is producer and Alex is consumer, Alex should pre-fund his account with bob to use his service, am I getting it right? That’s a nice idea, it increases scope for many accounting related options.
I somehow remember that using ILP, users can charge consumers without any subscription service. Is this like an addon or am I completely learning it wrong?
I think you may be confusing this with higher level uses of ILP. If someone has a service or some content they want to offer, they can use ILP micropayments instead of a subscription to charge the users for access.
This thread is about how ILP nodes, such as the end user and their Interledger Service Provider (that they would use for all ILP payments) track balances between themselves on a lower level. If the user trusts the connector/ILSP more than the connector trusts the user, the user may need to prepay some small amount before the connector is willing to forward packets for them.
1 Like
That’s right. Thanks @emschwartz. 
Again in my telecoms SMS background (high-volume/micro-cost), standard practice is the service provider displaying the balance of what a user has prefunded, perhaps with no credit line if the relationship is not bidirectional and a dynamic credit line available to them relative to the size of our Payable debt to them.
Netting too frequently with Alice could cause Bob liquidity issues when interacting with Carl, which does nobody any favours.
It’s also worth mentioning that certain geographies have netting restrictions, for example Brazil only allows netting in its local currency. And many geographies require netting to be reported to governments.
EDIT: You only need to read the paragraph above and this one. Netting can’t be forced due to regulatory issues. Two balances are necessary, but it doesn’t really matter how they are presented to users, as long as the accounting is correct. But as an end-user signing in to someones platform and looking at the balance I have available, I’d expect it to be positive if I have money to spend.
1 Like
Agree. I think this is what @sappenin also said above (way above)
2 Likes
Circling back here to make sure I’m properly understanding things.
Positive/Negative Balances
Cool – if I’m summarizing that and mapping it to some of the accounting terms we’ve been using, does this sound correct:
From the perspective of the entity tracking an ILP balance, a positive balance represents a payable/liability. A negative balance represents a receivable/asset.
I also agree with this statement, though it can get a little confusing.
For example, if Bob has prefunded 10 units to Alice, then technically speaking Alice owes Bob 10 units (Alice is holding those units on Bob’s behalf). Alice’s internal balance tracker would show 10 (i.e., Alice’s liability to Bob). If Bob asks Alice, “hey, what’s my balance”, Alice’s API should respond with +10 (from Bob’s point of view, Bob has 10 units stored at Alice).
However, if Bob asks his internal balance tracker what the balance is, it would report -10 (the inverse).
I’m comfortable with this behavior and these definitions, but I figured I’d call it out to both confirm that I’m understanding properly, and to ensure no objections.
In the net balance + prepaid balance model, what happens if both peers prepay? Does it function correctly? (This sounds odd, but if we ever implement auto-peering, that could be a likely arrangement between two nodes that each are not hubs, but don’t have reputation).