ci/woodpecker/push/woodpecker Pipeline was successfulDetails
ci/woodpecker/tag/woodpecker Pipeline was successfulDetails
the "nodename" encompasses lnd alias and OS hostname.
while the former may be seen by lightning node peers as a node name, the
latter is how the device is seen on a local network such as WiFi.
upon receiving a comm message set_nodename, nd sets both lightning node
alias and hostname to that new name while applying restrictions such as
RFC 1123 for hostnames.
the lightning alias is written to lnd config file, regenerated and
persistent, after which the lnd daemon is restarted to pick up the
changes. network host name is changed by writing the name to
/etc/hostname and issuing "hostname <newname>" shell command.
while persisting operations are atomic, the whole sequence isn't.
in the latter case an inconsistency can be eliminated by sending a
set_nodename msg again.
the nd daemon also includes the OS hostname in the settings message when
sending it to ngui.
it broke after last commit where lnd client got moved into the lightning
module, preventing lndhc from importing it.
also, add lndhc to CI build to catch regressions like this early on.
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
ci/woodpecker/tag/woodpecker Pipeline was successfulDetails
the daemon can now identify which state lnd is in and report to the GUI
which displays different elements on the lighting tab, based on the
reported lnd state:
- startup in progress: displays spinner
- no lightning wallet: displays a "setup" button and guides the user
through a simple workflow
- reset an operational node
this means, the UI has now minimal but functional elements for any user
equipped with a smart phone to set up the lightning node without SSHing
in or using command line in general.
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
the "bitcoin" name is overloaded: everything's about bitcoin here.
a less confusing name is onchain to emphasize the difference w.r.t.
lightning or any other future L2 networks.
ci/woodpecker/pr/woodpecker Pipeline was successfulDetails
ci/woodpecker/tag/woodpecker Pipeline was successfulDetails
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
a previous commit added some lightning tab implementation which
including balance details but only for lightning channels.
this commit queries lnd for a wallet balance and displays it on the
bitcoin tab since "wallet" funds are on-chain and it doesn't feel like
it belongs to the lightning tab in the UI.
while there, also improved some daemon backend code style, alightning
with the lightning implementation structures.
ci/woodpecker/pr/woodpecker Pipeline was successfulDetails
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
similarly to 0260d477, the lightning tab has now some basic info
including channels list.
the gui playground is updated to send some stub data via comms
periodically.
similarly to 2642a554, this adds an lnd HTTP client able to make some
queries like getinfo. the daemon then uses the client to compose a
lightning status report and sends it over to ngui through comms,
periodically.
there's also a client playground built on demand with
"zig build lndhc".
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
while there's lots of changes and new features in zig v0.11.0, the most
important for this project at the moment is the HTTP client.
the client is most likely what will connect to lnd lightning node to
fetch stats and info for the UI to then visualize it on "lightning" tab,
similar to the bitcoind RPC client.
see all zig 0.11 release notes here:
https://ziglang.org/download/0.11.0/release-notes.html
the bitcoin tab has now some basic status and stats: parts of blockchain
info, network info and mempool. this is far from complete but makes a
good start for an initial version.
the gui playground is also updated to sent some stub info via comms
periodically.
this adds a very simple bitcoind RPC client able to make a few queries
like the blockchain and network status. the daemon uses the client
to get the bitcoind status and sends a report through comms periodically.
there's also a little playground program which simply dumps a query
result to stderr. built on demand with "zig build btcrpc".
ci/woodpecker/pr/woodpecker Pipeline was successfulDetails
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
most troubles were due to blocking nature of child process pipe
descriptions which made comm.read loops hang in various places
under certain conditions.
this commit moves all read/writes in separate threads to be able to
always watch for sig TERM and INT, and ensures child process pipes
are closed early allowing comm.read loops to terminate.
ci/woodpecker/pr/woodpecker Pipeline was successfulDetails
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
this greatly improves UX during shutdown: no need to guess at which
point it's ok to unplug the power cord.
the commit also includes a GUI playground. a sort of a fake daemon which
sends hardcoded messages to ngui. useful for manual debugging and trying
different UX scenarious.
alex