Un móvil enlazado por Bluetooth a un nodo Meshtastic en primer plano; una línea ámbar representa el enlace LoRa hacia un segundo nodo situado en una cumbre, sobre un paisaje de montaña al amanecer.

Meshtastic: mensajes sin cobertura móvil ni Internet

Un mensaje donde no hay ninguna raya

Imagina un grupo caminando por un barranco, un valle sin cobertura o una zona de monte donde el móvil lleva horas marcando «sin servicio». Alguien se separa del grupo. No hay forma de escribir «voy bien, nos vemos en el refugio»: no hay antena de telefonía cerca, no hay wifi, no hay datos.

Ahora imagina que cada persona lleva un pequeño aparato de radio enlazado a su móvil. Escribe el mensaje en el teléfono como si fuera un chat normal, pulsa enviar y, poco después, aparece en los dispositivos del resto del grupo. Sin cobertura. Sin Internet.

Eso es Meshtastic: un proyecto de código abierto que permite enviar mensajes de texto y posición usando pequeñas radios de bajo consumo, sin depender de infraestructura de comunicaciones existente o fiable. Meshtastic no es un aparato concreto, sino un ecosistema de software y protocolos que funciona sobre distintos nodos compatibles: el firmware oficial da soporte a plataformas ESP32, nRF52, RP2040/RP2350 y equipos Linux, y los aparatos van desde una etiqueta del tamaño de un llavero hasta un terminal con teclado y pantalla. El software se publica bajo licencia GPL-3.0.

Antes de entusiasmarnos, conviene decir con claridad qué no es, porque casi todos los malentendidos sobre Meshtastic vienen de esperar de él algo que no promete. No es telefonía móvil. No da acceso a Internet ni a WhatsApp. Y no es magia: tiene límites físicos muy concretos que veremos más abajo.

Lo que sí ofrece es algo poco común: comunicación de texto que sigue funcionando cuando todo lo demás deja de hacerlo.

De dónde viene Meshtastic

Meshtastic no nació como una operadora ni como un estándar impuesto por la industria, sino como un proyecto abierto surgido de una necesidad práctica. Kevin Hester lo publicó el 26 de febrero de 2020, con una primera versión de firmware descargable ese mismo día, sobre placas asequibles que combinaban un microcontrolador, una radio LoRa y, en algunos casos, un receptor de posicionamiento. El objetivo era sencillo: tener comunicación de largo alcance y bajo consumo en actividades donde la cobertura móvil no es fiable —montaña, esquí, parapente—, con equipos baratos y software libre. Ya entonces se planteaba que el teléfono fuese opcional. Desde ahí ha crecido como proyecto sostenido por voluntarios, y esa genealogía explica muchos de sus rasgos actuales: hardware económico, código abierto, funcionamiento sin infraestructura y un papel central de la comunidad.

Lo que vas a descubrir

  • Qué problema resuelve Meshtastic y para quién tiene sentido.
  • Qué necesitas para empezar.
  • Qué hace tu móvil y qué hace el nodo de radio: dos aparatos con dos trabajos distintos.
  • Qué significa realmente que sea una red mesh, en malla.
  • Qué datos puede transportar y cuáles no.
  • Cuál es su alcance real, más allá de las cifras de escaparate.
  • Qué protege el cifrado y qué deja al descubierto.
  • Por qué el canal es un recurso pequeño y compartido que hay que cuidar.

Qué necesitas para empezar

La lista es corta, y conviene tenerla clara antes de seguir:

  • Un nodo por persona. Una placa con radio LoRa y su antena, configurada para la región correspondiente. En España, EU868.
  • Al menos dos nodos. Con uno solo no hay con quién hablar.
  • Un cliente para escribir y leer. Lo habitual es un móvil enlazado al nodo, pero también sirven un ordenador o un nodo con teclado y pantalla propios.
  • Un canal compartido. Todos los participantes deben usar la misma configuración de radio y la misma clave de canal.
  • Alimentación. Batería o alimentación externa, según dónde vaya a estar el nodo.

