[Dxspider-support] FTx autogenerated spots

Tue Mar 18 20:38:44 GMT 2025

Thanks Chris,

I know you'll support work on the wiki. But there are also a lot of people
here that have been doing this a lot longer than I have, they are equally
capable of editing a wiki.

---
Ciemon Dunville - GØTRT <https://www.qrz.com/db/G0TRT>
Warminster, Wiltshire. UK
CW Ops <http://www.cwops.org> #3429

On Tue, 18 Mar 2025 at 13:55, Christopher Schlegel <sutehk.cs at gmail.com>
wrote:

> You are absolutely correct, Ciemon. However, we can't sit back and expect
> Dirk to do all the documentation. We, as sysops, need to help. I took the
> liberty of putting a bit about the wiki in my MOTD to help advertise that
> location. I know you have helped me with the wiki and have put some effort
> in to remediating this issue.
>
> I'd say a good starting point to your questions would be to start a new
> thread with a topic question of "What should a new sysop know?" Compile a
> list of questions/issues and provide the answers.
>
> This is something I would gladly help out with.
>
> 73, Chris WI3W
>
>
> On Tue, Mar 18, 2025, 09:08 Ciemon Dunville via Dxspider-support <
> dxspider-support at tobit.co.uk> wrote:
>
>> Ah, in the lab, a good place to start.
>>
>> I guess that with a lot of this work that's going on here part of the
>> problem is that the users generally don't know.. anything, because cluster
>> practises (rather than the configurations discussed here) is not documented
>> anywhere useful.
>>
>> Why shouldn't 800 people connect to one node, why should 20 nodes spoke
>> off one, why shouldn't people spot and re-spot, why shouldn't we advertise
>> nodes through announcements, why shouldn't people flood-spot, why should
>> you contact a sysop before you try to establish a node-to-node link etc
>> etc. Are any of these things bad? Aren't they all?
>>
>> What is the webcluster strategy for the delivery of timely spots to the
>> world, by the world? Where is it stated?
>>
>> ---
>> Ciemon Dunville - GØTRT <https://www.qrz.com/db/G0TRT>
>> Warminster, Wiltshire. UK
>>
>>
>>
>>
>> On Tue, 18 Mar 2025 at 12:51, IZ2LSC <iz2lsc.andrea at gmail.com> 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 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/23c8b828/attachment-0001.htm>