I’ve deployed the latest version of Nodus. The most notable changes:
Speed is improved on the code level + full HTTP/3 support
Filters for node list (@jenkin 's first feature request has landed )
Noticed that the Telegram MiniApp doesn’t open on Linux Desktop Telegram client. Fixed.
+Some “under-the-hood” optimizations and finally fixed the page flickering on loading (known UI bug from the beginning)
@jenkin
I’ve done some research about monitoring Zebra full nodes, it seems clear that it’s possible to integrate the full node monitoring as well. Will continue working in this direction. Usually, and in terms of security, the RPC ports are not exposed, so the basic info could be taken from P2P port.
Also, haven’t ever worked with Zakura. Is it really popular? Anyways, need to investigate more. Do you have any wokring Zakura node address?
add “Send a message” next to “Donate”
As I understand, anyone can send a text message to the node owner, right? So it should be something like “light” message exchange system (messenger)? If only when you send a message and need to get an answer. Otherwise, if it’s just like an emergency contact, it could be just a sending message form and receiver will get it via Telegram bot.
Added Zebra/Zakura standalone p2p nodes monitoring ability.
But there’s one “BUT”: p2p nodes has connections limit, so if it’s reached - the node assumed as failed. I’m thinking how can this case be improved, but this is the p2p nodes specialty of working.
Yes, and opening rpc port is not right in terms of the security. Need to think about some workaround.
But I can’t add my node as the configured 125 connections limit is reached, and if your node reaches configured connections limit it will be treated as offline
Since the nodes that get listed clearly want to be listed, I believe there should be an option in the RPC software itself that allows the node to ping proactively as opposed to a passive ping from you (which can also mask maintenance or planned downtime)
Do you think this will be adopted? If so, we can author a PR if you want.
As a node operator, I could add an option to my config to send events (startup, ping, shutdown) to an external service during operations. This external service (an harvester) should store events (with data attached) and show them on a frontend.
Very interesting!
If we now define some standards, both full nodes and indexers can implement it and an open source harvester can be a public centralized service or a private self-hosted one.
This way, people could also build custom “harvester” middleware in node management software as well, and the nodes can inform the manager via the same route. Two birds with one stone, I reckon!
The Idea of a “harverster” also good and has its place, and I think it worth to be implemented on Nodus as a separate part like working through API method which node operators are pinging from time to time. It’s like “I publish my node exists” giving the info about your node.
But here we have one fundamental difference. Monitoring gets info from nodes, so it can realistically gather the info about versions, uptime, etc.And non-existent node can’t be even added and if it becomes unavailable it’s immediately flagged on the system.
The “I publish my node myself” is a different thing, it means I see the list, but the list contains the info about nodes which operators pushed themselves. In this case, anyone can call that API methods and put everything they want: wrong version or even non-existent ip/domain (or even if it’s exits and you can’t connect to the node and prove that). So this information will not be complete, reliable and up-to-date.
??? In the case, what guarantee is there that the operator has not set a custom override for your probe’s IP to feed the same false information? If the operator is malicious, your existing model doesn’t work anyways?
Right, this is also reasonable.
But in the real world, the sending false API request a way easier than create a malicious node. I’m not deny that everything is possible.
We can do an experiment by adding a separate the self-maintained list of nodes pushed by operators via API, but this will also work only to share the nodes to the services which could use them. Monitoring from server-side and notifications about any issue is not supported for them in this case as the server should check. The only way I see here is to set any timestamp of inactivity from the node and if it’s reached the notification is sent to the owner.
Maybe I can register my node (as I can do now) and receive a secret for my api calls, so the harvester can link events with registered node. An alternative to api secret can be a signed event the harvester can validate.
Harvester can perform light check by itself (ie. nc -z <node address> <node ip>) other than receives events from node. We can define a well known event types (ie. startup, synced, shutdown, ping) based on node events (the formers) or time (the latter). Every event bring a data payload. Harvester can apply some heuristics to compute the status (ie. after 5 missing pings without a shutdown, then show offline).
A PoC that pings local healthcheck endpoint and send an event to a harvester should be quite simple to develop before thinking to a PR to real nodes or indexers repos.
)
Anyways, need to investigate more. Do you have any wokring Zakura node address?