Iroh 1.0 - Conexión por claves, no por IP - Biblioteca de red para conectar dispositivos arbitrarios

• Iroh 1.0 es la primera versión estable y garantiza la estabilidad del wire protocol y de la API del lenguaje, por lo que los endpoints de iroh v1 pueden comunicarse entre sí sin importar la versión minor o el lenguaje
• Además del crate de Rust, ofrece soporte oficial para Python, Node.js, Swift y Kotlin, y permite integrar iroh en aplicaciones Swift para iOS y apps Kotlin para Android
• Los cambios que afecten la estabilidad del wire siempre ocurrirán junto con un major release, y en el futuro las versiones de la API de lenguaje y la compatibilidad wire podrán versionarse de forma independiente
• Después de la 1.0, las versiones major y minor recibirán soporte según el calendario de soporte, y la versión minor 0.35 no recibirá lanzamientos adicionales
• El soporte de Public relay estará operativo hasta el fin de vida de la v1.0, hasta el 31 de diciembre de 2026 para la v0.35x, y hasta el 30 de septiembre de 2026 para la v0.9x y la v1.0.0-rcX
• El public relay normalmente se actualiza a la versión más reciente dentro de las 24 horas posteriores a cada release, y los cambios del relay que rompan compatibilidad wire usarán una nueva URL para que los clientes existentes sigan funcionando
• Las capacidades de conexión incluyen QUIC multipath, QUIC NAT traversal, configuración local-first, ejecución en WASM y navegador, hooks de control de conexión y soporte para transport personalizado
• En las conexiones, normalmente el 95% de los datos se transfiere directamente entre dispositivos, y se explica que las conexiones directas reducen los saltos por la nube y los costos de egress {p:95}
• El tráfico retransmitido por el public relay tiene rate limits, y esos límites pueden cambiar en cualquier momento

[GN⁺]

Comentarios de Hacker News

• Si ves Iroh por primera vez, puedes entenderlo más o menos como un Tailscale en la capa de aplicación, no en la capa de red
  La idea de “¿por qué no usar simplemente Tailscale?” es distinta desde la perspectiva de un desarrollador de apps. Para conectar fácilmente instancias de una app, en teoría podrías integrar las funciones de Tailscale dentro de la app, pero entonces el usuario necesitaría una cuenta de Tailscale y la app también quedaría dependiendo de Tailscale
  Iroh te permite integrar esa función directamente y además ofrece relays públicos de respaldo. Si la app crece hasta el punto de que ya no sea viable usar relays públicos, cambiar a un relay propio es casi como accionar un interruptor

  • Fue con esta explicación que por fin entendí mejor qué hace Iroh, más que con el video. Ahora lo que me da curiosidad es cómo implementa Iroh todo esto
  • Ahora sí entiendo la propuesta de valor. Lo explicaste mucho mejor que la landing page; casi como para encargarte el texto de marketing
  • Una respuesta a “¿por qué no usar Tailscale?” es también que Tailscale es una empresa que busca ganar dinero, y sería una tontería seguir concentrando la tecnología distribuida en manos de unos pocos dueños centralizados
    Más aún si Iroh hace que hacerlo de la forma correcta sea tan fácil y tan bueno
  • Exactamente eso. Creo que encontré Iroh mientras pensaba: “¿podríamos distribuir Tailscale junto con nuestra app?”
    En entornos donde los usuarios necesitan acceder a una instancia local, creo que Iroh puede ser un cambio total de juego. En nuestro caso, sirve para facilitar el control del software desde el teléfono u otros dispositivos
    Antes tal vez había que comprobar si estaban en la misma LAN, pero con Iroh funciona en cualquier entorno
  • La comparación más cercana es OpenZiti
    Tanto Iroh como OpenZiti pueden integrarse en apps, y ambos tienen buenos casos de uso para desarrolladores que quieren integrarlos en sus servicios
    OpenZiti se usa en servicios donde importan la escala y la seguridad, mientras que Iroh puede ser muy conveniente porque permite participar incluso a actores sin una relación previa

