<div dir="ltr"><div dir="auto">Agreed on the update point...<div dir="auto"><br></div><div dir="auto">And I see your point on the likeness of the auto generation, but I'm going to play devil's advocate here. In the last week the K index has been horrible for barefoot and a wire operators leading to an increase in digital mode activity. I am one of these operators. Now, I don't care for auto generated spots and have it disabled as I feel that I can filter the spots better than just automagically letting it happen (my opinion). I am capable and educated (through effort) enough to do that. I understand the argument for general users and their capabilities, ignorance is not an excuse at some point. Perhaps an education campaign by sysops could help the situation, but that's a losing battle as well. Proven by Kin's efforts. Gives me the idea to put a link to the wiki in the MOTD.</div><div dir="auto"><br></div><div dir="auto">Most software that I have been exposed to will automatically spot (if set) when a contact has been logged. No different than an overzealous spotter at say a few spots a minute. The gotcha here is that the information is valid (as much as any manually entered spot) and authentic to the contact. Even during contests, if all QSOs were automatically spotted of even the best CW 2BSIQ operators you're looking at maybe 9 spots per minute by various call signs. 500 QSOs/hr / 60min = 8.33 spots/min (exaggerated for headroom)</div><div dir="auto"><br></div><div dir="auto">I think there is merit in the idea of rate limiting, at least in mitigating the effect of flooding. Websites and other software (thinking PSKReporter, rate limiting login attempts, etc.) do this all the time. The deduping algorithms employed in the cluster (haven't forgotten the bypass) do to some extent but not in the manner needed.</div><div dir="auto"><br></div><div dir="auto">Authenticity of spots is a separate issue to me. As you mentioned previously, the cluster is far too disparate and open to truly fix that issue while being inclusive to older technologies and formats. Again, we mirror the greater Internet at this point and trying to get everyone on board is like pulling teeth. Do we use the greater share that Spider nodes have to force a movement? Is it worth an essentially civil war at this point alienating older nodes? I don't think this is in the spirit of Amateur Radio nor is keeping everything a secret by way of going closed source. I applaud Dirk's efforts here in adhering to the spirit. If someone used my radio gear to broadcast a commercial transmission, would I not have the responsibility to prevent that and suffer the consequences that follow? </div><div dir="auto"><br></div><div dir="auto">Sysops need to wake up and pay attention. These attacks are coming from somewhere, there has to be a way to find the holes and do what we can to patch them. My personal opinion is that I provide a service and compromising that to solve a problem is the easy way out. I would respectfully request that these changes remain optional so that I can provide the service to users the way I believe it should be. Some other sysops have already filtered out FTx spots on their nodes and advertise them that way. I do not filter announcements so any user that would prefer that, is able to see them and make that choice for themselves.</div><div dir="auto"><br></div><div>It has been danced around on this list and I'm just going to go and outright say it...sysops that are absent or apathetic perhaps need to be disconnected as a warning or make their nodes inaccessible to the public. A culling of sorts to prune the dead weight and reduce the vulnerable attack surface. This I feel is the real vulnerability of the system that gets exploited. Checking in once in a while or paying attention to communication from a group that a sysop directly affects is the first and foremost thing we can do to cooperate on keeping things healthy. I for one will keep paying attention in hopes of finding that slip that lets us figure out the hole and I will continue to work with other sysops here in that effort.</div><div><br></div><div>As always, I am not a developer, but I will respect the decisions of the group and the developer who has so graciously spent his time providing the software needed to provide this service to the hobby.</div><div><br></div><div>73, Chris WI3W</div><div><br></div><div>Sorry for the rant like prose, but a call to arms is needed...</div><div><br></div><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon, Mar 17, 2025, 18:58 Dirk Koopman <<a href="mailto:djk@tobit.co.uk" rel="noreferrer" target="_blank">djk@tobit.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Which is the place that I am coming from. Maybe, in this case, on somewhat specious grounds but is precisely in the light of the recent uptick in <br>
attacks on the network that caused me to do this. <br>
<br>
Please bear in mind that the network was recently used to promote and facilitate someone’s commercial activity by sending genuine (looking) spots by irregular means. But ignoring the whys and wherefores of the circumstances: consider the nature of the generation. The majority of those spots were automatically generated by design. Just like these spots AND they too were then modified by some people to get around the filters - just like the spots causing the recent flooding. <br>
<br>
They were designed to affirm rather than inform the user. The system generated them rather than the user. As sysops and I struggled to contain the flood, and the resulting vendetta that ensued, caused even more problems and has led me to conclude that any automated spots are to be discouraged or removed.<br>
<br>
Some years ago I had a similar spat with an author about automated FTx spots. Which went nowhere. The volume may not be the same but these spots annoy many, many users when they appear in large runs as they did (for a time) this afternoon. Hence this little  experiment. <br>
<br>
Users are not literate enough to (force their user programs to) create filters for themselves*. Either I have to provide a mechanism or sysops have to each create a local command / filter to do it for them. <br>
<br>
Anyway I shall be merging the test branch tomorrow (with this feature switched off) and I’ll do something about a user version as well (maybe disable/ftx) with a sysops function to allow or disable Ftx spots for users as well. Maybe that will mean that the nodes running very old software offering this as a selling point might upgrade. Sigh. <br>
<br>
73 Dirk G1TLH<br>
<br>
* In the last couple of days I have had a request from a user to fix his filters for Hamclock.<br>
<br>
> On 17 Mar 2025, at 19:19, Christopher Schlegel <<a href="mailto:sutehk.cs@gmail.com" rel="noreferrer noreferrer" target="_blank">sutehk.cs@gmail.com</a>> wrote:<br>
> <br>
> Flooding, providing false info, or other abuses to the cluster is our domain as it directly relates to the above sysop responsibilities. <br>
</blockquote></div></div>
</div>