commands: cli commands for sendonionmessage and subscribeonionmessage

[Abdulkbk]

Change Description

Add lncli commands for the SendOnionMessage and SubscribeOnionMessages RPCs that were introduced in #9868.

• sendonionmessage: Sends an onion message to a peer, accepting --peer, --path_key, and --onion flags (all hex-encoded).
• subscribeonionmessage: Subscribes to incoming onion messages from peers, printing each received message as JSON.
• Rename the lncli annotations in the proto from sendonion/subscribeonion to sendonionmessage/subscribeonionmessage to match the actual command names.

The commands follow the same pattern as the existing sendcustom/subscribecustom commands in cmd_custom.go.

[gemini-code-assist]

Summary of Changes

Hello @Abdulkbk, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the command-line interface for the Lightning Network Daemon (LND) by integrating new commands for sending and subscribing to onion messages. These additions provide users with direct lncli access to the previously implemented onion message RPCs, streamlining the process of interacting with this privacy-preserving communication feature. The changes ensure consistency in command naming across the system and update relevant documentation.

Highlights

• New lncli Commands: Introduced lncli commands sendonionmessage and subscribeonionmessage to interact with the previously added onion message RPCs.
• Send Onion Message Functionality: The sendonionmessage command allows users to send onion messages by specifying the peer, path key, and onion payload, all of which are expected to be hex-encoded.
• Subscribe to Onion Messages: The subscribeonionmessage command provides a real-time stream of incoming onion messages, outputting each received message as JSON.
• Annotation Renaming: Updated lncli annotations in protocol buffer definitions and generated files from sendonion/subscribeonion to sendonionmessage/subscribeonionmessage for consistency.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• cmd/commands/cmd_onion_message.go
  • Added a new file to define the sendonionmessage and subscribeonionmessage CLI commands.
  • Implemented the sendOnionMessage function, including hex decoding for input parameters.
  • Implemented the subscribeOnionMessage function to establish a stream for receiving and printing incoming onion messages.
• cmd/commands/main.go
  • Integrated the newly defined sendOnionMessageCommand and subscribeOnionMessageCommand into the main lncli command list.
• docs/release-notes/release-notes-0.21.0.md
  • Added a release note entry announcing the new lncli commands for SendOnionMessage and SubscribeOnionMessages.
  • Included 'Abdulkbk' in the list of contributors.
• lnrpc/lightning.proto
  • Renamed the lncli annotation for SendOnionMessage from sendonion to sendonionmessage.
  • Renamed the lncli annotation for SubscribeOnionMessages from subscribeonion to subscribeonionmessage.
• lnrpc/lightning.swagger.json
  • Updated the summary field for the /v1/onionmessage endpoint to reflect the lncli: sendonionmessage annotation.
  • Updated the summary field for the /v1/onionmessage/subscribe endpoint to reflect the lncli: subscribeonionmessage annotation.
• lnrpc/lightning_grpc.pb.go
  • Modified the lncli comments in the LightningClient and LightningServer interfaces to sendonionmessage and subscribeonionmessage respectively.

Activity

• The pull request introduces new lncli commands and updates related documentation and protocol definitions.
• No specific review comments or discussions are available in the provided context.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces lncli commands for the SendOnionMessage and SubscribeOnionMessages RPCs, which is a great addition for interacting with onion messages. The implementation is straightforward and follows existing patterns in the codebase. I've provided a few suggestions to improve error handling and adhere to the project's style guide regarding function documentation. Overall, the changes are well-implemented.

[saubyk]

Hi @Abdulkbk I am not certain that exposing these RPCs as cli to end users is a good idea.

AFAIU these RPCs should be for internal usage within the code for the extremely specific purpose of requesting a Bolt12 invoice from a node. Surfacing them to end users in such way can potentially open up the feature for other uses which we may not want to encourage.

I am not sure that this is the best defense to limit the use of these RPCs, but we would at least not like to make it easy on LND.

[Abdulkbk]

Hi @Abdulkbk I am not certain that exposing these RPCs as cli to end users is a good idea.

AFAIU these RPCs should be for internal usage within the code for the extremely specific purpose of requesting a Bolt12 invoice from a node. Surfacing them to end users in such way can potentially open up the feature for other uses which we may not want to encourage.

The reason I thought it was a good idea is that both Eclair and CLN expose equivalent CLI commands (sendonionmessage and injectonionmessage, respectively). Since the RPCs are already available on the public Lightning service, I don't think adding the CLI would hurt LND. Additionally, CLI commands are essential for testing and debugging during development. Without them, anyone working on onion message features has to write custom gRPC client code just to manually test basic send/receive flows.

I am not sure that this is the best defense to limit the use of these RPCs, but we would at least not like to make it easy on LND.

There are discussions in the PR to limit the use of these RPCs, similar to other implementations that ratelimit and provide config policies for forwarding onion messages.

[lightninglabs-deploy]

@Abdulkbk, remember to re-request review from reviewers when ready