[Dxspider-support] FTx autogenerated spots

[Christopher Schlegel]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250317/a34bba06/attachment-0001.htm>