[Dxspider-support] FTx autogenerated spots

Tue Mar 18 08:40:55 GMT 2025

Because I don't tolerate serial spotters (human or robot, SSB or DATA or
CW), my approach is different and radical.
If a spotter exceeds a threshold of spots/m it is blacklisted for a certain
time.

73s

Andrea, iz2lsc

-->

On Tue, Mar 18, 2025 at 3:28 AM Christopher Schlegel via Dxspider-support <
dxspider-support at tobit.co.uk> wrote:

> Agreed on the update point...
>
> 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.
>
> 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)
>
> 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.
>
> 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?
>
> 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.
>
> 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.
>
> 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.
>
> 73, Chris WI3W
>
> Sorry for the rant like prose, but a call to arms is needed...
>
>
> On Mon, Mar 17, 2025, 18:58 Dirk Koopman <djk at tobit.co.uk> wrote:
>
>> 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
>> attacks on the network that caused me to do this.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 73 Dirk G1TLH
>>
>> * In the last couple of days I have had a request from a user to fix his
>> filters for Hamclock.
>>
>> > On 17 Mar 2025, at 19:19, Christopher Schlegel <sutehk.cs at gmail.com>
>> wrote:
>> >
>> > Flooding, providing false info, or other abuses to the cluster is our
>> domain as it directly relates to the above sysop responsibilities.
>>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250318/3832a34b/attachment.htm>