Iroh 1.0 - Se connecter par clé plutôt que par IP - Bibliothèque réseau pour connecter des appareils arbitraires

• Iroh 1.0 est la première version stable et garantit la stabilité du wire protocol ainsi que de l’API des langages, ce qui permet à des endpoints iroh v1 de communiquer entre eux независимо de la version mineure ou du langage
• En plus du crate Rust, Python, Node.js, Swift et Kotlin sont officiellement pris en charge, ce qui permet d’embarquer iroh dans des applications Swift iOS et des apps Kotlin Android
• Les changements qui affectent la stabilité du wire interviennent toujours avec une major release, et à l’avenir les versions d’API par langage et la compatibilité wire pourront être versionnées indépendamment
• Après la 1.0, les versions majeures et mineures seront prises en charge selon le calendrier de support, et la version mineure 0.35 ne recevra pas de release supplémentaire
• La prise en charge du public relay sera assurée jusqu’à la fin de vie pour la v1.0, jusqu’au 31 décembre 2026 pour la v0.35x, et jusqu’au 30 septembre 2026 pour les v0.9x et v1.0.0-rcX
• Le public relay passe généralement à la dernière version dans les 24 heures suivant chaque release, et les changements de relay incompatibles au niveau wire utilisent une nouvelle URL afin que les clients existants continuent de fonctionner
• Les fonctionnalités de connexion incluent QUIC multipath, QUIC NAT traversal, une configuration local-first, l’exécution en WASM et dans le navigateur, des hooks de contrôle de connexion et la prise en charge de transports personnalisés
• Pour les connexions, il est courant que 95 % des données soient transmises directement entre appareils, ce qui réduit les sauts via le cloud et les coûts d’egress {p:95}
• Le trafic relayé via le public relay est soumis à des rate limits, et ces limites peuvent changer à tout moment

[GN⁺]

Avis sur Hacker News

• Si vous découvrez Iroh, on peut grosso modo le comprendre comme un Tailscale de couche applicative plutôt que de couche réseau
  La question « pourquoi ne pas simplement utiliser Tailscale ? » est différente du point de vue d’un développeur d’app. Pour connecter facilement des instances d’application entre elles, on pourrait en théorie intégrer les fonctionnalités de Tailscale dans l’app, mais cela obligerait les utilisateurs à avoir un compte Tailscale et rendrait aussi l’app dépendante de Tailscale
  Iroh permet d’intégrer directement cette capacité et fournit aussi des relais publics de secours. Si l’app grossit au point que les relais publics ne suffisent plus, passer à ses propres relais est presque aussi simple que d’actionner un interrupteur

  • C’est seulement avec cette explication que je comprends mieux ce que fait Iroh que dans la vidéo. Maintenant, ce qui m’intéresse, c’est comment Iroh implémente ça
  • Maintenant je comprends la proposition de valeur. L’explication était bien meilleure que la landing page, au point qu’on pourrait presque lui confier les textes marketing
  • Une autre réponse à « pourquoi ne pas utiliser Tailscale », c’est aussi que Tailscale est une entreprise qui cherche à gagner de l’argent, et qu’il est absurde de continuer à concentrer les technologies distribuées entre les mains de quelques propriétaires centraux
    Encore plus si Iroh rend les bonnes pratiques aussi simples et bien faites
  • C’est exactement ça. Je crois que j’ai découvert Iroh en me demandant : « est-ce qu’on pourrait distribuer Tailscale avec notre app ? »
    Dans des environnements où les utilisateurs doivent accéder à des instances locales, Iroh peut être un vrai game changer. Chez nous, cela sert à permettre de piloter facilement un logiciel depuis un téléphone ou un autre appareil
    Avant, il fallait peut-être vérifier qu’on était sur le même LAN, mais avec Iroh, ça fonctionne dans n’importe quel environnement
  • Le point de comparaison le plus proche, c’est OpenZiti
    Iroh et OpenZiti peuvent tous deux être intégrés dans une app, et ce sont tous les deux de bons cas d’usage pour les développeurs qui veulent les embarquer dans un service
    OpenZiti est utilisé pour des services où l’échelle et la sécurité sont cruciales, tandis qu’Iroh peut être très pratique parce qu’il permet aussi à des participants sans relation préalable de se joindre

• Je suis l’un des développeurs d’Iroh
  Une question fréquente est de savoir quand Iroh prendra en charge WebRTC, BLE, LoRa, etc.
  Pour l’instant, Iroh ne prend en charge par défaut que l’IPv4, l’IPv6 et le transport via relais. Il existe tellement de modes de transport intéressants que vouloir tous les prendre en charge transformerait la base de code en un labyrinthe de feature flags impossible à maintenir
  À la place, nous avons permis d’implémenter des transports personnalisés, et leur implémentation peut vivre dans une crate complètement séparée
  Parmi les transports personnalisés expérimentaux existants, on trouve Tor, Nym et BLE. https://github.com/mcginty/iroh-ble-transport
  On peut voir le fonctionnement interne ici : https://www.iroh.computer/blog/iroh-0-97-0-custom-transports...

  • En parcourant la documentation, ça m’a semblé être un projet assez sympa, et j’ai aussi trouvé un exemple de chat P2P
    Si on construit avec ça une configuration client/serveur P2P ou deux machines pair à pair, je me demande quelles sont les limites en termes de configuration supplémentaire nécessaire pour connecter les deux applications
    Par exemple, si je crée une app qui tourne sur un téléphone et une autre sur un laptop, est-ce qu’on obtient réellement entre elles une connexion directe et sécurisée, ou est-ce que ça résout un autre problème ?
    -[0]: p2p chat, in rust, from scratch: https://www.youtube.com/watch?v=ogN_mBkWu7o
  • Pour avoir beaucoup bricolé avec libp2p par le passé, j’aimerais voir une comparaison récente sous l’angle des développeurs d’apps
    L’an dernier, au moment de choisir entre les deux, j’ai pris celui que je connaissais déjà, mais maintenant j’ai l’impression qu’Iroh a clairement le vent en poupe
  • Je me demande quels sont les risques à exploiter des relais publics. Conceptuellement, est-ce similaire au fait d’exploiter un Tor Guard Node ou un relais ?
  • Le transport Tor se trouve sur https://github.com/n0-computer/iroh-tor-transport
    Ici, ils utilisent un démon Tor. Il existe une implémentation de Tor en Rust, et en Rust on peut l’utiliser sous la forme d’un objet de type flux
    Un exemple d’utilisation est visible sur https://gitlab.torproject.org/tpo/core/oniux
  • Si vous craignez que cela devienne impossible à maintenir, il pourrait être utile d’envisager une API de feature flags
    Le pattern Strategy et une gestion centralisée des fonctionnalités sont de bonnes approches

• Je ne sais pas si les « dial keys » étaient expliquées dans la vidéo, mais à mon avis le premier paragraphe devrait préciser clairement de quel type de clés il s’agit et pourquoi elles sont nécessaires
  On ne dit pas s’il s’agit de clés cryptographiques, si elles sont asymétriques, ni même comment cela fonctionne au niveau le plus élémentaire. Le texte enchaîne aussitôt sur des affirmations abstraites de supériorité et des statistiques d’usage
  Il semble que les relais soient impliqués, mais il vaudrait mieux l’expliquer d’emblée au lieu de laisser les gens le découvrir dans la discussion HN

  • La première page n’entre pas dans les détails, mais la documentation l’explique rapidement
    Il y a d’abord https://docs.iroh.computer/what-is-iroh, puis une section sur le fonctionnement. Jusqu’ici, la doc a l’air vraiment correcte et semble répondre assez vite aux questions soulevées
  • J’ai regardé la vidéo et je ne sais toujours pas ce que c’est. Et puis ils disent « ne jamais être dépendant », mais il y a une page « pricing », et je ne comprends pas non plus pourquoi on paierait pour des « apps » si les relais sont auto-hébergés
  • La formule « Dial keys. Not IPs. » me fait penser à une réimplémentation de DNS
    Ça peut être distribué, gratuit et non monolithique, mais au sens large ça reste la même catégorie
  • En lisant « keys », j’ai d’abord pensé à des « noms » permettant d’accéder par clé, comme des hôtes nommés dans .ssh/config
    Mais en creusant un peu plus, on dirait plutôt une nouvelle manière de faire du réseau au-dessus de QUIC
  • Après avoir essayé de comprendre pendant un moment, j’ai l’impression que ces clés jouent un double rôle : clés de chiffrement et identifiants stables, un peu comme des cookies de session qu’on pourrait utiliser pour un appel vidéo WebRTC
    Mon résumé Lobste.rs, en gardant à l’esprit que je ne suis pas expert et que c’est un projet que je découvre aujourd’hui : cela ressemble davantage à une configuration WebRTC très orientée, qui attribue des ID persistants aux clients. Le travail de mise en place d’un serveur de signalisation est déjà géré, et la solution semble suffisamment générique et peu coûteuse pour qu’on puisse utiliser un serveur hébergé par la communauté. C’est un peu comparable à ce qu’apporte l’infrastructure P2P propriétaire gamenetworkingsocket de Steam
    https://lobste.rs/s/cslljn/iroh_1_0_dial_keys_not_ips#c_s3na...

• À la base, je ne comprends pas quel problème ils essaient de résoudre. IP et DNS fonctionnent bien
  On a déjà IPv6 et QUIC, et pour obtenir une adoption significative dans ce domaine, il faut des éditeurs et des logiciels majeurs

  • Iroh, c’est QUIC. Ce n’est pas réinventer la roue, c’est combiner de façon créative des RFC IETF existantes
    Plus précisément, imaginons un appareil derrière le NAT du WLAN domestique, et un autre derrière la 4G ou un autre NAT d’entreprise
    Dans la plupart des cas, le hole punching permet d’établir très rapidement une connexion directe entre les deux appareils, avec la meilleure bande passante possible et la latence la plus faible
    Ce problème n’avait jusqu’à présent pas été résolu
  • Je n’ai aucun lien avec Iroh et je ne l’utilise pas, mais dire que « l’IP fonctionne bien » n’a pas de sens. Ce n’est pas un problème résolu
  • Au contraire, établir une connexion directe est un problème bien plus difficile dans l’infrastructure Internet actuelle
  • À mes yeux, Iroh essaie de créer la couche session manquante dans le modèle OSI. Le Location-Identity Separation Protocol de Cisco est une tentative similaire
    Comme TCP/IP n’a pas de véritable couche session, vMotion n’est en général possible qu’au sein d’un seul domaine de broadcast. Dans cette situation, on utilise en pratique uniquement les adresses MAC pour l’adressage, et même si l’adresse MAC change après un vMotion, l’IP peut rester un identifiant stable. Le mapping est alors géré par la table d’adresses MAC du switch
  • DNS n’est pas tant décentralisé que fédéré. Aux dernières nouvelles, je crois qu’Iroh avait ici une option permettant d’utiliser une DHT

• L’avenir du réseau est décentralisé. J’aime beaucoup Yggdrasil et I2P
  On devrait pouvoir acheter un mini-PC à laisser tourner 24 h/24 pour héberger ce dont on a besoin et se connecter aux autres de manière fluide. Beaucoup de techniciens ont déjà une vieille machine de secours qui prend la poussière et qu’ils pourraient transformer en serveur
  À long terme, ce serait bien moins cher et plus simple à maintenir que de gérer des domaines et de l’hébergement serveur. J’apprécie sincèrement le travail de l’équipe Iroh

  • C’est l’avenir depuis au moins 20 ans

• Iroh a été vraiment agréable à utiliser, et les ingénieurs sur le canal Discord étaient eux aussi très serviables
  L’approche pragmatique qui fait simplement fonctionner le P2P était facile à comprendre, et le contenu de leur chaîne YouTube est excellent. Félicitations pour la sortie de la v1
  https://youtube.com/@n0computer

• Ça ne vous semble pas étrange qu’un protocole censé jouer un rôle similaire à des adresses IP ait une grille tarifaire ? Je me trompe peut-être sur quelque chose

  • Comme d’autres l’ont déjà dit, la bibliothèque centrale et le protocole d’iroh sont entièrement open source
    En revanche, pour financer le développement, ils proposent des services supplémentaires qui facilitent le déploiement et l’exploitation, surtout pour des cas d’usage plus grands ou plus spécifiques
  • C’est le syndrome Tailscale
    Vouloir « être de l’infrastructure pour les gens, et un business pour les experts »
    C’est coincé entre « il faut de l’argent pour l’exploiter » et « on veut devenir un système d’infrastructure de bien public », et les aspects négatifs d’une entreprise à but lucratif sont balayés d’un « oui mais c’est open source »
    Tant que la mention « open source » ne s’accompagne pas d’une base de code entièrement sur mesure et incompréhensible, je trouve que ce concept business reste acceptable dans une certaine mesure
  • Si on regarde cette même page de tarification, tout correspond à des services additionnels : observabilité, hébergement de relais, ingénieurs support et ce genre de choses
  • Si l’on compare ce qu’ils fournissent aux adresses IP, cela ressemble davantage à l’exploitation de routeurs BGP ou d’un FAI, ou au fait de faire appel à des ingénieurs réseau pour du réseau en datacenter
    Il est certain qu’exploiter un FAI ou un AS coûte beaucoup d’argent
  • On dirait qu’ils proposent de « l’hébergement et du monitoring sur mesure pour les applications Iroh »

• On utilise Iroh en production dans notre entreprise et on en est vraiment contents
  Je le décrirais surtout comme du hole punching façon Tailscale fourni sous forme de crate Rust, même si on peut évidemment ajouter beaucoup de fonctionnalités P2P intéressantes au-dessus de la connexion QUIC de base

• Notre entreprise a utilisé Iroh pour un système distribué d’entraînement de machine learning en production, et nous en avons été très satisfaits
  Même avant de signer un contrat de support entreprise, l’équipe répondait avec une rapidité incroyable, avec une expertise très profonde, et la bibliothèque elle-même fonctionnait remarquablement bien. Je réutiliserais cette bibliothèque sans hésiter plutôt que libp2p

• Félicitations pour la sortie
  Il faut d’urgence une page de comparaison avec tailscale/netbird/netmaker/zerotier/twingate/openziti
  À voir uniquement les cas d’usage, on ne voit pas encore ce que Tailscale ne permet pas de faire aujourd’hui

[GN⁺]

Avis sur Lobste.rs

• Ici comme sur HN, beaucoup semblent confondre la différence entre Iroh et les réseaux mesh superposés à un VPN (Tailscale, ZeroTier, Netbird, etc.). Mon interprétation, c’est qu’Iroh s’adresse aux développeurs d’applications qui veulent faire communiquer en P2P des appareils exécutant leur propre app, tandis que les réseaux mesh visent les administrateurs réseau qui veulent relier entre eux des machines qu’ils possèdent ou gèrent
  Par exemple, si on crée une application de messagerie P2P, un utilisateur peut être sur un appareil mobile qui bascule sans cesse entre Wi‑Fi et données mobiles, donc sans adresse stable, tandis que l’autre peut être sur un portable derrière du NAT et du CGNAT. Si on veut qu’ils puissent communiquer même quand les adresses IP changent, il faut un mécanisme pour gérer ça
  Avant, on passait généralement par un serveur d’intermédiation exploité par le développeur de l’application, auquel les deux endpoints se connectaient pour partager leur état ; Iroh semble plutôt vouloir standardiser cela et le proposer comme service

  • Si j’ai bien compris, ça ressemble davantage à une configuration WebRTC opinionated qui attribue un identifiant persistant aux clients. En gros, cela évite d’avoir à construire son propre serveur de signalisation, avec une architecture suffisamment générique et peu coûteuse pour pouvoir utiliser un serveur hébergé par la communauté
    C’est aussi un peu comparable à ce qu’apporte l’infrastructure P2P propriétaire gamenetworkingsocket de Steam
  • Je vois comment ils positionnent leur marché cible, mais la grille tarifaire évolue selon le nombre d’utilisateurs simultanés, avec un plafond de 5 000 pour les offres standard. Ça me paraît quand même assez bas

• Je rate peut-être quelque chose, mais faire reposer tout le système sur une seule clé me semble extrêmement risqué. Je me demande ce qui se passe si cette clé est perdue ou compromise
  J’ai fait une recherche rapide sur « key rotation » dans la documentation d’Iroh, sans rien trouver

  • Ce sont des clés publiques. Dans Iroh, elles remplacent les adresses IP, qui sont elles aussi des informations publiques, comme moyen d’atteindre les autres nœuds
  • La manière de stocker ou de faire tourner ces clés est laissée au développeur. Ici, il s’agit d’une paire de clés Ed25519, et comme la clé publique sert d’identité, toute rotation de clé impose d’informer les pairs de la nouvelle clé publique d’une manière ou d’une autre
    Certaines applications qui utilisent Iroh stockent les clés de façon persistante, d’autres en génèrent de nouvelles à chaque session
    Si la clé privée fuit, un attaquant peut se faire passer pour moi lorsqu’il initie ou reçoit une connexion. Si je perds la clé, je ne peux plus prouver mon identité à mes pairs. De ce que je comprends, le risque est similaire à celui d’un mot de passe ou d’une clé privée classique perdu(e) ou compromis(e)

• Quelles seraient les alternatives proches ? Host Identity Protocol ? https://mkomu.kapsi.fi/hipl/index.php?index=how

• J’essaie de comprendre le projet, mais la différence entre une clé et une IP ne me parle pas vraiment. À un moment ou à un autre, la clé n’est-elle pas mappée vers une adresse IP pour utiliser le routage IP ?
  La clé remplace-t-elle URL ou DNS comme identifiant durable associé à une adresse IP ?

  • Oui, la « clé » remplace URL/DNS, mais elle n’est pas attribuée à une IP particulière. Iroh effectue du hole punching P2P et du relais, et les clés sont publiées sur des serveurs relais Iroh. On peut aussi les exploiter soi-même
    Quand on veut connecter un nœud à un autre via sa clé, on interroge l’un des serveurs relais pour cette clé, puis on essaie plusieurs méthodes : connexion IP directe, hole punching, et en dernier recours connexion relayée via le serveur relais
    Les clés servent aussi au chiffrement de bout en bout via QUIC

• Existe-t-il un moyen d’héberger son propre serveur relais pour une application spécifique ? Ça semble possible. Mais le fait qu’il y ait une page tarifaire distincte pour les relais dédiés paraît un peu étrange

  • Je pense que le code lié suffit à montrer qu’on peut faire de l’auto-hébergement, indépendamment du service de relais managé payant
  • Oui, on peut exploiter son propre serveur relais, et le code lié est bien le bon. Par exemple, DeltaChat l’exécute dans le cadre de ses relais chatmail. Certaines personnes l’embarquent même dans un serveur web existant
    Les relais hébergés servent à fournir cela sans la contrainte de gérer soi-même un serveur, tout en donnant davantage de visibilité sur le réseau

• Ça me paraît plus proche de Reticulum que de Yggdrasil ou Netbird

• J’ai du mal à comprendre ce que c’est. Ça me fait penser à Yggdrasil, mais je ne vois pas bien comment les comparer