Briar está en modo de mantenimiento
Un mensajero seguro de nicho llamado Briar, conocido por su diseño peer-to-peer, sin servidores, sobre Bluetooth, Wi‑Fi local y Tor, está pasando a modo de mantenimiento después de que sus desarrolladores concluyeran que no podían superar las limitaciones modernas de los sistemas operativos móviles. Los comentaristas destacan cómo la gestión agresiva de segundo plano y de batería en Android e iOS, los sistemas centralizados de notificaciones push y los débiles efectos de red hacen que la mensajería P2P siempre activa en teléfonos sea frágil tanto técnica como socialmente. El caso se usa para ilustrar límites más amplios del código abierto financiado con donaciones, el escepticismo de que la IA pueda “arreglar” restricciones a nivel de plataforma, y el creciente interés en alternativas como radios mesh dedicadas y otros proyectos P2P o mesh.
El diseño y el nicho de Briar
- Se considera inusualmente ambicioso: totalmente P2P, cifrado de extremo a extremo, sin servidores, funcionando sobre Tor, Wi‑Fi local y Bluetooth.
- El descubrimiento local de pares y las capacidades sin conexión se destacan como funciones que pocos otros mensajeros admiten.
- Las decisiones de seguridad fueron muy conservadoras (por ejemplo, evitar el reenvío tipo “courier” en los mensajes directos para prevenir fugas del grafo de contactos), priorizando la privacidad sobre la usabilidad.
Usabilidad, adopción y límites de plataforma
- Muchos sostienen que los efectos de red de los mensajeros son brutales; si tus amigos no cambian, la app es, en la práctica, inútil.
- Ser P2P empeora esto: necesitas suficiente densidad local o recurrir a la conectividad a Internet.
- Las restricciones de fondo y de push en iOS se consideran un obstáculo importante; Briar nunca se lanzó en iOS.
- En Android, la gestión agresiva de energía y las restricciones sobre servicios en segundo plano de larga duración hacen que el P2P fiable y en tiempo real sea difícil sin usar el sistema de push de Google.
Funcionamiento en segundo plano y notificaciones
- Varios usuarios informan notificaciones retrasadas para muchas apps que no usan FCM; las apps convencionales que usan las API de push de Google funcionan mejor.
- Los comentarios técnicos explican Doze, los buckets de standby de las apps, los niveles de prioridad de FCM y el whitelisting, pero señalan que las apps que no usan FCM deben sondear o ejecutar servicios en primer plano, con compromisos en batería y fiabilidad.
- Algunos creen que más ajustes o un whitelisting a nivel de SO podrían ayudar; otros dicen que Android moderno simplemente cerró la mayoría de las vías viables.
Financiación y sostenibilidad
- Una línea de discusión culpa a la falta de usuarios que paguen y de donaciones de que el proyecto se haya estancado; otros responden que probablemente Briar tenía pocos usuarios desde el principio y que esperar que voluntarios se autofinancien es irrazonable.
- Preocupación general de que las herramientas pequeñas de código abierto y críticas para la seguridad son difíciles de sostener a largo plazo.
La IA como “arreglo”
- Un hilo controvertido debate “simplemente usa un LLM” para reescribir o arreglar Briar.
- Los escépticos subrayan: código crítico para la seguridad, barreras a nivel de plataforma en lugar de problemas puramente de programación, y el riesgo de grandes cantidades de código generado por IA.
- Quienes lo apoyan afirman que los LLM destacan en código de solución alternativa tedioso, pero se les cuestiona por su viabilidad y seguridad.
Alternativas y direcciones futuras
- Proyectos mencionados o comparados: qaul.net, BitChat, Meshtastic/MeshCore, Cwtch, Aurora/Geogram, Berty.
- Algunos sugieren descargar el P2P/mesh a radios dedicadas (LoRa, dispositivos mesh externos) con los teléfonos como clientes ligeros.
- Unos pocos especulan con funciones P2P construidas por el proveedor del sistema operativo (por ejemplo, que Apple haga iMessage al estilo mesh), pero señalan la baja demanda generalizada.