Expose node-invariant features via NodeStatus#810
Expose node-invariant features via NodeStatus#810enigbe wants to merge 2 commits intolightningdevkit:mainfrom
Conversation
|
I've assigned @joostjager as a reviewer! |
There was a problem hiding this comment.
I'm not convinced we should expose this as freestanding APIs. Note that for channels and invoices these might also might be confusing as people really would be interested in the negotiated features, not what we generally, maybe support.
I guess we could consider to find a way to expose the invariant node features via an API (or maybe Node::status) if that would be useful, but for channels we should do #305 and maybe expose features in a sane way through list_channels. But note all of this should also work in bindings, so reusing LDK types might be challenging.
e1acc25 to
3ac1658
Compare
With this, we can read the features supported by the node as announced in node and channel announcements, within an init message, and within a BOLT 11 invoice. We write a small integration test to assert that, at minimum, certain features are supported by default, for example, keysend support.
This fixup moves node feature exposure from freestanding APIs to NodeStatus, as suggested in review. Rather than exposing init_features(), channel_features(), bolt11_invoice_features(), and node_features() as separate public methods on Node, this embeds NodeFeatures in the NodeStatus struct returned by Node::status(). Additionally, channel and invoice features at node level are confusing. Users would expect negotiated per-peer/channel/invoice features, not what the node generally supports. Access to negotiated features are addressed in lightningdevkit#841
3ac1658 to
5a87041
Compare
I agree too. I only added them after reviewing cln-grpc and thought parity with them (on ldk-server) would make sense. I've removed the free-standing APIs.
I've just opened #841 in relation to this. |
What this PR does
For users interested in features announced in
node_announcement, we make node_features available viaNode::status().The plan is to modify
ldk-server'shandle_get_node_info_requestand make features available onGetNodeInfoResponseso that the node's supported features are available to any requesting client.lnrpcandcln-grpcmake these fields available in the response toget_node_info.This is in relation to an exploratory
sim-lnPR seeking to support/integrateldk-node/server.