Grandfathering as base security model

[ea1het]

Hi there,

As explained [in the docs] the base security model for Radio Cluster DX (RCLDX) is a model of grandfathering. This is a social control mechanism over unwanted behaviours and manners inside a community where no central point of authority exists. Instead of relying on classic “admin/moderator policing”, responsibility is distributed: each user is indirectly validated by the trust of others.

In practice, every operator needs at least two “grandfathers”, two active members who vouch for their presence and behaviour on the cluster. If both drop their support, the operator automatically falls back to a read-only / anonymous mode. It’s simple, lightweight, and avoids the need for heavy identity management, password resets or complex token infrastructures.

The idea is not new. It appears in open-source communities, small federated networks and even in traditional ham radio culture where reputation follows callsigns across bands and decades. What RCLDX tries to do is formalise that logic just enough to discourage abusive behaviour (spoofing, deliberate QRM, trolling, flooding, fake spots, etc...) without becoming an intrusive or bureaucratic system.

What do you think?

• Is “social trust” a strong enough foundation for access control in a global ham-radio cluster?
• Should the system add extra layers (rate limits, behavioural scoring, optional mTLS, etc...) or is the social layer enough?
• And how would you balance openness vs. abuse-prevention in a world where callsigns can be spoofed over the air just as easily as over MQTT?

Curious to hear your thoughts, especially from people running club nodes or who have experienced abuse on existing clusters.

Thank you.
VY 73 DE EA1HET . .

[EA3CV]

Hola,

He leído la documentación publicada sobre el proyecto RCLDX y, sin duda, considero que se trata de una iniciativa ambiciosa, con un enfoque claramente disruptivo respecto al modelo actual de la Red de DX Clusters.

No obstante, me ha resultado llamativo haber tenido conocimiento del proyecto de manera casual y no a través de los canales habituales utilizados históricamente por la comunidad de sysops y operadores de DXCluster, especialmente considerando la magnitud e impacto potencial del cambio que se propone.

En la documentación revisada, observo que no se hace referencia a DXSpider, que es el proyecto Open Source con mayor implantación, difusión e influencia en la infraestructura actual de DXCluster a nivel mundial. Sin embargo, sí se menciona VE7CC, un sistema que, en la práctica, parece encontrarse en vía muerta en la actualidad.

Otro aspecto que me ha llamado la atención es el peso otorgado al papel de los clubes dentro del nuevo modelo organizativo. La experiencia acumulada durante décadas indica que la continuidad, estabilidad y expansión de la Red ha dependido principalmente del trabajo de los sysops (evidentemente no de todos, pero sí de un número significativo), que han mantenido y desarrollado la infraestructura de forma sostenida, con contadas excepciones a nivel de clubes.

Dado que el proyecto plantea una sustitución del modelo actual y establece una jerarquía organizativa definida, considero relevante plantear si se ha valorado la implicación de la IARU como entidad de referencia a nivel internacional en aspectos de coordinación, gestión y supervisión global, dada su legitimidad y rol histórico dentro del ámbito radioaficionado.

En relación con la privacidad y tratamiento de los datos de usuario, quisiera saber si se contempla explícitamente el cumplimiento de la normativa vigente en la Unión Europea (RGPD/GDPR), así como la legislación aplicable en otros países. Este punto resulta especialmente sensible y crítico, y considero fundamental que el proyecto incorpore desde su diseño mecanismos claros de cumplimiento legal, protección y control de datos.

Asimismo, no he visto reflejada la creación de un sistema de chat integrado a través de la Red. Personalmente, lo considero una funcionalidad de uso limitado en el contexto actual, además de ser redundante frente a canales ya consolidados y ampliamente utilizados como WhatsApp, Telegram u otros sistemas similares.

Por otra parte, me gustaría conocer cuál ha sido la fuente principal de inputs y criterios utilizados para definir este nuevo modelo. Hasta el momento, tras consultar a varios sysops, ninguno parecía conocer la existencia del proyecto. En este sentido, considero importante saber si se ha contado con la experiencia operativa acumulada durante décadas por quienes han mantenido y gestionado la Red actual.

Como conclusión, me parece un proyecto muy interesante y con potencial, pero creo que sería recomendable reforzar la transparencia, la participación y el contraste técnico con los actores que históricamente han sostenido la infraestructura de DXCluster.

73 de Kin EA3CV

[ea1het]

Hi Kin,

Thank you for your interest in the project.

As this is an international initiative, I will continue responding in the lingua franca to ensure the communication remains accessible to everyone involved. I’ll address your points in order of importance:

• Regarding privacy: Security is one of the foundational principles of RCLDX, and GDPR considerations have been carefully assessed from the outset. At the appropriate stage of the project, we will publish an update in our documentation, including a privacy policy, compliance notes, privacy-by-design materials and clear details regarding data retention, purge mechanisms and user rights.

• Regarding clubs: Clubs are one of the core pillars of the project. They provide continuity, structure and long-term sustainability beyond what any single individual can realistically maintain over time. Their institutional capacity is essential to the federation model we are building.

• Regarding IARU and its legitimacy: IARU has not been involved at this stage, and currently there is no operational reason to include them. From the project’s perspective, existing cluster network ecosystems have not demonstrated coordinated capacity of evolution, consistent administrative practices or robust handling of recurring security and/or privacy issues. In that context, the assumption of a centralized referee role would not align with observable realities.

The remaining points in your message appear to reflect personal opinions rather than specific questions or actionable concerns for the project. While we respect differing viewpoints, at this stage we are prioritizing concrete technical development, governance structure and measurable progress. For that reason, we prefer to focus our time and energy on discussions that contribute directly to the evolution of the project. Engaging in broader or speculative debates, especially those not tied to specific implementation aspects, would risk diverting attention from the work currently underway.

Kind regards,

EA1HET, Jonathan

[EA3CV]

GL Jonathan.

Kin EA3CV