-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
discovery+lnwire: add support for DNS host name in NodeAnnouncement msg #9455
base: master
Are you sure you want to change the base?
discovery+lnwire: add support for DNS host name in NodeAnnouncement msg #9455
Conversation
Important Review skippedAuto reviews are limited to specific labels. 🏷️ Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
27e571d
to
3e93cdf
Compare
3e93cdf
to
cb36d26
Compare
cb36d26
to
fb721bc
Compare
fb721bc
to
4a8adcb
Compare
@@ -3437,6 +3437,9 @@ message LightningNode { | |||
|
|||
// Custom node announcement tlv records. | |||
map<uint64, bytes> custom_records = 7; | |||
|
|||
// The DNS hostname address of the node, if available. | |||
NodeAddress dns_hostname_address = 8; |
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.
why a new field for this if we already have an addresses
field above?
@@ -69,6 +69,10 @@ var updateNodeAnnouncementCommand = cli.Command{ | |||
Name: "color", |
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.
a suggestion for PR structure: it's a better pattern to do:
- add new logic internal to the server
- expose new logic of server via RPC
- start reading/using new logic from client
a nice way to think about it is: we always want to be able to revert back to any commit and have things make sense. But with this current order, if we reverted to this commit, we would have all these fields that the server is exposing and the client is writing to but it wont actually do anything on the server side which doesnt make sense
@@ -325,26 +325,28 @@ type Config struct { | |||
// loadConfig function. We need to expose the 'raw' strings so the |
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 commit is doing way too much.
- start with just
lnwire
(ie, "schema first" rule) and make sure to add the necessary tests around decoding/encoding there. Also, maybe i missed this but somewhere we need to check that our peers are not sending us more than 1 DNS address in their announcements (see bolt 7). - then slowly expand out from there, commit by commit to start using the new type.
each commit should be one unit of change that the reviewer needs to consider.
@mohamedawnallah, remember to re-request review from reviewers when ready |
Change Description
Closes #6337.
Closes #9126.
Steps to Test
Steps for reviewers to follow to test the change.
Pull Request Checklist
Testing
Code Style and Documentation
[skip ci]
in the commit message for small changes.📝 Please see our Contribution Guidelines for further guidance.