Por Scott Powell, desarrollador principal del firmware. 01/03/2026
El rápido crecimiento y desarrollo de MeshCore es realmente gratificante y espero que continúe, pero existe el riesgo de fragmentación y división, entre otros problemas, si se pierden o se ignoran algunos de los principios que sustentan su diseño. Por lo tanto, espero que un resumen sobre lo que llevó a su diseño y hacia dónde creo que se dirige resulte útil.
Antecedentes
Probablemente la mayoría conoce el sistema de red mallada existente y las frustraciones que genera. Mi principal inquietud era el deseo de un ecosistema abierto, con un protocolo abierto, donde los usuarios pudieran desarrollar sus propios componentes (ya sea software, hardware, complementos, etc.) y maximizar la interoperabilidad. Esto, sencillamente, no era posible.
Reticulum también forma parte de esta propuesta. Es mucho más ambiciosa que MeshCore y ofrece muchas más funcionalidades, pero presenta varios problemas, como el hecho de estar casi completamente basada en Python y no estar diseñada para microcontroladores y, aunque incluye esta funcionalidad mediante herramientas como el firmware RNode, sigue siendo muy pesada en comparación con MeshCore.
¿Cómo intenta MeshCore dar respuesta a estos problemas?
Así pues, y teniendo en cuenta estas limitaciones previas, me dispuse a diseñar algo nuevo, y estos fueron los principios que surgieron:
- Ligero. Puede funcionar en hardware pequeño.
- Diseño basado en LoRa, pero no limitado a LoRa (cualquier radio de paquetes), es decir, tamaños de paquetes reducidos, muy conservador con el tiempo de transmisión.
- Librería C++ portátil, no restringida a Arduino. Extensible. Compatible con múltiples entornos de ejecución.
- La privacidad como principio fundamental (sin exposición obligatoria de la identidad, cifrado por defecto).
- Descentralizado. No existe un organismo administrativo central ni una corporación que establezca las políticas o los permisos.
- Firmware no monolítico. Los firmwares tienen una función específica; realizan una tarea concreta. Ni más ni menos.
- Un protocolo en constante evolución, extensible, con funciones esenciales como la mensajería y la interoperabilidad con la mayor cantidad posible de firmwares. Adaptable a redes de sensores, por ejemplo, o incluso a sistemas completamente privados con protocolos personalizados sobre el protocolo base.
La división del trabajo, los derechos y las responsabilidades
Al igual que Reticulum, MeshCore traslada claramente la responsabilidad del enrutamiento de paquetes a los repetidores, y solo a ellos. Los nodos periféricos, como los clientes de chat o los nodos sensores, no contaminan el espectro radioeléctrico. Los repetidores suelen estar ubicados en lugares elevados y con buena visibilidad, y tienen una ubicación fija. Los nodos periféricos pueden desplazarse (sin embargo, aún se están desarrollando extensiones de protocolo para optimizar el desplazamiento de estos nodos).
Dado que los repetidores realizan el trabajo de la red mallada, el administrador de un repetidor tiene derecho a permitir o rechazar el tráfico. Esto podría resultar algo controvertido o interpretarse como una forma de discriminación por parte de los administradores, pero la privacidad integrada en el protocolo principal dificulta intencionadamente esta práctica. Actualmente, el firmware estándar de los repetidores no impone restricciones, pero existen diversas versiones, algunas con mayor control administrativo, que incluyen limitaciones de velocidad, prioridades (aumento o penalización) personalizadas para ciertos tipos de paquetes o patrones de uso específicos.
Creo que una estrategia más orgánica para eliminar los nodos defectuosos es un enfoque mejor que las políticas impuestas desde arriba. Con más opciones y variedad de firmware, cada área o red encontrará sus propias soluciones a problemas como la saturación de canales, etc. Es improbable que exista una única solución para todas las redes en todas las jurisdicciones (aunque una configuración predeterminada adecuada y sensata contribuye en gran medida a limitar el caos).
Rutas
La estrategia general es: «rutas directas cuando sea posible, inundación como último recurso». Cada paquete se envía en modo inundación o en modo directo. Para optimizar el uso de recursos, el descubrimiento de rutas se integra en los paquetes normales, como en los mensajes. Así, cuando A no tiene una ruta hacia B, el envío de un mensaje se realiza en modo inundación y, si se encuentra a B, recibe el mensaje y la ruta en uno solo. En el contexto de la mensajería, el acuse de recibo (Ack) y la ruta se devuelven a A.
Las rutas son asimétricas. B también debe descubrir una ruta hacia A, y el ejemplo de acuse de recibo también realiza una doble función: al devolver el Ack + la ruta de salida, A recibe el Ack, la ruta de salida y la ruta de retorno. La única sobrecarga de paquetes en este intercambio es un tercer paquete, exclusivamente directo, que envía la ruta de retorno a B. Después de esta secuencia, tanto A como B almacenan rutas directas (hacia el otro) en su memoria.
Una consecuencia de esto es que los remitentes pueden almacenar rutas y elegir cuál usar. La aplicación de Liam va un paso más allá y permite construir rutas manualmente. Si administras un conjunto de repetidores y sabes que una ruta en particular es la óptima, esto puede ser beneficioso y reducir la saturación de la red.
Las inundaciones se volverán «caras»
El futuro escalable de MeshCore sigue siendo una incógnita. Soy moderadamente optimista respecto a su crecimiento, pero creo que es seguro afirmar que el modo Flood (por inundación) se volverá, en mi opinión, «costoso». La manifestación más básica de esto será el tiempo. Simplemente, Flood tardará más en llegar a su destino (este es, de hecho, el comportamiento actual: el firmware del repetidor da prioridad cada vez menor a los paquetes Flood provenientes de remitentes distantes). Para la mayoría de los usuarios y casos de uso, esto será suficiente para buscar mejores alternativas.
Utilizar un servidor de sala relativamente local es una de esas opciones. Estos están pensados para grupos muy locales, como un sencillo sistema de tablón de anuncios. (¡No, no están diseñados para escalar a toda la red!). Sin embargo, generalmente insisten en el tráfico en modo directo, así que mantén el tráfico local.
Recompensa y motivación
También creo que es un derecho fundamental de un desarrollador ser recompensado económicamente por su trabajo. Las vagas promesas de «recompensar a los colaboradores» por parte de una estructura corporativa opaca me parecen una farsa. Por eso recomiendo encarecidamente el modelo «freemium». Es una recompensa directa para quien realiza el trabajo. Además, permite un desarrollo mucho más sostenible y garantiza una experiencia de alta calidad, en lugar de perderse semanas enteras en foros sin sentido.
El increíble trabajo de Liam Cottle con la aplicación nativa para Android e iOS es un gran ejemplo de esto. Ha invertido mucho esfuerzo y realmente merece ser recompensado. Además, si lo comparamos con la alternativa (el infierno de los foros y lidiar con configuraciones y herramientas desconocidas), ¿acaso no vale la pena ahorrarse eso por unos pocos dólares? 🙂
Es muy gratificante recibir elogios directos y apoyo financiero de quienes usan tus productos. ¡Pero es un camino difícil! Es extremadamente complicado ganarse la vida así.
También existe la posibilidad de establecer alianzas con fabricantes de hardware. Sin embargo, esto se vuelve mucho más complejo. Resulta beneficioso trabajar en paquetes orientados al consumidor, altamente optimizados para un hardware específico, y si estos se concretan, corresponderá a los participantes determinar un reparto equitativo de las ganancias. Todo lo relacionado con el consumidor es extremadamente difícil y requiere un riguroso control de calidad y un gran nivel de perfeccionamiento para lanzar productos de este tipo al mercado. Espero que los productos de consumo compatibles con MeshCore lleguen a materializarse, pero el camino será arduo.
Materia para el futuro
Para concluir, unas breves notas sobre las futuras direcciones:
- La interacción entre el administrador de repetidores y el servidor de salas llegará a las aplicaciones de Liam.
- Ojalá haya más herramientas de diagnóstico para los planificadores de redes, como el rastreo de paquetes con relación señal/ruido (SNR).
- Ampliación general de la compatibilidad con dispositivos: esfuerzos para perfeccionar la compatibilidad con T1000e, más funciones para T1114, etc.
- Esfuerzos por estandarizar la telemetría de los datos de los sensores.
