Why does NoiseTorch require Internet access?

[smkuehnhold]

Howdy,

Until today, I was not aware that NoiseTorch required an Internet connection to work (ran into github rate limits). Not knowing this program very much outside of the users perspective, I want to know why? Also, will it be possible to remove this requirement in future versions of NoiseTorch?

(mostly unrelated) BTW I'm not sure if it is such a good idea to autorestart the systemd service on failure (as recommended in the wiki). If you run into the issue with the rate limits as I did, I think it is very possible you will unknowingly continue to query GitHub's servers (and remain rate limited). I think this is what happened to me today.

Thanks,
smkuehnhold

[AXDOOMER]

NoiseTorch requires internet access so that it can know if an update is available, if it detects a newer release on Github, it will show you that an update is available. Being rate limited shouldn't cause you any problem, it's normal as NoiseTorch contacts Github's API without using an access token.

[smkuehnhold]

Thanks for the quick reply :)

NoiseTorch requires internet access so that it can know if an update is available, if it detects a newer release on Github, it will show you that an update is available

Is there any danger in giving the user an ability to keep an older version? Thinking about systems (like some of mine) that do not have persistent connection to the internet...

Being rate limited shouldn't cause you any problem, it's normal as NoiseTorch contacts Github's API without using an access token.

I wouldn't normally argue this because I really am ignorant, but I was simultaneously encountering a similar problem with another program because my IP was softblocked/rate-limited by GitHub (thankfully the error for this other program was explicit about the rate limiting, wouldn't have checked otherwise). Killing the NoiseTorch service immediately fixed both issues... which seems too coincidental. But again, I am ignorant.

Thanks,
smkuehnhold

[ZyanKLee]

I agree, that this feature is not implemented perfectly and should be revamped with some more thoughts on such use-cases (100% offline-usage, checking for internet-availability and fallback to not checking for updates when there is none, waiting some time before the next update check even when NT is restarted, etc).