Skip to content

Expose node-invariant features via NodeStatus#810

Open
enigbe wants to merge 2 commits into
lightningdevkit:mainfrom
enigbe:2026-02-expose-node-features-api
Open

Expose node-invariant features via NodeStatus#810
enigbe wants to merge 2 commits into
lightningdevkit:mainfrom
enigbe:2026-02-expose-node-features-api

Conversation

@enigbe
Copy link
Copy Markdown
Contributor

@enigbe enigbe commented Feb 26, 2026 •
edited
Loading

What this PR does

For users interested in features announced in node_announcement, we make node_features available via Node::status().

The plan is to modify ldk-server's handle_get_node_info_request and make features available on GetNodeInfoResponse so that the node's supported features are available to any requesting client.

lnrpc and cln-grpc make these fields available in the response to get_node_info.

This is in relation to an exploratory sim-ln PR seeking to support/integrate ldk-node/server.

@ldk-reviews-bot
Copy link
Copy Markdown

ldk-reviews-bot commented Feb 26, 2026 •
edited
Loading

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@enigbe enigbe marked this pull request as draft February 26, 2026 12:49
@enigbe enigbe mentioned this pull request Feb 26, 2026
Open
tnull
tnull reviewed Feb 27, 2026
View reviewed changes
Copy link
Copy Markdown
Collaborator

@tnull tnull left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@enigbe enigbe force-pushed the 2026-02-expose-node-features-api branch from e1acc25 to 3ac1658 Compare March 17, 2026 13:55
@enigbe enigbe mentioned this pull request Mar 24, 2026
Open
@enigbe enigbe force-pushed the 2026-02-expose-node-features-api branch from 3ac1658 to 5a87041 Compare March 24, 2026 21:05
@enigbe enigbe marked this pull request as ready for review March 24, 2026 21:15
@enigbe enigbe changed the title Expose APIs to access node's supported feature flags Expose node-invariant features via NodeStatus Mar 24, 2026
@enigbe
Copy link
Copy Markdown
Contributor Author

enigbe commented Mar 24, 2026

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 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.

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.

I've just opened #841 in relation to this.

@ldk-reviews-bot
Copy link
Copy Markdown

ldk-reviews-bot commented Mar 26, 2026

🔔 1st Reminder

Hey @joostjager! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link
Copy Markdown

ldk-reviews-bot commented Mar 30, 2026

🔔 2nd Reminder

Hey @joostjager! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@tnull tnull removed the request for review from joostjager March 30, 2026 08:25
enigbe added 2 commits May 12, 2026 22:05
@enigbe
Expose node announcement feature flags
ead6a8c 
Expose the feature flags advertised by the node in its
node_announcement message via NodeStatus::node_features.

For UniFFI consumers, expose NodeFeatures as an object with BOLT 9 byte
encoding helpers and typed feature accessors.

This intentionally avoids exposing freestanding Node methods for init,
channel, invoice, or node feature contexts. Channel and invoice features
are context-specific, and exposing node-level helpers for them could be
confused with negotiated per-peer, per-channel, or per-invoice features.
Those negotiated feature surfaces are handled separately.
@enigbe
fixup! Expose node announcement feature flags
0668b4f 
Switch the UniFFI NodeFeatures exposure from a raw custom Vec<u8>
conversion to an object wrapper with BOLT 9 byte encoding helpers and
typed feature accessors.
@enigbe enigbe force-pushed the 2026-02-expose-node-features-api branch from 5a87041 to 0668b4f Compare May 12, 2026 21:30
@enigbe
Copy link
Copy Markdown
Contributor Author

enigbe commented May 12, 2026

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

For node features, I've decided to expose via NodeStatus and done some cleanup of the original FFI-exposed type. The PR ready for another review round.

@enigbe enigbe requested a review from tnull May 13, 2026 09:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@tnull tnull Awaiting requested review from tnull

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@enigbe @ldk-reviews-bot @tnull