[Dxspider-support] FTx autogenerated spots
Dirk Koopman
djk at tobit.co.uk
Thu Mar 20 16:32:12 GMT 2025
Apropos ftx
(on the test branch) is your friend (i.e. I've even done the help for
these commands).
But in answer to the question you asked: yes (in as much as it can,
given that I only look at the comments). The answer to the other
question "is this users or node"? users.
Dirk
On 19/03/2025 07:55, Keith, G6NHU via Dxspider-support wrote:
> Dirk, will enable/ftx and disable/ftx completely enable and disable
> all FTx spots?
>
> 73 Keith
> On 18 Mar 2025 at 21:50 +0000, Dirk Koopman via Dxspider-support
> <dxspider-support at tobit.co.uk>, wrote:
>> There is a new version available in the test branch. Please read the
>> Changes file. Hopefully that will make what’s happening clear.
>>
>> 73 Dirk
>>
>>> On 18 Mar 2025, at 20:47, 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 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
>> _______________________________________________
>> 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/20250320/e19f0c9a/attachment-0001.htm>
More information about the Dxspider-support
mailing list