No necesitas contratar una red ni darte de alta en un servicio. El equipo debe configurarse y utilizarse conforme a la normativa de radio aplicable en cada región.

Dos aparatos, dos trabajos

La confusión más habitual de quien empieza es pensar que Meshtastic «va por el móvil». No exactamente. En un sistema Meshtastic intervienen dos dispositivos con papeles muy diferentes, y entender ese reparto es la clave de todo lo demás.

El nodo es una pequeña placa electrónica con un chip de radio especial —un transceptor LoRa— y una antena. Es el que de verdad transmite por el aire. Puede funcionar solo, con su batería, colocado en una mochila, un poste o una ventana. Los mensajes viajan de nodo a nodo por ondas de radio.

El móvil no transmite nada por LoRa. En el uso más habitual con un teléfono, móvil y nodo se enlazan por Bluetooth, y el móvil hace de pantalla y teclado cómodos: escribes ahí el mensaje, ves la conversación, consultas el mapa. También existen otras formas de controlar un nodo —por USB, por wifi o desde la línea de órdenes—, pero lo importante es la idea de fondo: el cliente solo es la interfaz cercana; es el nodo el que se encarga del largo alcance. Bluetooth no forma parte del enlace LoRa ni es una pieza obligatoria de la malla.

Sobre una loma, un móvil enlazado por Bluetooth a un nodo con antena; desde ese nodo, una línea representa el enlace LoRa hasta un segundo nodo situado al otro lado del valle.
El móvil solo enlaza con el nodo cercano. El alcance largo lo hace el nodo, por LoRa. El nodo remoto participa sin teléfono conectado. Ilustración conceptual elaborada con IA.

Dicho de forma sencilla:

  • Bluetooth, u otra interfaz cercana, conecta tu móvil con tu nodo, a corta distancia.
  • LoRa conecta tu nodo con los nodos de los demás, a mucha mayor distancia.

El nodo puede seguir funcionando y participando en la malla —recibir y retransmitir tráfico— sin que el teléfono permanezca conectado; la documentación oficial lo enuncia con claridad al señalar que no se requiere teléfono para la comunicación en malla. Ahora bien, para escribir o leer mensajes necesitarás algún cliente. Muchas placas no llevan teclado ni pantalla, así que «dejar el móvil en casa» permite que el nodo participe en la red, pero no que tú redactes mensajes desde él si no tiene interfaz suficiente.

Para ir más hondo — ¿por qué LoRa y no wifi o Bluetooth para el alcance largo?

Wifi y Bluetooth mueven muchos datos pero llegan muy poco lejos. LoRa hace justo lo contrario. Semtech, fabricante de la tecnología, la describe en su documentación técnica como una capa física pensada para bajo caudal y alto presupuesto de enlace: transporta poquísimos datos, pero con una eficiencia que le permite llegar muy lejos gastando muy poca energía. Ese intercambio —renunciar a velocidad para ganar alcance y autonomía— es la razón de ser de LoRa, y lo desarrollaremos en la pieza ¿Cómo puede LoRa llegar tan lejos consumiendo tan poco?

LoRa, LoRaWAN y Meshtastic: tres cosas distintas

Merece la pena fijar la frontera cuanto antes, porque es fuente constante de confusión:

  • LoRa es la tecnología de radio: la forma de modular la señal.
  • LoRaWAN es un protocolo de red construido sobre LoRa, con sus gateways y sus servidores.
  • Meshtastic usa LoRa, pero no usa LoRaWAN. Construye su propio sistema de paquetes, canales y retransmisión.

La consecuencia práctica: para montar una red Meshtastic no necesitas ningún gateway LoRaWAN, ni darte de alta en The Things Network, ni ningún servidor. Dos nodos y nada más.

Esa distinción tiene suficiente miga como para merecer pieza propia, y la tendrá: LoRa no es LoRaWAN: dónde encaja Meshtastic.

Qué significa que sea una red «en malla»

