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

[joaquin]

Hi,   
  

  
A certain Luigi. Dirk and Lee are essential, and their experience invaluable.
  
It would be interesting to know your opinion. Everything evolves, and we...
  

  
Regards,   
  

  
Kim
  

  

  
  
  
  
  
>   
> El 1 nov. 2022 en 22:29, Luigi Carlotto IK5ZUK  <ik5zuk at tiscali.it>  escribió:
>   
>   
>  Hello Kin,  
> your proposal is very interesting!I think it should be a good idea to  
> switch to a more secure network.  
>
> BTW it is important to know the opinion of the two software's  
> developers, Dirk and Lee...  
>
> 73 Luigi IK5ZUK  
>
> Il 16/09/2022 09:40, Joaquin via Dxspider-support ha scritto:  
> >  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  
> >   
> >   
> >  _______________________________________________  
> >  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/20221102/215474a2/attachment-0001.htm>