<div>Hi all.<br></div><div><br></div><div>Yesterday I released the first beta version of a plugin called go-lnmetrics.reporter available at <a href="https://github.com/LNOpenMetrics/go-lnmetrics.reporter" rel="noopener noreferrer" target="_blank">https://github.com/LNOpenMetrics/go-lnmetrics.reporter</a>. This plugin is able to collect some data in the node about the uptime information of it and all the friends. But a full description of the metrics is described in lnmetrics specification available at <a href="https://github.com/LNOpenMetrics/lnmetrics.rfc" rel="noopener noreferrer" target="_blank">https://github.com/LNOpenMetrics/lnmetrics.rfc</a><br></div><div><br></div><div>So, lnmetrics is designed to be a unique system to collect different type of metrics across lightning implementation, and report these data to an open-source server that gives the possibility to access the full metrics payload and have rating  that it is accessible throught API available at <a href="https://api.lnmetrics.info" rel="noopener noreferrer" target="_blank">https://api.lnmetrics.info</a>, and in the near future has also the possibility to analyze the metrics from a small UI <a href="https://lnmetrics.info" rel="noopener noreferrer" target="_blank">https://lnmetrics.info</a>. But the goal, for now, is to collect data in an open source way and try to understand if under this data it is possible to define some model.<br></div><div><br></div><div>The basic idea is that we don't want a trust system like 1ml or lightning terminal that give some hidden metrics on the goodness of the node, but we want to start to collect data from people that want to share this data and try to understand if it is possible to define some concept of goodness and help tools like clboss in order to do less work in the estimation of the goodness of one node. In addition, having global metrics can help us to have a standard of goodness across implementation, because right now there are tools that managed the various implementation, but the metrics could be different.<br></div><div><br></div><div>In conclusion, having a system able to store the history of the channels, such as failure rating, uptime of the node and the friend of the node gives us the possibility to make the right choice during the selection of one node to open a channel. Also, we could collect data about the feature supported, and the lightning implementation to avoid nodes that have some incompatibility with the protocol and can cause mistakes.<br></div><div><br></div><div>P.S': The lnmetrics specification is not a list of rules that all need to respect, but it is more like a collection of standard metrics description in terms of data collection and result calculated with this data. More important, there is no topic of these metrics, so anyone can push new metrics on any topic. For Example with this system, you can have the possibility to benchmarking the various implementation in a real-world environment and not in a theoretical way in a test env.<br></div><div><br></div><div>P.S'': The plugin is in rc1 release, so for this release, it will not change. However, I'm optimizing the server and starting to implement a rating system on the server, that will be available at the end of December. I think it is a good moment to propose this system and start to collect the data and more important catch bugs :)<br></div><div><br></div><div>Regards.<br></div><div><br></div><div>Vincent.<br></div><div><a href="https://github.com/vincenzopalazzo">https://github.com/vincenzopalazzo</a><br></div>