[feature]: The ability to route assets directly and swap assets with non-peer nodes

[jcbrand]

Is your feature request related to a problem? Please describe.

The TA protocol is currently designed so that assets must be swapped for sats at the edges of the route (i.e. with direct peer nodes of the payer and/or recipient).

We would like to have the ability to swap assets with non-peer nodes, which also implies the ability to route assets directly over one or more hops without swapping.

Why is this be a desirable feature?

Because this can result in better exchange rates for users.

For example, a peer swap node (aka edge node) might be reluctant to swap BTC for TA and it therefore charges a premium for its BTC, because its portfolio allocation is currently underweight BTC, so it would rather get rid of its excess TA and not buy more, whereas the non-peer swap node might prefer to get more TA in its portfolio, and it therefore offers a better exchange rate.

So if you have the ability to swap with the non-peer node, you can get a better exchange rate than when you're forced to swap with the peer node.

Example:

Let's say we have the following topology and route from A to E:

A --tap--> B --tap--> C --> D --> E

B is currently reluctant to swap, so they'll prefer to route assets-for-assets. C is happy to swap and therefore has a more competitive asset rate, so A would prefer to swap with C.

It would also be good if the opposite flow, sending BTC to TA were possible.

A --> B --> C --tap--> D --tap--> E

In the above example, C does the BTC to TA swap, even though it's not a peer of E.

Describe the solution you'd like

We'd need a few things to make this possible:

• Nodes need to be able to negotiate a quote, even though they're not peers (perhaps onion messages could be used here).
• The invoice must have more a comprehensive route hint which includes the route to the non-peer swap node
• The protocol spec and tapd need to be updated to allow for Taproot assets to be forwarded directly and not always immediately swapped for BTC

I'm aware that one particular complication is that Taproot channels are currently all private, and this means that there's no discovery of non-peer channels we could swap with. This is a challenge to finding a generalized solution.

In our particular, narrower use-case, we do know these routes and we could therefore use something like SendToRouteV2 to make a payment that will be routed over a non-peer swap node (although I note there's no SendToRoute endpoint for tapd).

We also have the ability to negotiate quotes between non-peer nodes, so although onion messages for RFQs would be needed in the general case, they're not needed by us in particular.

For our narrower use-case, we just need the last point:

• The protocol and tapd need to be updated to allow for Taproot assets to be forwarded directly and not always immediately swapped for BTC

To break this down further:

1. Concerning the protocol spec change, I'm referring to the onion processing section in bLIP 29:

When receiving an incoming onion TLV payload sourced from a TAP channel, the receiving node:
MUST reject the payment if the incoming HLTC is a TAP asset, and the outgoing payload doesn't include a tap_rfq_id value.

This will have to be updated so that the node tries to forward the TAP asset if there's no tap_rfq_id value.

2. Then the taproot-assets source code needs to be updated to allow direct forwarding of Taproot assets and not always try to swap for BTC. For example here:
   

   taproot-assets/rpcserver.go

   Line 8921 in e892603

   if len(acquiredQuotes) == 0 {