La palabra mesh significa «malla», y describe cómo se organizan los nodos entre sí.

En una red de telefonía tradicional todo pasa por una antena central: tu móvil habla con la torre, y la torre con el resto del mundo. Si esa torre no está o se cae, te quedas incomunicado.

En una red mesh no hay centro. Cada nodo puede recibir un mensaje y volver a emitirlo para que llegue más lejos. Si tú y yo estamos demasiado separados para oírnos directamente, pero hay un tercer nodo en medio, ese nodo repite nuestro mensaje y establece el puente.

Tres nodos en un terreno ondulado: el enlace directo entre los extremos aparece bloqueado por el relieve y un tercer nodo situado sobre la loma retransmite el mensaje.
En este ejemplo, el relieve bloquea el enlace directo entre los extremos y el nodo situado en alto hace de puente. Cada retransmisión ocupa tiempo de emisión, y el número de saltos está limitado. Ilustración conceptual elaborada con IA.

El mecanismo que emplea Meshtastic se llama difusión gestionada: varios nodos pueden retransmitir un mensaje, pero antes de hacerlo escuchan un momento por si otro ya lo ha repetido, y así se evitan repeticiones innecesarias. La mecánica fina —cómo se decide quién repite antes, cómo se encaminan los mensajes directos— la veremos en Cómo funciona realmente una red Meshtastic.

Esto tiene una consecuencia interesante: más nodos bien situados pueden ampliar la cobertura y ofrecer caminos alternativos, porque cada nodo nuevo es un posible puente. Pero —y esto importa— más nodos no significa automáticamente una red mejor. La posición, la densidad y la configuración pesan tanto como el número. Lo veremos con más detalle al final.

Conviene una advertencia temprana para no vender humo: una malla no es ilimitada. No es que un mensaje pueda saltar infinitas veces y dar la vuelta a una provincia. Cada reenvío consume tiempo de emisión compartido, y el protocolo lleva en la propia cabecera de cada paquete un contador de saltos que va decreciendo hasta agotarse, precisamente para que la red no se ahogue en sus propias repeticiones.

Qué puede transportar (y qué no)

Meshtastic está pensado para mover muy poca información, pero la esencial cuando no hay otra cosa:

Y aquí la parte que evita decepciones. En su funcionamiento ordinario sobre las bandas sub-1 GHz —las que se usan en España, EU868—, Meshtastic no puede:

  • hacer llamadas de voz ni videollamadas*;
  • enviar fotos, audios o archivos de tamaño normal;
  • darte acceso a Internet, redes sociales o mensajería habitual;
  • sustituir a la telefonía móvil en velocidad o capacidad.

* Existe un módulo de audio experimental, limitado a determinados equipos ESP32 con radio SX128x que operan en 2,4 GHz. La propia documentación explica que las bandas sub-1 GHz no son suficientemente anchas para sostener audio continuo. En EU868, por tanto, la voz no está sobre la mesa.

La razón no es un defecto que vayan a corregir en la próxima versión: es física. La misma característica que le permite llegar tan lejos con tan poca energía —enviar muy pocos datos por segundo— es la que le impide mover voz o vídeo con soltura. Es un intercambio deliberado, no una limitación pasajera.

Piénsalo así: Meshtastic no es un móvil más barato, es más parecido a un walkie-talkie de mensajes de texto con un alcance sorprendente y la capacidad de repetir mensajes entre aparatos.

Alcance real, no alcance de escaparate

Es fácil encontrar titulares con distancias espectaculares. Y son ciertos. El proyecto Meshtastic recoge un récord en tierra de 331 kilómetros, aportado por dos miembros de la comunidad. Lo interesante no es desmentir la cifra, sino leer sus condiciones: enlace de montaña a montaña, sin obstáculos de por medio, antenas favorables, y una configuración de radio deliberadamente lentísima, elegida para maximizar el alcance a costa de la velocidad.