• Soy uno de los desarrolladores de Iroh
  Una pregunta frecuente es cuándo va a soportar Iroh WebRTC, BLE, LoRa, etc.
  Actualmente Iroh solo soporta por defecto IPv4, IPv6 y transporte por relay. Hay tantos métodos de transporte interesantes que, si intentáramos soportarlos todos, la base de código se convertiría en un laberinto de feature flags imposible de mantener
  En su lugar, hicimos posible implementar transportes personalizados, y la implementación del transporte puede vivir en un crate completamente separado
  Entre los transportes personalizados experimentales existentes están Tor, Nym y BLE. https://github.com/mcginty/iroh-ble-transport
  Aquí se puede ver cómo funciona internamente: https://www.iroh.computer/blog/iroh-0-97-0-custom-transports...

  • Estuve viendo la documentación y parece un proyecto bastante interesante, y también encontré un ejemplo de chat P2P
    Si uno arma con esto una configuración P2P cliente/servidor o dos máquinas peer, me da curiosidad saber cuáles son los límites en cuanto a qué más habría que configurar para conectar dos aplicaciones
    Por ejemplo, si haces una app que corre en un teléfono y otra que corre en una laptop, quisiera saber si realmente obtienes una conexión directa y segura entre ambas, o si esto resuelve otro problema
    -[0]: chat p2p, en rust, desde cero: https://www.youtube.com/watch?v=ogN_mBkWu7o
  • Como alguien que antes construyó bastante sobre libp2p, me gustaría ver una comparación actual desde el punto de vista del desarrollador de apps
    El año pasado terminé eligiendo lo conocido al tener que optar entre los dos, pero ahora da la impresión de que Iroh tiene un impulso clarísimo
  • Me gustaría saber qué riesgos hay al operar un relay público. Quisiera entender si, conceptualmente, es similar a operar un Tor Guard Node o un relay
  • El transporte de Tor está en https://github.com/n0-computer/iroh-tor-transport
    Aquí están usando un daemon de Tor. Tor tiene una implementación en Rust, y al usarla desde Rust se puede manejar en una forma parecida a un objeto de stream
    Un ejemplo de uso puede verse en https://gitlab.torproject.org/tpo/core/oniux
  • Si te preocupa que se vuelva imposible de mantener, podría valer la pena considerar una API de feature flags
    El patrón estrategia y la gestión centralizada de funcionalidades son buenas

• No sé si en el video aparecían las “dial keys”, pero creo que en el primer párrafo deberían dejar claro qué tipo de claves son y por qué hacen falta
  No explican si son claves criptográficas, si son asimétricas, ni cómo funcionan aunque sea al nivel más básico. Enseguida pasan a afirmaciones abstractas de superioridad y estadísticas de uso
  Parece que los relays tienen algo que ver, pero sería mejor decirlo desde el principio en vez de obligar a la gente a enterarse buscando en la discusión de HN

  • La primera página no entra en mucho detalle, pero la documentación lo explica rápido
    Primero está https://docs.iroh.computer/what-is-iroh y después la sección de cómo funciona. Por lo que he visto hasta ahora, la documentación sí está bastante bien, y parece responder esas preguntas bastante rápido
  • Vi el video y todavía no sé qué son esas cosas. Además dicen “nunca quedas atado” pero hay “pricing”, y si se supone que los relays se pueden autoalojar, tampoco entiendo por qué habría que pagar por “apps”
  • La explicación “Dial keys. Not IPs.” me suena a una reimplementación de DNS
    Puede ser distribuida, puede ser gratis y puede no ser monolítica, pero en términos amplios entra en la misma categoría
  • Cuando leí “keys”, pensé que eran “nombres” para acceder por clave, como los hosts con nombre en .ssh/config
    Pero mientras más escucho, más suena a una forma nueva de hacer networking sobre QUIC
  • Después de intentar entenderlo un rato, me parece que estas claves cumplen un doble papel: son claves de cifrado y también identificadores estables, algo así como cookies de sesión que podrían usarse para videollamadas WebRTC
    Mi resumen en Lobste.rs, tomando en cuenta que no soy experto y que vi este proyecto por primera vez hoy, es este: se parece más a una configuración de WebRTC con opiniones fuertes que asigna IDs persistentes a los clientes. Ya resuelve la parte de montar servidores de señalización, y la solución parece lo bastante general y barata como para que incluso se puedan usar servidores alojados por la comunidad. Es un poco parecido a lo que se obtiene con la infraestructura P2P propietaria gamenetworkingsocket de Steam
    https://lobste.rs/s/cslljn/iroh_1_0_dial_keys_not_ips#c_s3na...

