Some remaining issues with current implementation:
Some remaining issues with current implementation:
* Some calls require shell access to lightning-cli as some gRPC calls are not yet implemented
* Getting on-chain fund flows is not as nice as it is with LND and required access to the Core Lightning SQlite database
* With current API you can only get current outputs
* High probability of bugs arising
closes#45
When someone connects to the SSE endpoint and the wallet is
locked a message with event name `wallet_lock_status` type is sent:
```js
// only sent when a new SSE connection is established and the wallet is
// locked at the same time
event: wallet_lock_status
data: {"locked": true}
```
When the wallet is unlocked either through SSH or the API, another
event is sent:
```js
// sent always when a new connection is established when the wallet
// is unlocked, or it is sent when the wallet was unlocked after
// connection was established
event: wallet_lock_status
data: {"locked": false}
```
It is always the first thing the client receives. After the unlock
event, the usual warmup data is sent.
refs #34
This avoids duplicated code with other ln implementations later on.
This also pushes LightningStatus object to the SSE channel
instead of the full LnInfo object.
refs #11
* /lightning/getbalance now returns onchain funds and channel
balances as one object
* changes to the wallet balance are now pushed through the SSE channel