Es decir: el récord no describe el uso cotidiano, describe el límite del sistema en circunstancias óptimas. Un dato así sirve para entender de qué es capaz la física de LoRa, no para predecir lo que ocurrirá en tu barrio o en tu ruta.

Porque el alcance real de Meshtastic no es una cifra fija. No es una propiedad que LoRa «tenga» sin más: es el resultado de muchos factores actuando a la vez.

  • La altura de las antenas, lo que más influye casi siempre.
  • Los obstáculos: edificios, montañas, vegetación densa.
  • La potencia de emisión y la sensibilidad del receptor.
  • La antena empleada y su orientación.
  • Los parámetros de radio configurados, que permiten cambiar velocidad por alcance.

Como orientación, y solo como orientación: en entorno urbano, con nodos a la altura de una persona y edificios de por medio, cabe esperar bastante menos que en campo abierto con antenas elevadas, donde la cosa mejora mucho. Pero conviene subrayarlo sin rodeos: eso es una expectativa condicionada, no una medida. Ni Trotero ni el proyecto Meshtastic publican una cifra de alcance típico, y la única en la que puedes confiar es la que tú mismo obtengas en tu entorno. En esta colección no daremos ninguna cifra de alcance como propia sin haberla obtenido en una prueba real y documentada.

Para ir más hondo — ¿cómo se mide si «llega bien»?

Dos números lo resumen: el RSSI, cuánta señal llega, y el SNR, cuánto destaca esa señal sobre el ruido de fondo. Un enlace puede «llegar» pero con margen justo, al borde de fallar. Aprenderemos a leerlos, y a medir alcance con método, en el recorrido B y en nuestras propias campañas de campo: ¿Hasta dónde llega un enlace directo Meshtastic? Primera prueba real.

Privacidad: qué protege el cifrado y qué no

Este apartado es importante y suele contarse mal, así que vamos con precisión.

Meshtastic cifra el contenido de cada paquete con AES256-CTR, usando una clave distinta para cada canal. Quien no disponga de esa clave no puede interpretar lo que se dice en el canal. Hasta ahí, bien. Ahora los tres matices que cambian el cuadro por completo.

1. Cifrado no es lo mismo que privado. Un contenido puede estar cifrado y, aun así, ser legible para cualquiera que conozca la clave compartida. Y ahí está el detalle de la configuración primaria predeterminada: los equipos arrancan con un canal primario cifrado mediante una clave conocida y publicada en la propia documentación del proyecto. Existe para que dispositivos desconocidos puedan encontrarse y repetirse mensajes entre sí, y por eso no debe considerarse un canal privado: cualquiera con un aparato igual puede leer lo que circula por él. Para conversaciones privadas hay que crear un canal propio con clave nueva y compartir esa clave en persona o por un medio seguro, nunca por la propia red.

2. La cabecera del mensaje viaja sin cifrar. Para que los nodos intermedios puedan repetir un mensaje sin necesidad de leerlo, la información de encaminamiento va siempre en claro: identificador del nodo emisor, identificador del destino, identificador del paquete, nodo que ha hecho la última retransmisión. Es decir, aunque el contenido esté protegido, qué nodos están comunicándose y cuándo queda a la vista de quien escuche. Conviene precisar qué queda expuesto exactamente: son identificadores de nodo y actividad, no nombres ni identidades civiles. Aun así, en privacidad esos metadatos importan tanto como el texto. Por eso es incorrecto decir que «todo el paquete está cifrado».

Representación conceptual de un paquete Meshtastic dividido en una cabecera visible, que contiene los identificadores de nodo emisor y destino, el identificador del paquete y la última retransmisión, y un contenido cifrado que no puede interpretarse sin la clave correspondiente.
La cabecera viaja en claro para que los nodos intermedios puedan retransmitir sin leer el mensaje. El contenido va cifrado. Representación conceptual: no refleja tamaños ni estructura real del paquete.

