[feature]: Expose Price Oracle RPC

[levmi]

A wide variety of app developers will likely be interested in validating the quote provided by the edge node for their users. Luckily, tapd itself also has a price oracle connection built into the daemon. However, the output of that price oracle is not easily accessible for app developers via an RPC. We should expose the result of the tapd price oracle for consumption by app developers via RPC.

[ZZiigguurraatt]

Trying to understand your wording here. Based on the conversation we had on this topic, I thought the intent was the following:

Expand tapd to not only be a price oracle client, but also a price oracle server. Normally the price oracle server is a separate external process. The price oracle server in tapd would basically be a proxy to the external price oracle server configured at https://github.com/lightninglabs/taproot-assets/blob/bf9fbadba06a1d19ec0c73604a55aef9b1aa6aa7/sample-tapd.conf#L358-L361 .

Benefits of this are as follows:

• Actual price oracle server can remain unauthenticated and on a private network (and it must until https://github.com/lightninglabs/taproot-assets/issues/1370 is fixed), but still allow authentication through tapd and exposure over the internet using a macaroon.
• Common gRPC socket (more efficient on the wire and less socket/connection objects to manage in client applications).
• Less firewall ports to open, less hostnames, SSL certificates and macaroons to manage.

[ZZiigguurraatt]

We should also be more specific here in that all we are talking about exposing is the QueryAssetRates RPC.

[Roasbeef]

Expand tapd to not only be a price oracle client, but also a price oracle server. Normally the price oracle server is a separate external process

My reading of this issue is that it would just be a proxy. So tapd isn't running the price oracle server in its Go process, instead it allows users an easy way to query the price oracle it's already connected to.

So we'd add a new RPC to the tapd rpcserver, which serves mostly proxy (can add any other relevant information) to the price oracle server itself.

[ZZiigguurraatt]

OK, so it might actually be a slight variant of the QueryAssetRates RPC?

[Roasbeef]

Yeah, basically a pass through version. So the user doesn't need the oracle info to query it, just tapd's info, who then proxies the call.

[levmi]

This proxy could also be used in the Terminal UX once enabled. For instance, when you plug in a payment request to the UI and select an asset to send, we currently call the tapd AddAssetBuyOrder/AddAssetSellOrder RPC to get the exchange rate. That's fine for now as a stop gap solution. The issue with that is that it'll actually insert RFQ records, and can actually fail once we insert the copilot control stuff.

A more fool proof solution would be to use this path with the Oracle Proxy. cc @jamaljsr for vis

[ffranr]

In my opinion, directly exposing the price oracle RPC within tapd is suboptimal. Instead, we should introduce a new RPC endpoint in tapd that calls into the price oracle to retrieve and return prices.

Crucially, this new endpoint could be extended to provide additional relevant data, such as local network prices—reflecting exchange rates achievable given the current peer set—by querying RFQ for those rates. This approach could align with a future where RFQ supports multi-peer interactions and provides quotes without requiring an active payment.

This new endpoint could help us differentiate between price oracle estimates and the actual prices supported by the local network.

So, IMO, TLDR: yes to a current best price RPC endpoint, no to just expose price oracle.

[levmi]

Adding comment from Laolu in Keybase so it doesn't get lost:

so changes from the PR would be:

• new set of protos to existing LN sub-server
• can start w/ just the asset_id/group_key and amount, can add on other info may think is relevant
• that just calls out to the configured proxy on the backend
• in the future can have it do things like add more oracles, or implement aggregation strategies across several (weighted avg, etc)

[ZZiigguurraatt]

Thinking about this more, I think the feature should also include tapcli access to this new RPC. OR, we should have a simple CLI tool that is a client to any configured price oracle server (users likely want a simple way to be able to query an arbitrary price oracle for testing or informational purposes but don't want to write their own tool to query the gRPC).