[Dxspider-support] Discussion: Informing Users About Registration Requirement for Spotting

Thu Mar 6 22:19:53 GMT 2025

My stance on this is simple.

Here’s my motd_nor….

I don’t force passwords on users and I have no intention to do so but this message clearly does get through as I generally have one or two requests a week for registration.  When I get a request, I check the callsign against qrz to make sure that it’s valid and that it appears to be relatively active.  I also search to see if that callsign has ever been spotted and whether it’s previously uploaded any spots.  I’m not looking for anything specific, just really trying to do some basic validation of the callsign. In all the time I’ve had registration, I’ve never rejected anyones request.

If anyone doesn’t like my policy and goes to a different cluster, that’s entirely up to them.  My bottom line is to provide a reliable service to anyone who wishes to use my node with good data and as many valid spots as I can.

73 Keith
On 6 Mar 2025 at 21:45 +0000, Grant via Dxspider-support <dxspider-support at tobit.co.uk>, wrote:
> Mikel,
>
> While I 100% support registration before you can post (i.e. you have contacted me and I have authorised you to be allowed to spot through my node), I don’t see value in taking the next step of adding a password for an end user. Many users do only want to read spots - and passwords prevent them accessing anything. I only feel the need to regulate the side that sends spots. I don’t have an issue with passive network consumption as passive consumption is not in any way able to be harmful.
>
> Rather than arguing about password protection and all of the user interface interaction problems that go with that because of the ways people access clusters, more effort from all of us needs to go into identifying how and where the bad actor is entering the network in the first place. That is why I asked what the protocol standard was. I was trying to understand how we can track and trace the perpetrator. Sorry Dirk, I did not deliberately set out to make more work for you either - but my enquiry came from the desire to really get to the root of the problem. The watchdbg logs surely hold the key to us tracing the network and despite it's distributed nature, we should still be able to trace the origins. To even begin to crack that, wider understanding of the protocol among the sysops is almost mandatory.
>
> Regards,
> Grant VK5GR
>
>
>
>
> -----Original Message-----
> From: Dxspider-support <dxspider-support-bounces at tobit.co.uk> On Behalf Of Mikel EA2CW via Dxspider-support
> Sent: Friday, 7 March 2025 5:49 AM
> To: dxspider-support at tobit.co.uk
> Cc: Mikel EA2CW <ea2cw at gautxori.com>
> Subject: Re: [Dxspider-support] Discussion: Informing Users About Registration Requirement for Spotting
>
> Thanks for your contribution, David. It can make us don't forget what are we spending our time for.
>
> Please, let me analyze it from, let's say, a "bussiness" point of view...
>
> A. What are we selling?: spots.
>
> B. What is our "market"? As you said, mainly aged amateur radio operators.
>
> We could somehow divide them in some types:
> - Serious contesters
> - Occasional contesters
> - DX hunters
> - Awards hunters
>
> C. How do we serve our "product"? Could be:
>
> 1. Directly to the "client" at telnet windows 2. Using several software interface apps.
>
> (I am sure that we all are aware that almost none use the 1st way, but the 2nd, by means of general logging, contesting or web apps.)
>
> D. What our "clients" want these spots for?
> I think they want to know WHERE and WHEN they can find some transmitting stations who interest them, in order to earn points of fill award slots.
>
> That could be -on a raw way- the panorama we have.
>
> E. What is the main problem we are facing now?
> The "product" we are giving to our "clients" lacks of a minimum quality level, because sometimes they cannot trust on the information we give them.
>
> By the way, I agree with you when you said that our clients (customers) are mainly aged, and like the rest of humankind, resistant to changes.
>
> On the other hand, I am sure that they are also used -very used- to have to type passwords in their "virtual" lives: e-mail accounts, banks, on-line commerce, etc.
>
> No one of these advances which are now normal in our every day life, would be possible today without passwords, and we use them often.
>
> As a smart man -Isaac Asimov- said in the 80's, those who do not know about computing, will become the illiterates of the future (that was 5 decades ago...)
>
> Don't worry! as amateur radio operators we are leaders on self-taught, science, communications, new technologies, et al... aren't we?
>
> Sorry!!! Let's return to our bussiness!
>
> Nowadays we are facing a problem, and we must find a solution.
> Otherwise, we will lose our "clients" trust, and they will be not our "customers" anymore.
> (Perhaps we have to be prepared to say goodbye to the assisted categories in the no CW/RTTY/FTx contests).
>
> Would we make the interface software developers include passwords like in other billion applicantions we use everyday and...
>
> Would we have to teach our customers about "how to enter a password" to be able -don't forget it- to UPLOAD (not to download) information to the network?
>
> Or, on the contrary, must we keep the things as they are, and say to developers and customers:
>
> "Sorry, if you don't want to change, be prepared to "swallow" garbage.
> We cannot guarantee the quality of the product you need to achieve your goals -spots- because we are afraid to include passwords, as we don't think you will be able to use them"
>
> Sometimes I recall past times when some in the amateur community were against SSB, FM, FT8, etc. because that implied changes...
>
> I think we would spend some time thinking carefully about all this, from a general POV, far from the noise we have on these times.
>
> 73, Mikel
>
> P.S. Don't forget that before all this revolution, we were asking only to use passwords between servers! Users' would (only would) be a second
> stage)
>
> El 6/3/25 a las 18:59, David Spoelstra via Dxspider-support escribió:
> > 1. I am a heavy user of the cluster.
> > 2. In 50 years, I have never posted a spot.
> > 3. With my current logging software, I never see the telnet interface.
> > I have a table with name, IP, Port, user name, and password.
> > Everything is pre-filled in except for password. I don't even know
> > where they get the list of nodes. I *can* change the table if needed.
> > 4. For those of you that wonder why you lose half your people when you
> > implement passwords, it's obvious to us that actually *use* the packet
> > cluster software rather than sit in front of it managing it from the
> > command line. WE DON'T EVEN KNOW YOU HAVE ADDED A MANDATORY PASSWORD!
> > We just know that _your node is no longer working_ so we just click on
> > the next node down in the table. I'll bet a lot of OMs wouldn't even
> > know
> > *how* to get on a telnet terminal and add a password anymore. From my
> > experience as a club president, they can barely run the software as it
> > is. Our most asked for monthly club topics now are how to use
> > different software packages. Our most asked technical questions are no
> > longer how to build an antenna, etc, they are "How do you do X in Y
> > software?" It actually feels more like I'm running a computer club than a ham radio club!
> >
> > I believe that if you really want to implement mandatory passwords,
> > you are going to have to _work with the logging program authors to
> > make it much easier for the users_. For example, in my software if I
> > just add a password in the table, it won't connect. I'm guessing that
> > the software is assuming that somehow I have already established a
> > password with the node.
> >
> > Remember, the average age of our users is getting older and older and
> > they are having trouble coping with new technology. I have people in
> > my club that buy new radios and then sell them because they are "too
> > complicated" and they can't run them. You would be amazed how many
> > people use SignaLinks with IC-7300s because they don't know or can't
> > figure out how to use the built-in soundcard interface in the IC-7300!
> > When I go over to their house and remove the SignaLink from their
> > setup they argue with me that they need it to run FT8. When I run FT8
> > without it, they are amazed and wonder why it wasn't made more obvious
> > in the software how to interface without a SignaLInk so they wouldn't
> > buy something they didn't need.
> >
> > _If you want mandatory passwords, then look at it from the end user's
> > perspective - not from you own bias of command lines and telnet
> > windows
> > - and make it much easier to implement from the end user's perspective
> > which means you are going to have to get the software authors
> > onboard._
> >
> > This is from the documentation of the DXLabs software (DXKeeper
> > specifically) - which from various tables like eQSL is one of the most
> > used softwares. "If you'd like to monitor spots from the N6WS, EI7MRE,
> > K1RFI, and JH1RFM DXClusters, enable them and repeat the above steps.
> > Like DX Spots, none of these DXClusters require a password, so you can
> > leave their Password textboxes blank; _specifying a password when none
> > is required may cause the login to fail_."
> >
> > -David, N9KT
> --
> 73 de Mikel Berrocal EA2CW-AE2CW
> Bilbao, Basque Country
> ea2cw at gautxori.com
> https://www.ea2cw.eus
>
>
> _______________________________________________
> 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/20250306/b45740c1/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: register.jpeg
Type: image/jpeg
Size: 29339 bytes
Desc: not available
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250306/b45740c1/attachment-0001.jpeg>