3. Un mensaje de canal y un mensaje directo no se protegen igual. El canal usa una clave compartida por todo el grupo. Los mensajes dirigidos a una persona concreta, en cambio, se cifran desde la versión 2.5 del firmware con la clave pública del destinatario, de modo que solo esa persona puede leerlos y los nodos que los retransmiten no necesitan conocer su contenido. Es una diferencia importante, y tiene condiciones: cómo se establece esa confianza entre nodos, y qué ocurre cuando falla, están detallados en el anexo.

La conclusión práctica no es «Meshtastic no es seguro», sino esta: cifrado no significa anónimo, y tampoco significa seguridad absoluta. El contenido de un canal está protegido frente a quien no tenga la clave, pero el cifrado de canal no garantiza que quien escribe sea quien dice ser, y la actividad de la red es visible aunque los mensajes no lo sean. Sácalo del canal predeterminado, usa clave propia, comparte esa clave con cuidado y no le pidas al sistema garantías que no ofrece. El detalle técnico completo, incluidos los cambios anunciados para la rama 2.8, está en el anexo.

El aire es pequeño y es de todos

Un último concepto, quizá el menos intuitivo pero el que marca la diferencia entre una red que funciona y una que se atasca.

El canal de radio configurado en un grupo Meshtastic tiene una capacidad muy pequeña, y todos los nodos que lo comparten emiten sobre el mismo medio. No es como el wifi de casa, donde caben vídeos simultáneos. Los nodos escuchan antes de transmitir para no pisarse, pero las transmisiones que se solapan pueden interferirse y algún mensaje se pierde. Cada paquete y cada retransmisión consumen tiempo de emisión, así que, a medida que crece el tráfico, acaba bajando la fiabilidad de la red.

No es una preocupación teórica: el propio firmware la gestiona. Cuando una malla supera cierto tamaño, alarga automáticamente los intervalos con que los nodos emiten su tráfico periódico —telemetría, posición, presentación— para no saturar el aire. El sistema, literalmente, se contiene solo cuando la red crece.

De ahí una idea contraintuitiva. En el papel estándar, un nodo solo retransmite si nadie más lo ha hecho ya. Los papeles pensados para infraestructura, en cambio, retransmiten siempre, incluso cuando oyen a otro nodo hacerlo, y la documentación recomienda reservarlos para emplazamientos estratégicos. De esos dos hechos se sigue una conclusión razonable —y la presentamos como inferencia, no como resultado medido ni como afirmación literal de la documentación—: multiplicar sin criterio los nodos configurados como infraestructura aumenta la ocupación del canal y puede empeorar una red densa en lugar de mejorarla. La mayoría de los aparatos deberían quedarse en su papel estándar. Cuidar el aire compartido es parte de usar Meshtastic con responsabilidad, igual que respetar la normativa de radio que veremos antes de cualquier práctica.

Errores frecuentes

Los malentendidos que más se repiten, reunidos:

  • «Meshtastic va por el móvil». No. El móvil es la interfaz; el nodo es quien transmite. Bluetooth no participa en el enlace largo.
  • «Necesito un gateway o darme de alta en alguna red». No. Eso es LoRaWAN, que es otra cosa. Dos nodos bastan.
  • «Como va cifrado, es privado». El canal predeterminado usa una clave pública y conocida. Y aunque uses clave propia, los metadatos de encaminamiento viajan en claro.
  • «Llega a 300 kilómetros». Llegó, una vez, de montaña a montaña y con una configuración muy concreta. No es lo que vas a obtener en un valle o en una ciudad.
  • «Cuantos más repetidores, mejor». Cada retransmisión ocupa el canal. Muchos nodos de infraestructura mal situados pueden empeorar la red.
  • «Sirve para hablar». En EU868, no. El módulo de audio existe, pero es experimental y solo para 2,4 GHz.
  • «Es una malla infinita». El número de saltos está limitado por diseño.

