hkjn / lnhw Goto Github PK

One of our biggest problems during the hackathon was getting real c-lightning data as we waited for our bitcoind and c-lightning testnet nodes to finish syncing.

I propose we use something like https://github.com/PierreRochard/bitcoin-lightning-docker to create a dockerized bitcoind / c-lightning test environment running on regtest. This way we wouldn't have to deal with testnet annoyances like coin faucets or syncing testnet's 15gb chain.

The project I linked above uses lnd. I plan to add c-lightning soon. This would probably be sufficient for UI developers. Next we would have to add some ability to use a c-lighting fork, instead.

I'm filing an issue to remind ourselves that we need to settle on an API between the ui layer and client layer.

On ui side, @superquest and friends have started with https://github.com/hkjn/lnhw/blob/master/ui/sdk.js to stub out the interactions they believe are needed for ui to fetch data from client to find out about the c-lightning state, as well as for ui to tell client to take an action, e.g. sending a BOLT11 invoice.

Some options:

1. Use lightning-cli, with a ui-side backend that receives HTTP requests from the client-side code, and translates them into lightning-cli commands
2. Build a small HTTP backend on client side, similar to the https://github.com/hkjn/lnmon/blob/master/lnmon.go tool which wraps lightning-cli to provide the data that is shown on the https://ln.hkjn.me web server + prometheus monitoring target

To show all necessary information on the tiny OLED screen we need to be able to scroll information.

For example, information about invoice contains amount, description and public key of the receiving node. We should be able to scroll to the next screen when user clicks button B.

Requires refactoring of this file: https://github.com/hkjn/lnhw/blob/master/arduino/ui/oled/oled.ino

As we found out, it's extremely annoying to set up Arduino IDE on Linux. If anyone remembers what we did to make it work, it would be really helpful to write a small guide on how to fix permission problems.

I'm filing a ticket to track our discussions to date about settling on an API between client and hardware layers.

Our current thinking is to initiate communication from the client layer, and use the serial port to send text-encoded requests to the hardware layer, which will return similarly text-encoded responses.

The responses might be delayed until the UI on the hardware side has gotten confirmation that the user wants to take a certain action.