• Para empezar, no entiendo qué problema intentan resolver. IP y DNS funcionan bien
  Ya existen IPv6 y QUIC, y para lograr tracción real en este espacio hacen falta vendors y software principal

  • Iroh es QUIC. No está intentando reinventar la rueda, sino combinar de forma creativa RFCs existentes del IETF
    En concreto, imagina un dispositivo detrás del NAT del WLAN de tu casa y otro detrás de otro NAT, ya sea en una red 4G o en una empresa
    En la mayoría de los casos se puede crear una conexión directa entre ambos dispositivos muy rápidamente mediante hole punching, obteniendo el mayor ancho de banda posible y la menor latencia
    Este problema no era algo ya resuelto
  • No tengo nada que ver con Iroh ni lo uso, pero decir que “IP funciona bien” no tiene sentido. Este no es un problema resuelto
  • Al contrario, establecer conexiones directas es un problema mucho más difícil con la infraestructura actual de Internet
  • A mí me parece que Iroh está intentando crear la capa de sesión que falta en el modelo OSI. El Location-Identity Separation Protocol de Cisco es un intento parecido
    Como TCP/IP no tiene una verdadera capa de sesión, vMotion normalmente solo es posible dentro de un único dominio de broadcast. En ese contexto, en la práctica solo se usan direcciones MAC para direccionamiento, y aunque la dirección MAC cambie después de un vMotion, se puede usar la IP como identificador estable. El mapeo lo maneja la tabla de direcciones MAC del switch
  • DNS no es tanto descentralizado como federado. Al menos la última vez que vi, Iroh tenía aquí una opción para usar DHT

• El futuro del networking es la descentralización. Me gustan muchísimo Yggdrasil e I2P
  Deberías poder comprar una mini PC para dejarla encendida 24/7, alojar lo que necesites y conectarte fluidamente con otras personas. Mucha gente técnica ya tiene alguna máquina vieja de respaldo juntando polvo, y podría convertirla en servidor
  A largo plazo, es mucho más barato y más fácil de mantener que lidiar con dominios y hosting de servidores. Aprecio sinceramente el trabajo del equipo de Iroh

  • Ese ha sido el futuro desde hace al menos 20 años

• Trabajar con Iroh fue realmente muy bueno, y los ingenieros del canal de Discord también fueron muy amables
  Su enfoque práctico para hacer que P2P simplemente funcione fue fácil de entender, y el contenido de su canal de YouTube también es excelente. Felicidades por el lanzamiento de v1
  https://youtube.com/@n0computer

• ¿No les parece raro que un protocolo que intenta cumplir una función parecida a la de las direcciones IP tenga una etiqueta de precio? Capaz estoy entendiendo algo mal

  • Como ya dijeron otros, la librería principal y el protocolo de iroh son completamente open source
    Lo que pasa es que, para cubrir los costos de desarrollo, ofrecen servicios adicionales que facilitan el despliegue y la operación, especialmente en casos de uso más grandes o especializados
  • Es el síndrome de Tailscale
    Quieren “ser infraestructura para la gente y negocio para los expertos” al mismo tiempo
    Quedan atrapados entre “hace falta dinero para operarlo” y “queremos ser un sistema de infraestructura de bien público”, y las partes negativas de ser una empresa con fines de lucro se despachan con un “bueno, al menos es open source”
    Mientras la parte de “open source” no venga acompañada de una base de código totalmente a medida e incomprensible, me parece que este concepto de negocio está bien hasta cierto punto
  • Si miras esa misma página de precios, todo son servicios adicionales: observabilidad, hosting de relays e ingenieros de soporte
  • Si comparas lo que ofrecen con las direcciones IP, se parece más a operar routers BGP o un ISP, o a contratar ingenieros de red para networking de datacenter
    Está claro que operar un ISP o un AS cuesta bastante dinero
  • Parece que ofrecen “hosting y monitoreo personalizados para apps de Iroh”

• En mi empresa usamos Iroh en producción y realmente nos encanta
  Yo lo describiría sobre todo como hole punching al estilo Tailscale ofrecido como crate de Rust, aunque claramente se le pueden montar muchas funciones P2P geniales encima de la conexión base de QUIC

• En nuestra empresa usamos Iroh para un sistema de entrenamiento distribuido de machine learning en producción y quedamos realmente muy satisfechos
  Incluso antes de firmar un contrato de soporte enterprise, el equipo respondía con una rapidez increíble, tenía conocimientos muy profundos y la librería en sí funcionó sorprendentemente bien. Volvería a usar esta librería antes que libp2p sin pensarlo

• Felicidades por el lanzamiento
  Urge muchísimo una página de comparación con tailscale/netbird/netmaker/zerotier/twingate/openziti
  Viendo solo los casos de uso, por ahora no se ve nada que no se pueda hacer con Tailscale

[GN⁺]

Comentarios de Lobste.rs

• Parece que tanto aquí como en HN hay confusión sobre en qué se diferencia Iroh de una red mesh montada sobre una VPN (Tailscale, ZeroTier, Netbird, etc.). Mi interpretación es que Iroh está pensado para desarrolladores de aplicaciones que quieren comunicación P2P entre dispositivos que ejecutan su propia app, mientras que las redes mesh están dirigidas a administradores de red que quieren conectar entre sí equipos que poseen o gestionan
  Por ejemplo, si haces una app de mensajería P2P, un usuario podría estar en un dispositivo móvil que cambia constantemente entre Wi‑Fi y datos móviles, así que no tiene una dirección estable, y el otro podría estar en una laptop detrás de NAT y CGNAT. Si quieres que ambos se comuniquen aunque cambien las direcciones IP, necesitas algún mecanismo que lo resuelva
  Antes, lo normal era que ambos endpoints se conectaran a un servidor intermediario operado por el desarrollador de la app para compartir estado, pero Iroh parece más bien un intento de estandarizar eso y ofrecerlo como servicio

  • Si lo entendí bien, se parece más a una configuración opinada de WebRTC que asigna una identidad persistente al cliente. O sea, te resuelve el trabajo de construir el servidor de señalización, y la idea es que sea lo bastante genérico y barato como para poder usar incluso un servidor hospedado por la comunidad
    También es algo parecido a lo que obtienes con la infraestructura P2P propietaria gamenetworkingsocket de Steam
  • Entiendo cómo están apuntando al mercado objetivo, pero viendo la tabla de precios, escala según la cantidad de usuarios concurrentes y el límite del tier general es de 5,000. Eso me parece bastante bajo

• Puede que se me esté escapando algo, pero hacer que todo dependa de una sola clave parece muy riesgoso. Me pregunto qué pasa si esa clave se pierde o es comprometida
  Busqué rápidamente “key rotation” en la documentación de Iroh, pero no encontré nada

  • Esas claves son públicas. En Iroh funcionan como una forma de llegar a otros nodos, reemplazando a la dirección IP, que también es información pública
  • El desarrollador tiene que decidir cómo almacenar o rotar las claves. Aquí la clave es un par de claves Ed25519, y como la clave pública se usa como identidad, si la rotas tienes que informarles a tus peers de alguna manera cuál es la nueva clave pública
    Algunas aplicaciones que usan Iroh almacenan la clave de forma permanente, y otras generan una nueva en cada sesión
    Si la clave privada se filtra, un atacante puede hacerse pasar por mí al iniciar o recibir conexiones. Si pierdo la clave, ya no puedo demostrar mi identidad ante mis peers. Según lo entiendo, es un riesgo similar al de perder o que te roben una contraseña normal o una clave privada

• ¿Qué alternativas similares habría? ¿Host Identity Protocol? https://mkomu.kapsi.fi/hipl/index.php?index=how

• Estoy tratando de entender el proyecto, pero no termino de captar bien la diferencia entre clave e IP. Al final, en algún momento la clave tiene que mapearse a una dirección IP para usar enrutamiento IP, ¿no?
  ¿La clave sustituye a una URL o a DNS como una forma de asociar un identificador duradero a una dirección IP?

  • Sí, la “clave” reemplaza a URL/DNS, pero no se asigna a una IP específica. Iroh hace hole punching P2P y relay, y la clave se publica en los servidores relay de Iroh. También puedes operarlos tú mismo
    Si intentas conectar un nodo con otro usando una clave, primero consulta esa clave en uno de los servidores relay, y luego prueba varios métodos: desde una conexión IP directa hasta hole punching y, al final, una conexión relayed a través del servidor relay
    Además, la clave también se usa para el cifrado de extremo a extremo sobre QUIC

• ¿Hay alguna forma de hospedar tu propio servidor relay para una aplicación específica? Parece que sí. Aunque se ve un poco raro que haya una página de precios para relays dedicados

  • Yo diría que con el código que enlazaste ya se puede hacer self-hosting aparte del relay administrado de pago
  • Sí, puedes operar tu propio servidor relay, y ese código enlazado es el correcto. Por ejemplo, DeltaChat lo ejecuta como parte de su relay chatmail. También hay gente que lo embebe dentro de un servidor web existente
    El relay hospedado busca ofrecer eso sin la molestia de administrar tú mismo un servidor, y dar más visibilidad sobre la red

• Esto se siente más cercano a Reticulum que a Yggdrasil o Netbird

• Cuesta entender qué es esto. Me recuerda a Yggdrasil, pero no tengo claro cómo se comparan ambos