[Dxspider-support] FTx autogenerated spots

Wed Mar 19 09:04:15 GMT 2025

I must, you must, He must....

Did you sign a service contract with users connected to your node?
I'm providing access to my node as a "best-effort", for free, as is. I
don't have any commercial interest and any obligations, apart from my
ethics.
And my ethic is: do whatever is needed to provide accurate good spots,
mitigating flooding and spam.

Cheers

Andrea, iz2lsc

-->

On Tue, Mar 18, 2025 at 9:47 PM Ciemon Dunville via Dxspider-support <
dxspider-support at tobit.co.uk> wrote:

> Andrea, and everyone else,
>
> We should be empowering the users, not quietly restricting them. If you're
> throttling (or planning on throttling) users you must tell them, and tell
> them why. They should be aware that there is a chance they'll be getting a
> reduced service from your cluster, and if they understand the limitations
> and why they will be in a position to understand and act.
>
> ---
> Ciemon Dunville - GØTRT <https://www.qrz.com/db/G0TRT>
> Warminster, Wiltshire. UK
>
>
>
>
> On Tue, 18 Mar 2025 at 14:14, IZ2LSC via Dxspider-support <
> dxspider-support at tobit.co.uk> wrote:
>
>> 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
>>>
>> _______________________________________________
>> 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/20250319/d7d21c32/attachment-0001.htm>