[Dxspider-support] Network v2.0 - A PROPOSAL FOR DISCUSSION

[Joaquin]

Hi all,

We have all seen the offensive spots that have been being sent to the 
Net. Others know that in WW contests, malicious spots are sent in order 
to cause the disqualification of an operator or team in that contest. We 
also know that if an authentication policy is not applied in our nodes, 
this will continue to happen and the sysops will always follow behind 
trying to block the alleged offenders, but not only are we late because 
the spot has already spread, in addition, the spotter is usually an 
unassigned callsign or worse still, from an operator that is not the one 
that actually sent that garbage. The bad thing is that we block those 
operators without knowing if they are the cause.
We also know that many of the nodes are not updated, so new features and 
bug fixes are not applied to them. This makes it impossible for the 
current network to evolve to a more secure and reliable one.

How can progress be made without the collaboration of the sysops 
community? An answer to this question may be this draft:

Let's say the current Network is v1.0 and the new one will be called v2.0.

The Network v1.0 remains as it is today.
The new Network v2.0 would be an evolution of v1.0 in such a way that a 
series of functions would be incorporated:
1. Every connection (user-node, node-node) would be with login/password 
authentication to be able to use the sending of information.
2. The information of all users and nodes will always be at least 
username, password, email if they are registered/validated.
3. Passwords will be stored encrypted (eg in MD5).
4. In order for a user registered/validated by a sysop on your node to 
access any other v2.0 Network, this information will be sent to all v2.0 
nodes.
5. In the case of DXSpider, the current logging mechanism should allow 
sending an email to the sysop.
6. A new command should be included that allows the sysop to send a 
message (email) indicating that a certain user who is registered in the 
v2.0 Network has broken the rules and that he proposes that he be 
blocked/eliminated from the nodes.

For both networks to cohexist initially:
v2.0 <-> v2.0. Network v2.0 nodes with other v2.0 nodes will send and 
receive the same information as they do now.
v2.0 <-> v1.0. In the case of Network v1.0 nodes that connect to v2.0 
nodes, the former will continue to function as before, but v2.0 nodes 
will only maintain the link up, receiving the spots, ann, .. ., but 
since v2.0 spots will not be sent, ann, ...
v1.0 <-> v1.0. The interconnection between nodes of the Network v1.0 was 
safe as before.

The idea is that the v1.0 nodes converge on the v2.0 Network without 
being isolated, progressively disappearing when they realize that they 
do not receive all the spots and their software is not updated.

 From a developer point of view, I think it would be possible to use 
newer PCxx and CCxx with less impact if current software can be adapted. 
And with some modifications for the current v1.0. But it is still a job 
that takes time and effort.

For this to work, the involvement of cluster developers and sysops is 
necessary, especially those that have more users and therefore can exert 
indirect pressure to promote change.

What do you think of this proposal?
Possible improvements?
Infeasibility?
Alternatives?

Regards.

Kin EA3CV

sysop EA3CV-2, EA4URE-2,3,5