Monitoring feature #1245
Monitoring feature #1245
Conversation
|
Hey @OriolRoura, good job! I would love to review this PR, but please consider splitting it into smaller commits to make the review process easier. Additionally, instead of merging from master, try rebasing when there are new commits. |
This feature introduces the ability to monitor communications between Lightning nodes on a Polar test network. It can be enabled during the creation of a new network. To facilitate monitoring, a new modal interface has been added for controlling and viewing the results. Additionally, new Docker containers—currently hosted on my Docker Hub—have been integrated into the Docker network. These containers are responsible for performing the actual monitoring
OriolRoura
force-pushed
the
monitoring-feature
branch
from
a677dba to
57756ff
Compare
|
Hello @Abdulkbk, I'm not sure how to break the project into functional commits. I have only two main parts:
Originally, I developed this project using an older version of Polar on an independent project. When I first started, the current version had a compilation error. In this fork, I'm applyinig all the changes from the original project to the current version of Polar. Do you want me to split the commit in this two parts? Or do you want me to do in a diferent way? |
|
Hey @OriolRoura thanks for submitting this PR. I agree with @Abdulkbk that the commit structure here makes it pretty difficult to review this. This is a pretty large diff and almost all of the changes are in the first commit. In general, you want your commits to be broken up into small, logical chunks of functionality that can be reviewed independently. It's not expected to have the feature fully functional in each commit, but they should tell a story about how the different parts combine to make the whole. #1159 is an example of good commit structure. It's slightly smaller than this PR but is similar in that it adds a new docker container to the compose file and has UI changes to as well. But before you work on the commits, can you briefly describe the reasons why you want to monitor the traffic between LN nodes? I've been working on LN apps for a while now and have never had the need to analyze the communication at the packet level. I'd like to understand the benefits of having this functionality baked into Polar. |
|
I developed this feature because I couldn’t find any existing tool that provides easy access to Lightning communication on a network level. My initial motivation was personal. I needed it to track network communication for a research project trying to identify the lightning messages in the network and decrypt them. You can find the project at OriolRoura/LightningDecryptor This feature is fully optional; it can be enabled or disabled when creating a new network, so users who don’t need it won’t be affected. |
Adds abstractions and logic for file operations and network management. This functionality allows communication between Polar and the lnd nodes.
Updates Docker orchestration logic to support custom monitoring containers in Polar networks. composeFile.ts: Adds logic to include monitoring services in the Docker Compose configuration. dockerService.ts: Extends Docker service management to handle monitoring containers. nodeTemplates.ts: Provides templates for monitoring containers, enabling their integration.
Updates store models and type definitions to support: The monitoring modal The monitoring-enabled network state.
Adds UI components and integrates a monitoring modal into the network. This modal allows the control of the monitoring.
Adds translation strings for all new UI elements and modal controls related to network monitoring. Some languages were translated automatically using a translation tool.
Adds tests and mocks to ensure correct behavior and reliability of the network monitoring feature. Existing tests were updated to remain compatible with new functionality.
Updates dependencies and configuration files required for the new monitoring functionality.
A mock I forgot to include on the testing commit.
…lar-monitoringFeature into monitoring-feature
|
Concept ACK
For projects related to privacy analysis this would be great see for example Fingerprinting LN Nodes; which uses network traffic analysis to discover which implementation your peers are running.
Maybe for a LN apps dev point of view is not an useful tool, but for research projects it surely is. And even more if it shows the content of the network packages decrypted and in plain text. @OriolRoura does this PR enable this? |
|
At the moment, the PR doesn't support decrypting packages exchanged between nodes. I managed to get decryption working by modifying the node itself, but I'm aiming for a cleaner solution that avoids altering the nodes directly. |
4 participants
Description
This function introduces the ability to monitor communications between Lightning nodes in a Polar test network. It can be enabled during the creation of a new network. To facilitate monitoring, a new modal interface has been added to control and view the results. Additionally, new Docker containers—currently hosted on my Docker Hub—have been integrated into the Docker network. These containers are responsible for carrying out the actual monitoring
Steps to Test
Screenshots