Core quoting doesn't work with subledger addresses

[emschwartz]

Quote will respond with an error if you try to get a quote for an address like ilpdemo.blue.bob.somethingextra. I think it should return the best quote it can, and maybe tell you how close it can get (in this case it might say it is only certain it can have money delivered on ilpdemo.blue, so if there are any connectors that charge fees beyond that it probably won't work).

Note that js-ilp uses request-specific addresses in the form <ledger>.<account>.<request uuid>

[adrianhopebailie]

I think it should return the best quote it can

:+1: - and what the address is of the account that is for.

Should it say that the quote is for ilpdemo.blue or ilpdemo.blue.bob?

Based on the discussion in https://github.com/interledger/rfcs/issues/77:

since the unit of the amount delivered is determined by the ledger portion of the ILP address, the subledger MUST use the same currency as the parent ledger. Bob also cannot charge himself any fees when relaying a payment to his subledger.

That quote should be enough. The sender shouldn't need to add anything to that quote to deliver to ilpdemo.blue.bob.somethingextra

[emschwartz]

This was my original problem with that discussion. What if the address is us.fed.wf.ilpdemo.blue.bob, because there is a connector between us.fed.wf and our ilpdemo ledger and we've chosen to address our ledger in terms of a bigger one that's more widely known? If the sender's connector only knows how to get to us.fed.wf it can try to deliver to the ilpdemo account but that will likely fail. I would prefer it told me it doesn't really know how to deliver the funds to the end, or at least how much of the path it does understand

[adrianhopebailie]

If the sender's connector only knows how to get to us.fed.wf it can try to deliver to the ilpdemo account but that will likely fail.

That's the right behaviour.

For these payments to succeed we need the last connector in the chain (between sender and us.fed.wf) to be aware of the connector between us.fed.wf and ilpdemo so it can include it in it's routing table.

This could happen a few ways:

1. ilpdemo broadcasts the route via the appropriate routing protocol and that connector stores the route
2. The connector attempts to deliver to the us.fed.wf.ilpdemo account and fails and based on that tried to discover other connectors connected to us.fed.wf that can help it deliver to us.fed.wf.ilpdemo

If senders see routes they don't recognize then they should get an explicit quote for that route (perhaps using an optimistic payment) to try and discover what routing info they are missing otherwise they risk a failed payment.

If the last connector in the chain between sender and us.fed.wf get's the quote request and can't route further it should make an effort to find a route and get an accurate response or it will lose out on a payment.

[justmoon]

This was my original problem with that discussion. What if the address is us.fed.wf.ilpdemo.blue.bob, because there is a connector between us.fed.wf and our ilpdemo ledger and we've chosen to address our ledger in terms of a bigger one that's more widely known?

Then you messed up. Note that our original understanding of prefixing and subledgering was vague and broken.

The correct way of thinking about ILP addresses is as two parts: ledger part and account part. The account part may contain dots to represent subledgering (a very limited and specific concept analogous to subnetworking.)

If you are not subledgering (breaking a ledger down into subaccounts - which may be virtual like the js-ilp use case - of the same fungible asset), then you shouldn't use the other ledger's ledger prefix.

I highly, highly recommend reading interledger/rfcs#77 closely and I added another comment for clarity.

[adrianhopebailie]

The account part may contain dots to represent subledgering (a very limited and specific concept analogous to subnetworking.)

This is somewhat analogous to things like small home networks behind a NAT. To the outside world the address of all machines in that home network is the same and the router figures out how to route incoming packets based on other semantics (like a port number for incoming connections when using port forwarding).

As @justmoon says we can think of that last connector/ledger as the edge of the Interledger and any sub-ledger accounts like nodes on the subnetwork. What happens after the last connector delivers to the local account on the terminating ledger is invisible to them.

But, we should also consider our trust lines idea as a way to deliver this payment beyond the edge of the Interledger.

For example, if Nerd has the account ildemo.usd.nerd and has a trust line with Noob he could tell Noob to use the address prefix ildemo.usd.nerd.noob.

So Noob could even host an SPSP receiver as long as they are able to produce a payment request that Nerd can fulfill and they can use any address as long as it's prefixed with ildemo.usd.nerd.noob.

Payments get delivered to Nerd (ildemo.usd.nerd) who sees a destination address with the ildemo.usd.nerd.noob prefix and so use their payment channel to deliver to Noob.

If Nerd wants to take a fee they need to have arranged that with Noob as part of their trustline agreement and so Noob expects to get payments with the fee deducted (either in realtime or later during settlement) but this is invisible to the participants in the Interledger.