How to request `lsps0.listprotocols` and get the response?

[yanganto]

Hi there,

First, sorry to open PR(#15, #16) before this issue, and thanks for this crate, such that we can have a channel to talk to each other. I will list down the details here before the bi-week meeting starts just to make sure I will not miss out on some detail and do not mean on this (I live in the +8 timezone, and the time of the meeting is midnight), and you do not need to hurry to respond this if you are busy.

---

Real Use Case

An application uses LiquidityManager, which has LSPS0MessageHandler in it. Now lsps0.listprotocols is implemented inside, it is good to request the application(release build) and make sure it works to validate the application before delivery.

So anything under #[cfg(test)] or unit test will not solve, because every byte in #[cfg(test)] or unit test is not really in the release build binary. I do integrate and do not have the duty of developing this repo, contributing to test cases, or any kind of unit test that does not make sense from my end and does not solve my issue on validating the release binary.

---

The Way to Receive Response in Blockchain This is the part I really confuse in this project. In General, the response of blockchain sends out in two ways, it is hard to know how it will be in the current project. Different blockchains may use different names, and the basic mechanism are these.

• Directly Response (like HTTP, RPC, or JSON RPC, etc whatever)

 Blockchain Node   <----->    Queryer (possibly a Node, client, or cli, etc whatever)

For the direct response, the function actually handles the content of the request and will return the content of the response.

• Broadcast Response to the Blockchain Network (like Event, etc)

Blockchain Node   <----->  Blockchain Node (Queryer, also a blockchain node to receive Event)
   |
   \-----------> Blockchain Node
    \-----------> Blockchain Node
     \-----------> Blockchain Node
      ....

In this way, the response or event will send to every node. There are three ways a query can know the exact response to his request.

• The content is a status or a general thing (No additional Id) take the lsps0.listprotocols as an example If there is a field to represent the node, then we can use this, the current spec of lsps0 is not

  {
  "node_id": "0xAAAAA",
  "protocols": [0]
  }

• With request Id or receipt Id There is an id in the response, and commonly any other things are in a result field like this(nesting is not necessary). Because of the id, the queryer can listen the events and know which one is the response to the request he sent.

  {
  "id": "let the query know this is for him",
  "result": {
     "protocols": [0]
  }
  }

  And there are two kind Id of this based on the mechanism wherein who generate the id

  • the Id is generated by queryer, normally it is named request Id The request Id will be defined as a required field in the request
  • the Id is generated by node receiving the request, normally it is named receipt Id The receipt Id will return to the queryer as a directly response, this means the handler will return an Id but not the response itself.

  ---

  Currently Status and Issues

  • The corresponding functions return Result<(), _>.
  • The id is generated in the handler, and it is called RequestId
  • There is no function in LiquidityManager to make a request to other node or self node

  ---

  Terminology The application with LSPS will handle any incoming LSPS message and also send LSPS messages out, so the term Client or Server I try to avoid. It mixes two kinds of roles. And there is still a difference between an application listening to the event and not. So the term Node means it is in the blockchain network and will listening events or broadcast events.

[yanganto]

To sum up, the solution is an event with the public key as the response.

ref: https://github.com/lightningdevkit/lightning-liquidity/commit/1f11274bb277cbf101dda99eb77ca71ed381002d

[tnull]

To sum up, the solution is an event with the public key as the response.

ref: 1f11274

Currently, yes. Note that the API is still considered unstable and might undergo further changes.