[Dxspider-support] FTx autogenerated spots

Tue Mar 18 10:21:29 GMT 2025

Andrea,

I'm curious as to whether or not your rate limiting applies to your (you
only) 'OTA cluster? Or are you not forwarding spots into those systems?

Having just had a look, I can't see any mention of you rate limiting spots
on your cluster, it would be useful to understand your thinking/levels etc

73, Ciemon

---
Ciemon Dunville - GØTRT <https://www.qrz.com/db/G0TRT>
Warminster, Wiltshire. UK
Sysop @G0TRT-9

On Tue, 18 Mar 2025 at 08:46, IZ2LSC via Dxspider-support <
dxspider-support at tobit.co.uk> wrote:

> 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
>>
> _______________________________________________
> 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/6fe79d6b/attachment-0001.htm>