lnp-bp / invoices Goto Github PK

The invoice protocol here is intended to act as universal payment protocol - not RGB specific. It should be compatible with other asset protocols (for instance, Liquid), as well as should work for native Bitcoin and Lightning.

Thus, I'd like to ensure we do not use anything that locks us on RGB usage.

As of now, I think that having rgb-specific list of consignment APIs is fine, as far as it has a dedicated TLV type - such that other payment protocols which may require a dedicated payment API can always use a different TLV for their purpose.

Looking at the Invoice struct I see a consignment_endpoints parameter that is defined as Vec<NodeAddr>. NodeAddr is a struct with an id (NodeId) and an addr (InetSocketAddr) and is documented as Internet P2P node address.

We believe that consignment_endpoints should be changed to something as (wording can be discussed) Vec<ConsignmentEndpoint> where ConsignmentEndpoint is defined as an enum that can be Storm(NodeAddr) or RestProxy(Url). In this way in the future it will be easy and backwards-compatible to add other "protocols" that allow the transfer of consignments.

rgb-proxy-server is an example of such "rest proxy", I plan to add documentation on "protocol" APIs so that the proxy can be implemented also in other programming languages.