[Dxspider-support] FTx autogenerated spots

Tue Mar 18 12:51:29 GMT 2025

I Ciemon,
it was just a different approach, not yet implemented because I'm sure Dirk
could do something better.
I'm just doing some experiments on a lab node.

73s

Andrea
-->

On Tue, Mar 18, 2025 at 11:48 AM Ciemon Dunville via Dxspider-support <
dxspider-support at tobit.co.uk> wrote:

> 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
>>
> _______________________________________________
> 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/333e4a28/attachment.htm>