Ideas esenciales

  • Meshtastic permite enviar texto y posición sin cobertura ni Internet, usando pequeñas radios LoRa de bajo consumo, y no utiliza LoRaWAN: no necesita gateway ni servidor.
  • Intervienen dos aparatos: el cliente —normalmente un móvil, por Bluetooth— y el nodo, la radio que transmite de verdad. El nodo participa en la malla sin el teléfono, pero para escribir y leer hace falta algún cliente.
  • Es una red en malla con difusión gestionada: los nodos se repiten los mensajes, escuchando antes para no duplicar esfuerzos. Más nodos bien situados amplían la cobertura, pero más nodos no es automáticamente mejor, y el número de saltos está limitado.
  • Transporta poca información —mensajes cortos, posición, telemetría sencilla— y no sirve para voz, vídeo, archivos ni Internet en las bandas sub-1 GHz. Es un intercambio físico deliberado, no un defecto.
  • El alcance real depende de altura, obstáculos, antenas y configuración. El récord documentado de 331 km es una medición comunitaria en condiciones excepcionales, no una expectativa.
  • El cifrado protege el contenido, pero cifrado no es privado: el canal predeterminado usa una clave conocida, los metadatos de encaminamiento viajan en claro, y el cifrado de canal no autentica ni verifica integridad.
  • El canal es pequeño y compartido: el firmware se autolimita cuando la red crece, y conviene no saturarlo con repeticiones innecesarias.

Qué permite y qué no permite concluir esta pieza

Esta pieza te da el mapa mental para entender qué es Meshtastic y decidir si encaja con lo que necesitas. No es una guía de configuración ni contiene mediciones propias: aquí no afirmamos ninguna cifra de alcance como resultado experimental de Trotero. Esos datos llegarán cuando montemos y probemos la red nosotros mismos.

Siguiente lectura

➡️ LoRa no es LoRaWAN: dónde encaja Meshtastic.

Y, cuando queramos pasar de la idea a la práctica:

➡️ Montamos una red Meshtastic con dos nodos.

Una placa LILYGO T-Beam con pantalla y antena junto a un nodo Meshnology N32 azul, ambos compatibles con Meshtastic.
Dos nodos Meshtastic utilizados por Trotero: una LILYGO T-Beam y un Meshnology N32 basado en Heltec WiFi LoRa 32 V3. Recreación fotográfica elaborada con IA a partir de imágenes de los modelos reales.

Anexo — Versiones, fuentes y trazabilidad técnica

Este anexo existe para que puedas comprobar sobre qué versión se ha escrito cada afirmación, y para que sepas qué habrá que revisar dentro de unos meses.

1. Versiones del firmware

VersiónCanalFechaPapel en este artículo
2.7.26.54e0d8dBeta, marcada como Latest por el repositorio oficial24 jun 2026Referencia operativa.
2.8.0.47db0e3Alpha / Pre-release1 sep 2026Evolución anunciada. Sus cambios no se dan por aplicados en el cuerpo.
2.8.0.7239fe8Revocada por el proyecto30 ago 2026Solo como contexto de que la rama 2.8 aún no está asentada.

La pieza toma 2.7.26.54e0d8d como referencia operativa. Los cambios identificados en la rama 2.8 se señalan expresamente cuando afectan a lo explicado. La documentación oficial enlazada se publica ya en su rama 2.8; los asuntos sensibles a la versión —mensajes directos, identificadores de nodo, límite de saltos, emisión de posición y telemetría, y papeles de nodo— se han contrastado específicamente contra la referencia. El resto describe comportamiento común a ambas ramas.

2. Afirmaciones y respaldo

