Documentación de Meshbell

Meshbell es un instrumento de emergencia a escala de vecindario. Su principio de diseño es poco común para una app de consumo: la verificación es el sustrato, no una función. Así es como funciona.

Panorama general

Una advertencia de peligro en Meshbell es un registro pequeño y firmado: una aseveración. Las aseveraciones se direccionan por contenido (se nombran mediante el hash de sus propios bytes), se firman con una clave de dispositivo y nunca se alteran: una corrección es una nueva aseveración que hace referencia a la anterior. Esa inmutabilidad es lo que permite que una advertencia y su corrección viajen juntas por una red en malla, y lo que permite a cualquier dispositivo volver a comprobar cualquier mensaje que reciba.

Todo lo que hay por encima de la red está diseñado para que perder una conexión, un servidor o un modelo te cueste una anotación, nunca la alerta.

El modelo de confianza

Meshbell mantiene separadas dos preguntas, porque son hechos distintos y mezclarlos es como se propaga la desinformación:

El segundo eje tiene deliberadamente tres valores. Una falsificación (comprobada contra una clave conocida, que falló) no es lo mismo que una clave desconocida (aún no hay forma de comprobarla): fusionarlas en un solo "no válido" ocultaría justo la distinción que una persona necesita. Un mensaje se almacena como confiable solo cuando el llavero dice verificado.

El cortafuegos de instrucciones

Lo único que una app de emergencia nunca debe hacer es convertir un rumor en una orden. Meshbell lo impone de forma estructural, no por disciplina de revisión:

• La pantalla que muestra una instrucción ("qué hacer") ni siquiera puede construirse a partir de un mensaje no verificado: el sistema de tipos lo rechaza.
• El texto de orientación proviene de un manual empaquetado y versionado, indexado por id, nunca de texto libre en la red y nunca de un modelo de lenguaje. Un modelo puede resumir una situación, en prosa, etiquetada como inferida: no tiene ningún campo donde colocar una orden.
• Una alerta oficial retransmitida se muestra como un vecino que da fe, no como oficial, a menos que demuestre una credencial ante un endpoint autoritativo.

La promesa, en una línea: la app nunca convierte un rumor en una instrucción, y esa frase es una propiedad del código, no una declaración de intenciones.

La capa de coordinación

Las alertas verificadas responden a "¿qué está pasando y puedo confiar en ello?". Pero un vecindario en una emergencia también tiene una logística ordinaria que resolver: quién está localizado, dónde está el refugio, quién tiene un generador. Meshbell lleva una segunda capa, deliberadamente separada, para ese trabajo, accesible de forma nativa en la pestaña Vecindario de la app, y en un navegador para quien no tenga la app.

Qué contiene

Por qué se mantiene aparte

Mezclar notas mutables de vecinos en un registro de alertas firmado y de solo anexado rompería ambas cosas. Por eso el almacén de coordinación es algo propio: solo en la LAN, mutable y servido por el puente junto al feed verificado, nunca dentro de él. Un operador posee un token de administración para el mantenimiento (borrar datos de prueba, podar un tablón desbordado); publicar y registrarse no requieren ninguna credencial. Las dos capas comparten una pantalla, nunca una frontera de confianza.

Funcionar sin conexión

La degradación es el estado esperado, no un error. Cuando una ruta de datos está caída, Meshbell sirve los últimos datos válidos conocidos etiquetados con su antigüedad ("hace 40 minutos") en lugar de un espacio en blanco de apariencia confiada. El nivel sin ML —un teléfono antiguo sin modelo en el dispositivo— es un nivel de producto de primera clase: una app de emergencia que solo funciona en el hardware más nuevo les falla a las personas que más probablemente la necesiten.

Radios y hardware

Meshbell funciona en tu teléfono por sí solo. Las radios amplían su alcance cuando la red está caída. Una red en malla de vecindario se construye con hardware LoRa económico y comercial que ejecuta el firmware abierto MeshCore:

Configurar un puente

Un "puente" es un nodo siempre encendido en la calle —por lo general una Raspberry Pi— que transporta el feed verificado y la capa de coordinación por Wi-Fi local, para que el teléfono o el navegador de cada vecino pueda alcanzarlos sin cobertura móvil ni internet. Meshbell está hecho para que dos personas muy distintas lleguen ahí sin un manual.

Si eres el anfitrión (un vecino preparado)

El instalador del puente viene dentro de la app. La configuración guiada te lleva paso a paso por el flasheo del nodo, y este arranca autocontenido: sirve las pantallas de coordinación de la app, una app web instalable para los vecinos que solo tienen navegador y una vista de administración para el mantenimiento. No hay nada que configurar a mano ni cuenta que crear: el nodo se anuncia en la red local y la app se encarga de encontrarlo.

Si eres un vecino (nunca has oído hablar de una red en malla)

Conéctate al Wi-Fi de la calle y abre la pestaña Vecindario. La app busca el puente automáticamente y se conecta; las pantallas de coordinación son nativas, así que funcionan incluso donde un navegador normal no puede alcanzar el nodo. Cuando el descubrimiento necesita ayuda, la app ofrece diagnósticos en lenguaje claro —¿es esta la red correcta? ¿está despierto el puente?— y un campo de dirección manual como respaldo, además de una vista dentro de la app de la app web del navegador si prefieres usar esa.

Arquitectura

La lógica de dominio es pura y portátil: se compila y se prueba en una Raspberry Pi sin hardware de Apple en el circuito, de modo que las partes que deciden si un mensaje es confiable se verifican de forma continua, no solo en el lanzamiento. La app de iOS es un renderizador delgado sobre ella.

• Canonical JSON (claves ordenadas, fijadas a ASCII) le da a cada dispositivo una preimagen idéntica byte a byte, de modo que una dirección de contenido calculada en un teléfono coincide con una calculada en un nodo.
• Firma y verificación Ed25519, una sola implementación en Apple y Linux.
• Un registro de solo anexado y solo inserción: los registros nunca se actualizan ni se eliminan, así que el historial —incluidas las correcciones— se preserva y se puede volver a verificar.
• Una compuerta de conformidad entre lenguajes: las mismas tramas se decodifican con la app y con un nodo independiente en Python y se comprueban byte a byte, de modo que ambos nunca pueden divergir en silencio.

Límites honestos

Dicho con claridad, porque una herramienta de emergencia que se sobrevende es peligrosa:

• Meshbell es una beta temprana. Ha llevado un boletín firmado a través de radios LoRa reales y lo ha verificado en un teléfono, pero todavía no sustituye a los canales de emergencia oficiales. Mantén activas tus alertas actuales.
• La distribución de claves —cómo tu dispositivo aprende qué clave pública pertenece a quién— es un área de trabajo activo; una firma prueba la posesión de una clave, y vincular una clave a una identidad real es un problema aparte y deliberado.
• Las claves de firma en el dispositivo residen en el llavero del dispositivo y son extraíbles por cualquier cosa que ya pueda leer el llavero de la app; no afirmamos una protección de enclave de hardware que no podemos cumplir.
• La capa de coordinación —el pase de lista de seguridad, las listas de recursos y el tablón, nativos en la app y en el puente— es no verificada por diseño y separada del canal de alertas firmado: útil para la logística, nunca una fuente de instrucción oficial, y no cubierta por el modelo de confianza de arriba. Es solo en la LAN, así que alcanza a quien esté en el puente, no a la red en malla más amplia.

← Volver al panorama general