Cómo iniciar un Club de Resiliencia de Internet
(bowshock.nl)- Debido a la guerra, la geopolítica y el cambio climático, las interrupciones de internet en Europa podrían volverse más frecuentes y más graves, por lo que pequeños grupos voluntarios de técnicos pueden convertirse en un punto inicial de coordinación para restaurar las comunicaciones.
- El club se comunica sin infraestructura central mediante radios LoRa de baja potencia y sin licencia, junto con mensajería de texto de código abierto Meshtastic, con un alcance de varios km.
- Esta combinación no requiere licencia ni servidores centrales, puede comenzar desde unos €20 y operar con menos de 1W usando baterías externas o pequeños paneles solares.
- La forma de empezar consiste en reunir a profesionales de internet dentro de un radio aproximado de 10 km, definir canales de contacto para tiempos normales y preparar radios LoRa y baterías externas para practicar repetidamente en un canal común.
- Una vez que se corta la electricidad o internet ya no hay tiempo para prepararse, así que antes de una crisis hay que reunirse en persona, intercambiar mensajes y familiarizarse con el equipo y los procedimientos.
El papel de Internet Resiliency Club
- Internet Resiliency Club es un grupo de voluntariado para que profesionales de internet puedan comunicarse entre sí sin infraestructura centralizada.
- Usa radios LoRa baratos, de baja potencia y sin licencia, junto con el software de mensajería de texto de código abierto Meshtastic.
- Los participantes pueden aprovechar sus radios, sus capacidades técnicas y sus conexiones personales con otros especialistas para impulsar la restauración de la conectividad a internet.
- El punto de partida es la preocupación de que, por la guerra, la geopolítica y el cambio climático, las interrupciones de internet en Europa puedan ocurrir con más frecuencia y ser más graves.
- Los gobiernos y las empresas podrían no actuar antes de que llegue una crisis debido al riesgo y al costo de los cambios necesarios.
Por qué hay que prepararse ahora
- En Ucrania, Rusia ha atacado repetidamente las comunicaciones y la energía usando tanto bombas como hackers.
- En 2022, malware dirigido a Ucrania desactivó turbinas eólicas en Alemania.
- En el mar Báltico, continúan los incidentes de petroleros sospechosos que arrastran sus anclas y cortan cables submarinos.
- El jefe de la OTAN aconseja que todos guarden en casa suministros para 3 días.
- “Network Resilience: Experiences of survival and development during the war in Ukraine” de 1-IX, el IXP de Ucrania, muestra la realidad de operar redes durante una guerra.
- Construcción de salas de routers camufladas
- Asegurar energía de generador para 3 días
- Sustitución de fibra óptica activa por métodos pasivos
- Obtener exenciones del servicio militar para personal de red
- El sistema neerlandés de “comunicación de emergencia” basado en la nube ha sido criticado porque no funcionaría en emergencias que afecten la energía o la conectividad a internet.
- Incluso si en el sector de las telecomunicaciones existieran planes formales equivalentes al “black start” de la red eléctrica, estos no se están compartiendo con los operadores de red que tendrían que implementarlos.
Respuesta a crisis y redes de voluntariado
- La clase de Crisis Engineering de Layer Aleph sostiene que cuando una organización enfrenta una crisis existencial, o bien cambia rápidamente hacia una forma más funcional, o fracasa y se vuelve más disfuncional.
- Este enfoque se centra menos en convencer de antemano a una organización de que vendrá una crisis, y más en preparar herramientas y planes para cuando la crisis llegue.
- Una cosa que una persona puede hacer sin ayuda del gobierno o de empresas es crear un grupo voluntario de especialistas en redes capaz de comunicarse sin infraestructura central.
- La radioafición puede ofrecer mayores distancias y más ancho de banda, pero se considera menos práctica para este objetivo por su costo, curva de aprendizaje, licencias, antenas y requerimientos de energía.
- Se eligen LoRa y Meshtastic como una alternativa barata y de bajo consumo para enviar mensajes de texto a varios km de distancia.
Procedimiento de inicio rápido
- Cómo formar un Internet Resiliency Club
- Reunir a técnicos relacionados con internet que estén dentro de unos 10 km
- Definir medios de contacto para tiempos normales: Signal, Matrix, correo electrónico, etc.
- Que cada persona prepare una radio LoRa y una batería externa compatible con carga de baja corriente (trickle charge)
- Instalar Meshtastic en las radios LoRa
- Definir el canal LoRa que usarán en conjunto
- Hacer reuniones y practicar enviando mensajes con Meshtastic
- Si trabajas en una empresa de infraestructura de internet, puedes proponer ofrecer a empleados interesados radios LoRa, baterías externas para celular y, si es posible, pequeños paneles solares para uso personal.
Funcionamiento básico de LoRa y Meshtastic
- Las radios LoRa tienen varias características adecuadas para comunicaciones de emergencia.
- No requieren infraestructura central
- No requieren licencia
- Precio bajo, desde unos €20
- Bajo consumo, de menos de 1W
- Pueden alimentarse con una batería externa común para celular
- Ejecutan el firmware de código abierto Meshtastic
- Pueden enviar y recibir mensajes de texto a varios km y en múltiples saltos con línea de vista
- Pueden conectarse a teléfonos o computadoras por Bluetooth o WiFi
- Muchas zonas urbanas ya tienen redes Meshtastic
- LoRa es un método de mensajería inalámbrica de baja potencia y baja tasa de bits derivado de la técnica chirp spread spectrum.
- Velocidad de transmisión de aproximadamente 1~25kbps
- Consumo energético de menos de 1W
- Meshtastic es un firmware de código abierto para radios LoRa.
- Usa un protocolo de red mallada de tipo flood-forward
- Reenvía mensajes entre nodos Meshtastic hasta 3 saltos con línea de vista
- Normalmente alcanza unos 10 km, aunque depende mucho del terreno y del clima
- Muchas placas LoRa económicas vienen como placas de desarrollo y pueden no incluir batería, carcasa ni una buena antena.
- Los productos más caros pueden incluir carcasa, batería, panel solar, pantalla grande, teclado y otros elementos; algunos incluso pueden usarse sin teléfono ni computadora aparte.
Elegir entre Meshtastic y MeshCore
- Se considera que MeshCore puede entregar mensajes de forma más estable, pero con menor resiliencia.
- La confiabilidad a larga distancia surge de un modelo más cercano a una red centralizada y administrada centralmente.
- MeshCore actualmente sufre problemas de congestión y requiere más gestión top-down que un enfoque desde abajo.
- Si se corta la energía y caen muchos repetidores, grandes áreas de la red MeshCore podrían quedar separadas y las partes restantes podrían saturarse con mensajes de actualización.
- También es posible usar ambos enfoques a la vez.
- Preparar dispositivos que ejecuten tanto Meshtastic como MeshCore
- Practicar cambiar de firmware sin conectividad de red ni electricidad comercial
Baterías y energía solar
- Las radios LoRa normalmente usan poca energía, del orden de 100~200mA.
- Una batería externa común para celular de 10,000~20,000mAh puede alimentar una radio LoRa durante aproximadamente 2~8 días.
- Depende del chipset
- Del tiempo de transmisión
- Y de si se usa WiFi o Bluetooth
- La batería externa debe admitir carga de baja corriente.
- Si no lo hace, el consumo de la radio LoRa puede ser tan bajo que la batería externa interprete que no hay nada conectado y deje de suministrar energía.
- La energía solar puede usarse conectando directamente un pequeño panel solar con salida USB o cargando la batería usada por la radio LoRa.
- Si un panel solar plegable de 800 cm² genera 15W y entrega hasta 5W/500mA, es suficiente para alimentar muchas radios LoRa.
- En una configuración pequeña de este tipo, puede bastar con solo el panel solar y una batería externa opcional, sin fusibles, controlador de carga ni convertidores buck/boost.
- Para 2026 ya es posible comprar radios LoRa totalmente solares con batería integrada, aunque los problemas de control de calidad siguen siendo relativamente comunes.
Dispositivos LoRa recomendados
- Dispositivos recomendados para Internet Resiliency Club
- SenseCap Solar P-1 Pro: alimentación solar, respaldo con batería, para instalación en exteriores
- Heltec V4: la opción más barata
- SenseCap Card Tracker 1000E: para llevar todos los días o para usuarios no técnicos
- LILYGO T-Echo: portátil y adecuado para experimentar
- Elegir el dispositivo puede ser más fácil que conseguir comprarlo, así que es mejor empezar sin pensarlo demasiado.
- Atención: no enciendas un dispositivo LoRa sin tener conectada la antena.
- La potencia que debería radiarse por la antena no puede salir y eso podría dañar el dispositivo.
- Aunque muchos dispositivos LoRa tienen puerto USB-C, puede que no implementen correctamente USB-C PD.
- Para una carga estable se recomienda usar un cable USB-A a USB-C.
-
SenseCap Solar P-1 Pro
- Si puedes pagar €100, se propone como la mejor opción para agregar un nodo LoRa que siga funcionando sin energía externa.
- Es un nodo LoRa con energía solar y respaldo de batería que puede fijarse en un balcón, techo o cerca.
- El P-1 Pro incluye batería y GPS; el P-1 no.
- Documentación de Meshtastic para SenseCap Solar P-1/P-1 Pro
-
Heltec V4 o superior
- Si tienes más tiempo y quieres ahorrar dinero, se recomienda un Heltec V4 o superior de unos €20.
- Tiene una pequeña pantalla OLED del tamaño de un sello postal, algunos botones, WiFi/Bluetooth y entrada/alimentación por USB-C.
- Los mensajes recibidos se muestran en la OLED y pueden revisarse con los botones.
- Para enviar mensajes se necesita conexión por WiFi o Bluetooth.
- No incluye carcasa, batería ni GPS, pero se recomienda usar una batería externa aparte.
- Documentación de Meshtastic para Heltec V4
-
SenseCap Card Tracker 1000-E
- Es adecuado para llevar un nodo Meshtastic todos los días.
- Tiene un tamaño y formato similares a varias tarjetas de crédito.
- También resulta práctico para dárselo a familiares o amigos que no estén familiarizados con la tecnología.
- Documentación de Meshtastic para SenseCAP 1000-E
-
LILYGO T-Echo
- Recomendado si quieres un dispositivo apto para experimentar y con una carcasa pequeña.
- Es un dispositivo portátil de bajo consumo de aproximadamente €80.
- Tiene una pantalla e-ink cuadrada de unos 3 cm, carcasa con botones, Bluetooth, GPS y batería para aproximadamente un día.
- Los mensajes recibidos se muestran en la pantalla e-ink y pueden revisarse con los botones.
- Para enviar mensajes, debe conectarse por Bluetooth a otro dispositivo.
- Documentación de Meshtastic para LILYGO T-Echo
Instalación de firmware y configuración inalámbrica
- Algunas placas se envían con Meshtastic ya instalado, pero por lo general será una versión de hace varios meses.
- Flashear placas LoRa es relativamente fácil.
- Se puede usar el flasher web de Meshtastic
- Requiere Chrome o Edge
- Si el dispositivo se monta como una unidad USB, también puede usarse el método de arrastrar y soltar archivos
- También existen herramientas de línea de comandos que usan interfaz serial, aunque pueden requerir ajustar el entorno de Python
- En Europa, las frecuencias disponibles para LoRa son 868MHz y 433MHz.
- Entre los usuarios europeos de Meshtastic, 868MHz es la más usada.
- Salvo que haya una razón especial, se usa el preset del módem por defecto:
LONG_FAST. - Un canal en LoRa es un flujo de mensajes que usa la misma clave de cifrado y el mismo nombre de canal.
- Existe un primary channel predeterminado compartido por todos los nodos Meshtastic
- También pueden configurarse secondary channels accesibles solo a nodos con la misma clave y el mismo nombre de canal
- Se puede definir una clave de cifrado y un nombre de canal para un secondary channel compartido, y compartir la configuración mediante un código QR
Reuniones y práctica
- La forma de trabajar juntos debe aprenderse antes de la crisis, no durante ella.
- Desde la perspectiva de Crisis Engineering, los equipos que ya han trabajado juntos tienen más probabilidades de tener éxito.
- En un grupo de voluntariado, la experiencia de “trabajar” juntos debe ser divertida.
- Hay que variar las actividades, los lugares y los horarios de las reuniones para que pueda participar gente distinta.
- La parte central de operar el club es reunirse en persona, enviar mensajes con Meshtastic y familiarizarse con el equipo y los procedimientos.
1 comentarios
Comentarios de Hacker News
Siento que Meshtastic todavía no está listo para instalarse y usarse de inmediato en un entorno sin internet
Llevé unas placas a una casa de vacaciones en el campo para probarlas en un espacio amplio, pero el acceso a internet era muy limitado, y todo el proyecto Meshtastic estaba orientado primero a la web
Para flashear las placas, el método recomendado es el "Web Flasher", y aunque descargues el código fuente del firmware, PlatformIO tiene que descargar e instalar por internet el toolchain y el flasher
Los clientes se ofrecen como apps de las tiendas o como app web en https://client.meshtastic.org/, pero ninguna de las dos opciones está pensada principalmente para uso offline. Después supe que la propia placa aloja una app web, pero aun así hay que conectarse al AP Wi-Fi, y no se puede acceder solo con conectar la placa a la computadora
La documentación también está solo en https://meshtastic.org/docs, y no veo opciones como "Download Docs" o "How to self host this project". Un técnico podría arreglárselas para averiguarlo, pero no parece ser una prioridad
Quizá la intención de este artículo sea que uno tenga todo preparado de antemano, pero es una lástima que ni siquiera haya documentación en PDF para leer offline. En este hilo también me enteré de Meshcore, pero si la guía de inicio del sitio es un video de YouTube, se queda corta para prepararse ante emergencias
El .apk del cliente Android se puede descargar directamente desde GitHub: https://github.com/meshtastic/Meshtastic-Android/releases
Aun así, estoy de acuerdo en que deberían dar mejor soporte a los casos de uso con cortes prolongados de internet
También se puede usar Meshtastic CLI
La documentación está en el repositorio git en formato .mdx: https://github.com/meshtastic/meshtastic
Todos los problemas señalados parecen ser consecuencia de intentar hacerlo más cómodo para usuarios acostumbrados al navegador web. La web actual, incluso incluyendo web3, está lejos de ser descentralizada
Si miras Linux, creció mucho durante los últimos 10 años y, sinceramente, la mayor parte fue en usabilidad. La UI/UX mejoró muchísimo y se volvió más pulida. A medida que Microsoft y Apple se volvieron más hostiles, más gente empezó a buscar alternativas, pero lo que creó el espacio para que esas personas entraran fue la usabilidad, y una comunidad más grande y diversa mejoró la accesibilidad
Hay que seguir criticando, pero interpretarlo como feedback, no como quejas puras. Así es como se pueden convertir estas cosas en mejores productos. Al fin y al cabo, ¿no es aquí donde se crean grandes productos?
Y nunca hay que subestimar la importancia de la documentación. Como cambia constantemente, parece una carga y una molestia, pero si la gente no sabe cómo participar, no puedes atraerla. Tanto para una empresa como para un proyecto open source, es una inversión muy rentable
La app web parece funcionar bien offline si guardas la página desde el navegador
La app de Android tiene versiones precompiladas en GitHub
Que no se pueda distribuir offline la app de iOS a usuarios finales es culpa de Apple. Hay que culpar a Apple o comprar un mejor teléfono
He visto dispositivos que, por comodidad, abren un servidor web de control mediante Ethernet por USB
Probé Meshtastic en una gran ciudad europea con casi 100% de cobertura mesh, y el rendimiento real fue bastante decepcionante.
Por diferencias en la ganancia de las antenas y un rendimiento mesh deficiente, muchas veces podía recibir mensajes pero no responder, y los chats públicos estaban completamente muertos o inundados de mensajes de prueba.
La mesh en realidad no escala bien: con más de 100 nodos se viene abajo, y hasta el canal de velocidad media se satura rápido, haciendo que todo sea muy lento. Incluso sin que nadie lo use apenas funciona, así que en una emergencia no creo que dependa de Meshtastic.
Me parece que una mesh Wi-Fi pública sería más valiosa. Los routers Wi-Fi usados son casi gratis, abundan y consumen poca energía. Todo el mundo ya lleva en el bolsillo un dispositivo cliente compatible. En un apagón total la mesh fallaría, pero mientras haya electricidad al menos sirve para algo.
Incluso usando una antena Yagi ajustada a 868 MHz o una antena dedicada en un mástil, el alcance en mi ubicación es bastante malo. Parece que la señal cae rápido con solo caminar 1 km por la calle. Sé que la altura es clave y la antena está bastante alta, pero 868 MHz parece atenuarse muy rápido.
Por eso no creo que Meshtastic sea una solución especialmente efectiva. El principio es válido, pero la implementación real se queda corta. En particular ahora que, gracias a SDR, las radios portátiles sencillas se volvieron muy baratas, alrededor de 20 euros, creo que enfoques existentes como Hamnet o la radioafición tradicional son mucho mejores.
Unos 10 watts por 100 metros cuadrados es un costo grande si intentas cubrir toda una ciudad.
Entonces bastaría con que una persona tuviera un generador o Starlink para ofrecer cierto grado de conectividad.
Se podría llamar a la red Find My de Apple una especie de mesh, pero para transportar datos arbitrarios a escondidas el ancho de banda es muy bajo. El nuevo chip Wi-Fi móvil de Apple podría ser el preludio de una verdadera red mesh de Internet.
En mi zona hay varios nodos ROUTER muy bien ubicados en cimas de montañas, que suprimen en gran parte la avalancha de ruido del centro urbano más bajo, y la mensajería local hasta unos 80 km es bastante estable. Eso sería imposible con Wi-Fi.
Las condiciones son unos 80 nodos locales, canal LONG_FAST y una población de alrededor de 500,000 personas.
Dicho eso, el algoritmo de enrutamiento de Meshtastic es extremadamente ineficiente y tiene muchísimo margen de mejora.
Qué pesadilla despertar una mañana sin electricidad, sin Internet y sin celular; cuanto más viejo me hago, más idílico suena.
Si supieras que las carreteras volverán a funcionar más tarde ese día, mucha gente incluso podría pasarla bien. Pero si el problema se prolonga, el caos tendría consecuencias amplias y desagradables.
Todavía no somos muy conscientes de cuánto dependemos de la tecnología ni de lo frágiles que pueden ser esas tecnologías. Si hace unos años alguien hubiera dicho que había que prepararse para una interrupción en el suministro de huevos, se habrían reído. También habrían salido bromas como "a mí ni me gustan tanto los huevos". ¿Y qué hay del acaparamiento de papel higiénico? Solo con esos dos incidentes se puede concluir que las interrupciones de suministro son, al menos en cierta medida, posibles. La antigua suposición de un suministro infinito de bienes y servicios quizá no se mantenga en el futuro.
Es un chiste divertido, y personalmente hay algunas dependencias que no extrañaría si desaparecieran. Hasta que las extrañe.
Personalmente, el concepto que me interesa es la resiliencia general.
En el apagón reciente esto ocurrió de verdad en la mayor parte de España y Portugal, y no fue una situación agradable.
Fue bastante surrealista. Quizá sea algún tipo de sesgo, pero yo también lo veo de esa forma.
Las redes mesh son la base de la resiliencia ante desastres y son esenciales. La cuestión es qué servicios montar encima.
Para chat en tiempo real, podría ser IRC, con su simplicidad burda e insegura pero probada en todas partes; Matrix con seguridad moderna encima; o algún enfoque nativo de mesh que casi nadie conoce. También importa cómo incorporar usuarios reales después de un desastre.
Para mensajería de almacenar y reenviar, la familia SMTP podría encajar bien, pero cada POP regional de desastre tendría que contar con servidores realmente distribuidos. También se necesitan parámetros de timeout y reintento para que los mensajes permanezcan en cola prácticamente para siempre.
Para foros, ¿hay algo mejor que el viejo NNTP? Otros protocolos adoptaron tarde la conectividad indirecta e intermitente, pero NNTP nació en ese entorno.
También queda la duda de si algo más sofisticado o interactivo es realista en una situación de desastre real.
Un kit de onboarding con clientes para los principales sistemas operativos, algo así como un CD-ROM de AOL, también podría ser útil para distribuir por sneakernet mediante dongles USB.
Incluso en celulares, abrir una conexión http normal o https con certificado autofirmado ahora es complicado.
Alguien más inteligente que yo seguramente tiene un conjunto de herramientas para esto, pero no sé dónde encontrarlo.
Del lado de almacenar y reenviar, NNCP fue diseñado para este propósito, pero todavía no está muy extendido.
La idea del autor parece ser que la red mesh provea un canal de comunicación mientras el "club de resiliencia" restaura el Internet normal.
El ancho de banda de la radio mesh es bastante malo
Para empezar, tiene que competir con muchas fuentes de interferencia, incluidas otras radios LoRa. Si hay un apagón, puede mejorar un poco. Más importante aún: las conexiones de larga distancia consumen ancho de banda en cada salto intermedio y van acumulando latencia y variación de latencia
La mensajería de texto puede ser razonable, pero como el ancho de banda por salto va de 0.3 kbps a 27 kbps y se divide todavía más en enlaces multisalto compartidos, fuera de eso es poco realista salvo para llamadas de voz de ultra bajo ancho de banda a corta distancia o para visitar sitios web minimalistas solo de texto
Podría tener más sentido reforzarlo con enlaces inalámbricos fijos punto a punto de microondas de varios megabits como backbone, y usar LoRa solo como red de acceso
Me da curiosidad la experiencia de quienes hayan hecho esto en la práctica
La idea del autor parece ser que la red mesh proporcione un canal de comunicación mientras el “club de resiliencia” restaura el Internet normal
Basada en algo como enlaces punto a punto Ethernet-over-microwave de unos 100 Mbit, y usando edificios altos como hubs, se podría armar una mesh bastante decente. Wi-Fi, LoRa o ambos podrían servir como red de acceso. Como el ancho de banda mesh de larga distancia es muy limitado, sería indispensable limitar el ancho de banda por cliente para evitar abusos
Claro que no sería barato. Un enlace de microondas decente cuesta miles de dólares, y cada parte de la red necesitaría energía solar de respaldo y baterías
También valdría la pena considerar la técnica de “orejas grandes, boca pequeña” para aumentar el ancho de banda. Si un enlace fijo con una tecnología como LoRa transmite a niveles de EIRP legales, pero del lado de recepción se usan antenas parabólicas de alta ganancia —por ejemplo, antenas satelitales recicladas— y amplificadores de bajo ruido en ambos extremos, se podría aumentar mucho el Eb/No de extremo a extremo, y ampliar bastante el ancho de banda y la distancia dentro de lo legal
El hardware necesario parece bastante viable con conmutación RF activa entre antenas o con duplexación mediante híbridos/circuladores. Me pregunto si alguien ya construyó o fabrica algo así, y cuáles son las barreras prácticas de implementación y regulación
Este artículo se entiende más si viene de una ciudad donde solo hay grandes operadoras de telecomunicaciones
En Dresden, Alemania, hay varias organizaciones voluntarias que han tendido cables o instalado antenas de microondas por toda la ciudad. AG DSN, Bürgernetz y Freifunk son ejemplos, y recientemente también apareció DD-IX, un punto de intercambio de Internet operado por voluntarios
Así que, mientras haya electricidad, tenemos nuestro propio Internet
Meshtastic es divertido, pero limitado; está más cerca de una app de chat por radio que de una infraestructura mesh real
Si estás pensando en serio en comunicaciones descentralizadas, vale la pena mirar Reticulum: https://reticulum.network
Reticulum no se limita a LoRa: funciona sobre IP, conexiones seriales, radio por paquetes y básicamente cualquier cosa que tengas. Sus características son tolerancia a retrasos, multisalto, cifrado y no requerir servidores. Todavía hay mucho por hacer y muchas apps por construir, pero la base es sólida
Una buena charla de EH22: https://media.ccc.de/v/eh22-97-eggceptional-meshnetworking
Probablemente sea este. Tiene un guion al final
https://media.ccc.de/v/eh22-97-eggceptional-meshnetworking-
Siento que un mejor camino hacia la resiliencia no son conexiones inalámbricas persistentes entre aficionados de lados opuestos del estado, sino conexiones intermitentes entre personas sentadas en lados opuestos del autobús, y una capa de aplicación que organice a quienes ya van en esa dirección para llevar tráfico de “Internet” en el sistema de archivos de su bolsillo
Si cada salto se convierte en una oportunidad para darle la mano a alguien y confirmar que el dueño de esa clave privada es un ser humano real, cambia el panorama de amenazas. Se crea una capa mínima de confianza sobre la cual construir. No se obtiene eso con direcciones de hardware flotando en el aire
Ambos métodos tienen el potencial de atraer atención dañina hacia los operadores de la red debido al comportamiento de los usuarios, pero en grados muy distintos. Hasta donde sé, todavía no ha habido casos de gente tumbando la puerta de operadores de Meshtastic para rastrear el origen de una transmisión, pero me parece que eso cambiará si fallan otros medios de travesuras de largo alcance
La infraestructura más resiliente sería una sin objetivos de alto valor: una estructura en la que cada usuario sea igualmente operador
No sé cuál sea su estado actual. El cliente enlazado desde el sitio web parece llevar un tiempo sin desarrollo
https://en.m.wikipedia.org/wiki/Secure_Scuttlebutt
Es muy estilo UNIX, así que puede ser bastante difícil de operar para alguien no técnico, pero por lo mismo debería ser fácil envolverlo con una UI. Hay que agregar explícitamente una lista de “vecinos” en la configuración, y los “paquetes” pueden encolarse como archivos o enviarse usando conexiones TCP/Noise. También soporta reenvío salto a salto y cifrado de extremo a extremo
http://www.nncpgo.org/
https://www.complete.org/nncp/
Podría surgir una comunidad de mensajeros que caminen por zonas concurridas recolectando mensajes enviados y luego crucen corriendo la ciudad para que los mensajes cifrados encuentren a sus destinatarios
Ese enfoque funcionaría en ciudades, pero sería mucho menos efectivo en lugares donde la gente no toma autobuses ni está cerca de otras personas todos los días
La ventaja de un método con alcance de unas 6 millas es que puede cubrir de forma relativamente efectiva suburbios y zonas rurales con parcelas de 20 a 40 acres
Está bien, pero algo viejo e incompleto. Hoy en día, Meshcore compite bastante con Meshtastic: https://meshcore.co.uk/
Algo para recordar es que LoRa solo permite mensajes de texto cortos. Ni pensar en imágenes, voz o archivos binarios.
Otra opción es APRS para enviar mensajes de texto mediante conexión satelital con un radio chino barato Quangsheng UV-K5 de 20 euros.
Meshtastic o Meshcore pueden estar bien para decenas de estaciones base y algunos usuarios de chat, pero cuando los números crecen, el enrutamiento y el procesamiento de señales consumen la mayor parte del ancho de banda, y si muchas personas envían mensajes al mismo tiempo, todo el sistema se vuelve muy inestable.
APRS es un poco mejor porque requiere licencia de radioaficionado y, por lo general, el equipo también es un poco más caro, pero aun con “SmartBeaconing” y unos pocos radioaficionados, aparecen colisiones: varias personas transmiten al mismo tiempo y se interfieren entre sí.
En Reddit abundan los preppers y tontos que compran estos radios chinos baratos, normalmente sin conocimientos, sin las licencias necesarias y sin saber realmente cómo usarlos. En entornos urbanos, el alcance de comunicación directa se mide en cientos de metros, o en uno o dos edificios grandes entre radios. Los repetidores estarán siendo usados por servicios reales de emergencia, así que en la práctica no sirven para ningún tipo de “uso privado”.
En resumen, mejor llevar unos libros y una baraja de cartas, y esperar. No hace tanto, lo normal era no estar localizable fuera de casa, y nos las arreglábamos bien.
Parece un negocio comercial, y el correo de contacto también es customers@... No sé cuál es la licencia. Preferiría usar Meshtastic.
Los códecs agresivos pueden bajar de 0,5 kbps. Si quieres usar un códec estándar sacrificando calidad de audio, el códec militar MELPe tiene un modo estándar de 600 bit/s.
Por lo que vi por encima, parece más pulido, pero al mismo tiempo un poco más opaco. Tal vez sea porque todavía no ha tenido suficiente tiempo para asentarse. Parece cumplir con los requisitos para ser público.
La respuesta del artículo —“las organizaciones no escuchan antes de que llegue una crisis; lo único que puedes hacer es preparar herramientas y planes”— es muy triste, pero totalmente cierta.
Pude trabajar en una empresa con más de 100 años de historia, que había pasado por guerras, la Gran Depresión, recesiones, colapsos de mercado, etc.
Ese tipo de empresa solía estar bastante abierta a la planificación ante desastres, pero al mismo tiempo a veces parecía una testaruda con la cabeza metida en la arena. Su rasgo más notable era una fuerte tendencia conservadora, tanto financiera como culturalmente, algo bastante inusual en la industria tecnológica actual.
Quien haya administrado sistemas de recuperación ante desastres sabe lo difícil que es conseguir apoyo. La recuperación ante desastres es cara, consume muchos recursos, es difícil de probar y es un tema en el que la gente no quiere pensar. Es parecido a un seguro.
Meshtastic/LoRa simplemente es malo para comunicaciones y tiene demasiados problemas.
En una situación de conflicto, a la ubicación de quien encienda LoRa podrían llegarle proyectiles o cohetes.
Basta ver qué pasa si enciendes un dron DJI con firmware básico, como en Ucrania.
Al usar radios en Ucrania, la regla número uno también es no usar radios cifrados. Me gusta especialmente este ejemplo porque parece ir contra el sentido común. Si el enemigo puede ver toda la comunicación, ¿por qué querrías usar un radio sin cifrado?
La razón es que el tráfico de radio cifrado le resulta muy interesante al enemigo. Si alguien lo está usando, es probable que sea alguien importante, y entonces le mandan proyectiles.
Se podrían colocar dispositivos LoRa al azar cerca del frente y, para reducir el riesgo, soltarlos con drones autónomos o drones de fibra óptica; luego encenderlos y apagarlos con temporizadores aleatorios para hacer que el enemigo gaste proyectiles y drones.