Currently anyone with the NETSTATS_SECRET can connect and send any information that they want. We have trusted.json, which manually corrects/supplements limited node information (mostly for geo coordinates), but does not validate data. We should support more strict control over access by allowing or blocking by IP.
One option would be to just treat trusted.json as an 'allowed' list, and to not accept connections from any other IPs. This is the simplest change - some lists would need to be updated and each new node would need to be added, but spammers would be blocked by default.
Another option would be to support a 'block' list, and still continue accept other IPs which are not 'blocked' or 'trusted' but which have the correct NETSTATS_SECRET. This change is a bit more complex, but does not require updating any current trusted lists or as new nodes are added. One downside is that it requires reacting to spammers, rather than blocking them by default.
I'm partial to 1. The change is minimal for us to react to, and not an unreasonable burden on other users. We could even soften it by putting it behind a --strict mode flag, so we're not actually breaking API.
Currently anyone with the NETSTATS_SECRET can connect and send any information that they want. We have
trusted.json
, which manually corrects/supplements limited node information (mostly for geo coordinates), but does not validate data. We should support more strict control over access by allowing or blocking by IP.One option would be to just treat
trusted.json
as an 'allowed' list, and to not accept connections from any other IPs. This is the simplest change - some lists would need to be updated and each new node would need to be added, but spammers would be blocked by default.Another option would be to support a 'block' list, and still continue accept other IPs which are not 'blocked' or 'trusted' but which have the correct
NETSTATS_SECRET
. This change is a bit more complex, but does not require updating any current trusted lists or as new nodes are added. One downside is that it requires reacting to spammers, rather than blocking them by default.I'm partial to 1. The change is minimal for us to react to, and not an unreasonable burden on other users. We could even soften it by putting it behind a
--strict
mode flag, so we're not actually breaking API.