-
Notifications
You must be signed in to change notification settings - Fork 912
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
plugin: Allow plugins to register featurebits #3477
plugin: Allow plugins to register featurebits #3477
Conversation
f3b6c9b
to
7a58594
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great !
Open Questions
- We could push new featurebits when plugins get added or removed.
If this can be done "just" with another message to connectd
, I think that's preferable (I mean ratio added complexity / usability) ?
b6af69c
to
41e2174
Compare
Currently fighting against travis-ci (as usual)... |
637c36e
to
eecdccc
Compare
It'd also mean we need to have a way to notify |
Had to add #3479 as a dependency since |
1c38144
to
ebe8e13
Compare
I suggest requiring |
129354f
to
fd8d137
Compare
Rebased and squashed. I also decided to punt the dynamic issue by forcing plugins to be non-dynamic if they register featurebits for now. |
Should be good to go. Ping @rustyrussell and @niftynei |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is sweet!! my comments are mostly clarification asks.
ACK fd8d137
- We could push new featurebits when plugins get added or removed.
regarding the 'should and if so how do we update the values for features' the "push on change" option strikes me as the most reasonable, given the frequency of a plugin removal/addition vs frequency of sending init
messages (we'd also need a way to update node_anns
)
@@ -810,14 +813,17 @@ static void plugin_manifest_timeout(struct plugin *plugin) | |||
fatal("Can't recover from plugin failure, terminating."); | |||
} | |||
|
|||
/* List of JSON keys matching `plugin_features_type`. */ | |||
static const char *plugin_features_type_names[] = {"node", "init", "invoice"}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it might be nicer to co-locate these names with the enum declaration, so if the enum set changes it's easy to see/update the type names
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, unf. that has to be in the header, and this really wants to be here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to keep this here, so we don't overexpose internal things. I added a comment in the header to also update this array if changing the enum
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack, minor feedback only. Might do it myself in fact, depending on what else is needed pre rc1...
we have 4 venues in which we can add features, 3 of which are unilaterally controlled (`init`, `node_announcement`, and `invoices`) the `channel_announcement` is co-signed by both parties, so we can't add featurebits without additional coordination overhead. Each location is encoded as a key-value pair in a dict called `featurebits` in the manifest (omitted if no custom featurebits are set).
Feedback from @niftynei and me; nothing major, but avoids another round-trip. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
fd8d137
to
f9dd252
Compare
Rebase and simple additional fixup commit. |
ACK 282c5f2 |
We'll collect the featurebits on-demand from all currently active plugins when needed.
We will be doing this when collecting featurebits from the plugins, so make this a reusable function.
The `init_featurebits` are computed at startup, and then cached indefinitely. They are then used whenever a new `init` handshake is performed. We could add a new message to push updates to `connectd` whenever a plugin is added or removed, but that's up for discussion.
This is the last venue we need to add custom featurebits to, so we also unmark the test as xfail. Changelog-Added: plugin: Plugins can now signal support for experimental protocol extensions by registering featurebits for `node_announcement`s, the connection handshake, and for invoices. For now this is limited to non-dynamic plugins only
This is in order to avoid having to update featurebits as plugins get activated and deactivated.
Feedback from @niftynei and me; nothing major, but avoids another round-trip. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
f9dd252
to
282c5f2
Compare
With the
htlc_accepted
hook merged (#2267), in conjunction with thesendonion
RPC method (#3260), and the recently mergedcustommsg
support(#3315), plugins can now extend the lightning protocol using custom
extensions:
sendcustommsg
method and the associatedcustommsg
plugin hook allowplugins to communicate directly with connected peers.
sendonion
and thehtlc_accepted
hook allow plugins to deliver andreceive custom payloads to non-peers, over multiple hops, by encoding them
in the onion.
The missing piece in these cases is a way to signal support for these custom
protocol extensions. This is what we address in this pull request: we allow
plugins to register featurebits that should be mixed into the featurebits that
are handled in
lightningd
natively.We support 3 locations for featurebits:
node_announcement
init
messagesIn addition the specification would allow for featurebits in
the
channel_announcement
, however I decided against implementing that fornow, since the features would need to be negotiated between the endpoints and
I could not come up with a use-case that is not already covered by the
invoices featurebits or the
node_announcement
featurebits. It should betrivial to add them after the fact if we find a use-case.
The plugin can register featurebits as part of its manifest, so it cannot
dynamically add or remove features, and the featurebits are cached in
connectd
andgossipd
. Starting / stopping plugins may result infeaturebits not being added to those two daemons or featurebits still being
announced despite the plugin that registered them no longer being
available. See open questions below.
Todo
doc/PLUGINS.md
documentation to include an example of thenew manifest fields.
Open Questions
init
message or create a
node_announcement
, or is it ok if these are alittle bit stale? The current "set-once" option is simple, but may
advertise features that are no longer available. There are a number of
ways to tackle this:
- We could push new featurebits when plugins get added or removed.
- We could pull featurebits whenever a message is created.
- We can mandate that plugins registering featurebits must be
dynamic = false
, preventing changes to featurebits after startup.Depends #3479