TemaFuenteVersiónNaturalezaConsulta
Definición del proyecto, plataformas, malla sin teléfonoDocumentación oficial, Introductiondocs 2.8Documentación oficial6 sep 2026
Licencia GPL-3.0 y plataformas soportadasRepositorio meshtastic/firmwareRepositorio oficial6 sep 2026
Origen del proyecto, autoría y fechaPublicación de Kevin Hester en Hackaday.io2020Publicación del autor6 sep 2026
Difusión gestionada, escucha previa, límite de saltosDocumentación oficial, Mesh Broadcast Algorithmdocs 2.8Documentación oficial6 sep 2026
Autolimitación de intervalos en mallas grandesDocumentación oficial, Mesh Broadcast Algorithmdesde 2.4.0Documentación oficial6 sep 2026
Cifrado AES256-CTR por canal, cabecera en claro, clave conocida del canal predeterminadoDocumentación oficial, Encryptiondocs 2.8Documentación oficial6 sep 2026
Mensajes directos con clave pública, confianza en el primer uso, retroceso al cifrado de canalDocumentación oficial, Encryption y Known Limitationsdesde 2.5Documentación oficial6 sep 2026
Ausencia de autenticación, integridad y secreto hacia delante en mensajes de canalDocumentación oficial, Encryption y Known Limitationsvigente en 2.7.26Documentación oficial6 sep 2026
Versiones publicadas, canal y fechasListado de versiones del firmwareRepositorio oficial6 sep 2026
Firma de paquetes como cambio de 2.8.XDocumentación oficial, Known Limitationsanunciado para 2.8Documentación oficial6 sep 2026
Comportamiento de retransmisión según el papel del nodoDocumentación oficial, Device Configurationdocs 2.8Documentación oficial6 sep 2026
Efecto de multiplicar nodos de infraestructuraInferencia editorial a partir de las dos fuentes anteriores
Telemetría transportable por la mallaDocumentación oficial, Telemetry Moduledocs 2.8Documentación oficial6 sep 2026
Módulo de audio experimental y anchura de las bandas sub-1 GHzDocumentación oficial, Audio Moduledocs 2.8Documentación oficial6 sep 2026
Récord de 331 km y sus condicionesDocumentación oficial, Range TestsMedición comunitaria recogida por el proyecto6 sep 2026
LoRa como capa física de bajo caudal y alto presupuesto de enlaceSemtech, AN1200.86v1.0, mar 2024Dato de fabricante6 sep 2026
Expectativa cualitativa de alcance urbano frente a campo abiertoOrientación condicionada, sin fuente ni medición

3. Notas de alcance

  • 2.7 frente a 2.8. El cuerpo describe la versión de referencia. La rama 2.8, en alpha, anuncia cambios que tocan directamente varios apartados de este artículo: firma de paquetes, identificadores de nodo derivados de la clave pública, límites de salto variables y emisión de posición y telemetría bajo activación explícita. Ninguno se da aquí por implantado.
  • Mediciones. El récord de 331 km es una medición de la comunidad, recogida por el proyecto. No es una medición del proyecto Meshtastic ni de Trotero. Trotero no aporta en esta pieza ninguna medición propia, y no lo hará hasta ejecutar y documentar sus propias pruebas.
  • Inferencias. Dos afirmaciones de este artículo son razonamientos nuestros, señalados como tales: el efecto de multiplicar nodos de infraestructura sobre una red densa, y la expectativa cualitativa de alcance urbano frente a campo abierto.
  • Detalle del cifrado, desplazado del cuerpo. Los mensajes directos usan un modelo de confianza en el primer uso: cada nodo guarda la primera clave pública que ve asociada a un identificador, y no existe autoridad que las certifique. Si el emisor no conoce la clave pública del destinatario, el envío puede retroceder al cifrado de canal, menos seguro. El cifrado de canal no incluye autenticación ni verificación de integridad, de modo que quien tenga la clave puede escribir en nombre de otro; y no hay secreto hacia delante, por lo que el tráfico capturado hoy sería descifrable si la clave se filtrase mañana. La rama 2.8 introduce firma de paquetes para reforzar la identidad de los nodos: no forma parte de la versión de referencia.
  • Qué habrá que revisar. La versión de referencia y el estado de la rama 2.8; el apartado de privacidad completo cuando la firma de paquetes se consolide; los papeles de nodo, que evolucionan entre versiones; y cualquier referencia regulatoria, que aquí se limita a situar el ámbito EU868 sin fijar límites numéricos.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *