[Dxspider-support] FTx autogenerated spots

Tue Mar 18 13:46:35 GMT 2025

Dear Dirk,
I was quite sure about that!!!
Thanks!!!!

@Ciemon, yes I agree that the documentation is not the best, but the beauty
of DXspider is that we have the source code available. This is why I prefer
Dirk work to others.
So you are free to study, test, reverse engineer, improve, fork.

Regarding the filter, flooding limit, etc., well, I think that each sysop
has a certain level of freedom on how to serve his users.
Just think of the setting to filter badwords, baddx, badspotter and so on.
Any sysop can implement different lists.
I think that when you enter a shop you are not questioning why they sell X
and not Y.
If you don't like what they sell, go to the next door.

73s
Andrea iz2lsc

-->

On Tue, Mar 18, 2025 at 2:26 PM Dirk Koopman via Dxspider-support <
dxspider-support at tobit.co.uk> wrote:

> There will be a version of this in the next release.
>
> Dirk
>
> On 18/03/2025 12:51, IZ2LSC via Dxspider-support wrote:
>
> 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
>>
>
> _______________________________________________
> Dxspider-support mailing listDxspider-support at tobit.co.ukhttps://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/24daa6ee/attachment-0001.htm>