Iroh 1.0 – Verbindung per Schlüssel statt IP – Networking-Bibliothek zum Verbinden beliebiger Geräte

• Iroh 1.0 ist das erste stabile Release und garantiert Stabilität des Wire Protocols sowie der Sprach-APIs, sodass iroh-v1-Endpunkte unabhängig von Minor-Version oder Programmiersprache miteinander kommunizieren können
• Zusätzlich zum Rust-Crate gibt es offizielle Unterstützung für Python, Node.js, Swift und Kotlin, wodurch sich iroh in Swift-iOS-Anwendungen und Kotlin-Android-Apps einbetten lässt
• Änderungen, die die Wire-Stabilität beeinflussen, erfolgen immer zusammen mit einem Major Release; künftig können Versionen der Sprach-APIs und die Wire-Kompatibilität unabhängig voneinander versioniert werden
• Nach 1.0 werden Major- und Minor-Versionen gemäß dem Support-Zeitplan unterstützt; die Minor-Version 0.35 erhält keine weiteren Releases
• Die Unterstützung für Public Relay läuft für v1.0 bis zum End of Life, für v0.35x bis zum 31. Dezember 2026 und für v0.9x sowie v1.0.0-rcX bis zum 30. September 2026
• Public Relays werden in der Regel innerhalb von 24 Stunden nach jedem Release auf die neueste Version aktualisiert; bei Wire-Breaking-Änderungen an Relays wird eine neue URL verwendet, damit bestehende Clients weiter funktionieren
• Zu den Verbindungsfunktionen gehören QUIC multipath, QUIC NAT traversal, Local-First-Konfigurationen, Ausführung in WASM und im Browser, Hooks zur Verbindungssteuerung sowie Unterstützung für Custom Transports
• Bei Verbindungen werden typischerweise 95 % der Daten direkt zwischen Geräten übertragen; laut Beschreibung reduzieren direkte Verbindungen Cloud-Hops und Egress-Kosten {p:95}
• Für den weitergeleiteten Traffic über Public Relays gelten Rate Limits, und diese Grenzen können jederzeit geändert werden

[GN⁺]

Hacker-News-Kommentare

• Wenn man Iroh zum ersten Mal sieht, kann man es grob als Tailscale auf Anwendungsebene statt auf Netzwerkebene verstehen
  „Warum nicht einfach Tailscale verwenden?“ — aus Sicht von App-Entwicklern ist das etwas anderes. Wenn sich App-Instanzen leicht miteinander verbinden lassen sollen, könnte man Tailscale-Funktionalität theoretisch in die App einbauen, aber dann brauchen die Nutzer ein Tailscale-Konto und die App hängt ebenfalls von Tailscale ab
  Mit Iroh kann man diese Funktion direkt einbetten, und es gibt auch öffentliche Bootstrap-Relays. Wenn eine App so groß wird, dass öffentliche Relays nicht mehr ausreichen, ist der Wechsel zu einem eigenen Relay fast nur noch ein Kippschalter

  • Erst durch diese Erklärung verstehe ich besser als durch das Video, was Iroh eigentlich macht. Jetzt frage ich mich nur noch, wie Iroh das umsetzt
  • Jetzt verstehe ich das Nutzenversprechen. Das wurde viel besser erklärt als auf der Landingpage — man könnte der Person glatt die Marketingtexte überlassen
  • Eine Antwort auf „Warum nicht Tailscale?“ ist auch, dass Tailscale ein Unternehmen ist, das Geld verdienen will, und dass es unklug ist, verteilte Technologien weiter bei wenigen zentralen Eigentümern zu konzentrieren
    Das gilt umso mehr, wenn Iroh es so einfach und so gut macht, den richtigen Weg zu gehen
  • Genau das. Ich glaube, ich habe Iroh gefunden, nachdem ich mich gefragt hatte: „Könnten wir Tailscale zusammen mit unserer App ausliefern?“
    In Umgebungen, in denen Nutzer auf lokale Instanzen zugreifen müssen, könnte Iroh ein Game Changer sein. Für uns geht es darum, Software einfach vom Handy oder von anderen Geräten aus zu steuern
    Früher musste man vielleicht prüfen, ob alles im selben LAN ist, aber mit Iroh funktioniert es in jeder Umgebung
  • Der naheliegendste Vergleich ist OpenZiti
    Sowohl Iroh als auch OpenZiti lassen sich in Apps einbetten und sind beide gute Optionen für App-Entwickler, die das in ihre Services integrieren wollen
    OpenZiti wird für Services verwendet, bei denen Größe und Sicherheit wichtig sind, während Iroh sehr praktisch sein kann, weil auch Teilnehmer ohne vorherige Beziehung mitmachen können

• Ich bin einer der Iroh-Entwickler
  Eine häufige Frage ist, wann Iroh WebRTC, BLE, LoRa usw. unterstützen wird
  Aktuell unterstützt Iroh standardmäßig nur IPv4, IPv6 und Relay-Transport. Es gibt so viele interessante Transportarten, dass die Codebasis zu einem unwartbaren Labyrinth aus Feature-Flags würde, wenn wir versuchen würden, alles zu unterstützen
  Stattdessen haben wir es ermöglicht, benutzerdefinierte Transporte zu implementieren, und die Transport-Implementierung kann in einem komplett separaten Crate liegen
  Zu den bestehenden experimentellen benutzerdefinierten Transporten gehören Tor, Nym und BLE. https://github.com/mcginty/iroh-ble-transport
  Wie das intern funktioniert, sieht man hier: https://www.iroh.computer/blog/iroh-0-97-0-custom-transports...

  • Ich habe in der Dokumentation gestöbert und das Projekt sieht ziemlich cool aus; ich habe auch ein P2P-Chat-Beispiel gefunden
    Wenn man damit eine P2P-Client/Server-Konfiguration oder zwei Peer-Maschinen baut, würde mich interessieren, wo die Grenzen liegen und was man zusätzlich einrichten muss, damit zwei Anwendungen miteinander verbunden werden
    Zum Beispiel: Wenn ich eine App baue, die auf einem Handy läuft, und eine App, die auf einem Laptop läuft — bekomme ich dann tatsächlich eine direkte und sichere Verbindung zwischen beiden, oder löst das etwas anderes?
    -[0]: p2p chat, in rust, from scratch: https://www.youtube.com/watch?v=ogN_mBkWu7o
  • Aus der Sicht von jemandem, der früher viel mit libp2p gebaut hat, würde ich gern einen aktuellen Vergleich aus App-Entwickler-Perspektive sehen
    Letztes Jahr habe ich mich zwischen beiden für das Vertraute entschieden, aber im Moment fühlt es sich so an, als hätte Iroh klar Rückenwind
  • Mich würde interessieren, welche Risiken es beim Betrieb eines öffentlichen Relays gibt. Ist das konzeptionell vergleichbar mit dem Betrieb eines Tor-Guard-Nodes oder eines Relays?
  • Der Tor-Transport liegt unter https://github.com/n0-computer/iroh-tor-transport
    Dort wird ein Tor-Daemon verwendet. Es gibt eine Rust-Implementierung von Tor, und in Rust kann man sie in Form von Stream-Objekten oder Ähnlichem verwenden
    Ein Nutzungsbeispiel findet sich unter https://gitlab.torproject.org/tpo/core/oniux
  • Wenn ihr euch Sorgen macht, dass es unwartbar wird, wäre vielleicht eine Feature-Flag-API einen Blick wert
    Das Strategy Pattern und zentralisiertes Feature-Management sind gut

• Ich weiß nicht, ob „Dial keys“ im Video vorkamen, aber ich finde, im ersten Absatz sollte klar gemacht werden, um welche Art von Schlüsseln es sich handelt und warum sie nötig sind.
  Es wird nicht erklärt, ob es sich um kryptographische Schlüssel handelt, ob sie asymmetrisch sind oder auch nur auf einem sehr grundlegenden Niveau, wie das funktioniert. Stattdessen geht es sofort zu abstrakten Überlegenheitsbehauptungen und Nutzungsstatistiken über.
  Es scheint etwas mit Relays zu tun zu haben; besser, man sagt das von Anfang an, statt die Leute es in der HN-Diskussion herausfinden zu lassen.

  • Die Startseite geht nicht allzu tief hinein, aber die Doku erklärt es ziemlich schnell.
    Zuerst gibt es https://docs.iroh.computer/what-is-iroh, danach folgt ein Abschnitt zur Funktionsweise. Soweit ich das bisher sehe, ist die Dokumentation tatsächlich ziemlich gut, und die aufgekommenen Fragen werden recht schnell beantwortet.
  • Ich habe das Video gesehen und weiß immer noch nicht, was diese Dinger sind. Außerdem heißt es „niemals Lock-in“, aber es gibt „Pricing“, und wenn man Relays selbst hostet, verstehe ich auch nicht, warum man für „Apps“ bezahlt.
  • Die Beschreibung „Dial keys. Not IPs.“ klingt für mich wie eine Neuumsetzung von DNS.
    Es mag dezentral sein, kostenlos sein und kein Monolith, aber grob gesehen fällt es in dieselbe Kategorie.
  • Als ich „keys“ gelesen habe, dachte ich an „Namen“, über die man per Schlüssel zugreift, wie benannte Hosts in .ssh/config.
    Aber je mehr ich darüber höre, desto mehr klingt es wie eine neue Art von Networking auf QUIC.
  • Nachdem ich eine Weile versucht habe, es zu verstehen, scheinen diese Schlüssel eine Doppelrolle zu spielen: Verschlüsselungsschlüssel und zugleich stabile Identifikatoren, ähnlich Session-Cookies, die man für WebRTC-Videoanrufe nutzen könnte.
    Meine Lobste.rs-Zusammenfassung, unter dem Vorbehalt, dass ich kein Experte bin und das Projekt heute zum ersten Mal gesehen habe, lautet so: Das ist eher eine meinungsstarke WebRTC-Konfiguration, die Clients persistente IDs zuweist. Die Arbeit, Signaling-Server zu bauen, ist bereits erledigt, und die Lösung ist allgemein genug und günstig genug, dass man auch Community-gehostete Server nutzen kann. Es ist ein bisschen ähnlich zu dem, was man aus Steams proprietärer P2P-gamenetworkingsocket-Infrastruktur bekommt.
    https://lobste.rs/s/cslljn/iroh_1_0_dial_keys_not_ips#c_s3na...

• Ich verstehe schon grundsätzlich nicht, welches Problem hier gelöst werden soll. IP und DNS funktionieren gut.
  Es gibt bereits IPv6 und QUIC, und um in diesem Bereich nennenswerte Traktion zu bekommen, braucht man Hersteller und große Softwareanbieter.

  • Iroh ist QUIC. Es versucht nicht, das Rad neu zu erfinden, sondern kombiniert bestehende IETF-RFCs auf kreative Weise.
    Konkret: Angenommen, du hast ein Gerät hinter dem NAT eines Heim-WLANs und ein anderes Gerät hinter 4G oder einem anderen NAT in einem Unternehmen.
    In den meisten Fällen kann man per Hole Punching sehr schnell eine direkte Verbindung zwischen diesen beiden Geräten herstellen und bekommt die höchstmögliche Bandbreite und die niedrigste Latenz.
    Dieses Problem war bisher nicht wirklich gelöst.
  • Ich habe mit Iroh nichts zu tun und nutze es auch nicht, aber zu sagen, „IP funktioniert gut“, ergibt keinen Sinn. Das ist kein gelöstes Problem.
  • Im Gegenteil: Eine direkte Verbindung aufzubauen ist in der heutigen Internet-Infrastruktur ein deutlich schwierigeres Problem.
  • Für mich sieht es so aus, als wolle Iroh die im OSI-Modell fehlende Session-Schicht schaffen. Ciscos Location-Identity Separation Protocol ist ein ähnlicher Versuch.
    Weil TCP/IP keine echte Session-Schicht hat, ist vMotion normalerweise nur innerhalb einer einzelnen Broadcast-Domain möglich. In dieser Situation nutzt man für das Adressieren faktisch nur MAC-Adressen, und selbst wenn sich die MAC-Adresse nach einer vMotion ändert, kann man die IP als stabilen Identifikator verwenden. Das Mapping übernimmt die MAC-Adress-Tabelle des Switches.
  • DNS ist nicht so sehr dezentralisiert, sondern eher föderiert. Soweit ich mich erinnere, hatte Iroh hier zumindest einmal die Option, DHT zu verwenden.

• Die Zukunft des Networking ist Dezentralisierung. Ich mag Yggdrasil und I2P sehr.
  Man sollte sich einen Mini-PC kaufen können, der 24/7 läuft, darauf hosten, was man braucht, und sich nahtlos mit anderen verbinden können. Viele technisch versierte Leute haben ohnehin alte Ersatzmaschinen, die nur verstauben und die man zum Server machen könnte.
  Langfristig ist das viel günstiger und einfacher zu warten, als sich mit Domains und Server-Hosting zu beschäftigen. Ich schätze die Arbeit des Iroh-Teams wirklich sehr.

  • Das ist seit mindestens 20 Jahren die Zukunft.

• Mit Iroh zu arbeiten war wirklich großartig, und die Engineers im Discord-Channel waren sehr freundlich.
  Der praktische Ansatz, P2P einfach zum Laufen zu bringen, war leicht zu verstehen, und auch die Inhalte auf dem YouTube-Kanal sind hervorragend. Glückwunsch zum v1-Release.
  https://youtube.com/@n0computer

• Wirkt es nicht seltsam, dass ein Protokoll, das etwas Ähnliches wie IP-Adressen leisten soll, ein Preisschild hat? Vielleicht missverstehe ich etwas.

  • Wie andere bereits gesagt haben, sind die Kernbibliothek und das Protokoll von iroh vollständig Open Source.
    Um jedoch die Entwicklungskosten zu decken, bieten sie zusätzliche Services an, die besonders bei größeren oder spezielleren Einsatzfällen Deployment und Betrieb erleichtern.
  • Das ist das Tailscale-Syndrom.
    Der Zustand, in dem man „für die Leute Infrastruktur und für Fachleute ein Business“ sein möchte.
    Man steckt zwischen „Der Betrieb kostet Geld“ und „Wir wollen eine Infrastruktur als öffentliches Gut sein“, und die negativen Seiten eines gewinnorientierten Unternehmens werden mit „ist doch Open Source“ beiseitegeschoben.
    Solange der Zusatz „Open Source“ nicht mit einer komplett maßgeschneiderten und unverständlichen Codebasis einhergeht, finde ich solche Business-Konzepte bis zu einem gewissen Grad in Ordnung.
  • Wenn man sich dieselbe Pricing-Seite ansieht, sind das alles Zusatzdienste. Dinge wie Observability, Relay-Hosting und Support-Engineers.
  • Wenn man das, was sie anbieten, mit IP-Adressen vergleichen will, ist es eher damit vergleichbar, BGP-Router oder einen ISP zu betreiben oder für Data-Center-Networking Netzwerkingenieure zu beauftragen.
    Dass der Betrieb eines ISP oder AS ziemlich viel Geld kostet, ist sicher.
  • Es scheint, als würden sie „maßgeschneidertes Hosting und Monitoring für Iroh-Apps“ anbieten.

• Wir nutzen Iroh in der Produktion in unserer Firma und sind wirklich begeistert.
  Ich würde es hauptsächlich als Tailscale-artiges Hole Punching, bereitgestellt als Rust-Crate, beschreiben, aber natürlich kann man auf der grundlegenden QUIC-Verbindung noch viele coole P2P-Funktionen aufsetzen.

• Unsere Firma hat Iroh in einem produktiven verteilten Machine-Learning-Trainingssystem eingesetzt und wir waren wirklich sehr zufrieden.
  Noch bevor wir einen Enterprise-Support-Vertrag abgeschlossen hatten, reagierte das Team unglaublich schnell, verfügte über sehr tiefes Wissen, und die Bibliothek selbst funktionierte erstaunlich gut. Ich würde diese Bibliothek libp2p jederzeit wieder vorziehen.

• Glückwunsch zum Release
  Es wird dringend eine Versus-Seite benötigt, die den Vergleich mit tailscale/netbird/netmaker/zerotier/twingate/openziti zeigt
  Wenn man sich nur die Anwendungsfälle ansieht, ist aktuell nicht erkennbar, was damit möglich ist, was mit Tailscale nicht geht

[GN⁺]

Lobste.rs-Kommentare

• Sowohl hier als auch auf HN scheinen viele zu verwechseln, worin sich Iroh von einem über ein VPN gelegten Mesh-Netzwerk (Tailscale, ZeroTier, Netbird usw.) unterscheidet. Meine Lesart ist: Iroh ist für Anwendungsentwickler gedacht, die P2P-Kommunikation zwischen Geräten wollen, auf denen ihre eigene App läuft, während Mesh-Netzwerke eher für Netzwerkadministratoren gedacht sind, die Geräte verbinden wollen, die sie besitzen oder verwalten.
  Wenn man zum Beispiel eine P2P-Messaging-App baut, könnte der eine Nutzer ein mobiles Gerät haben, das ständig zwischen WLAN und mobilen Daten wechselt und daher keine stabile Adresse hat, während der andere einen Laptop hinter NAT und CGNAT nutzt. Wenn diese beiden trotz wechselnder IP-Adressen miteinander kommunizieren sollen, braucht man einen Mechanismus, der das handhabt.
  Früher lief das meist so, dass beide Endpunkte sich mit einem vom App-Entwickler betriebenen Vermittlungsserver verbinden und dort ihren Status austauschen; Iroh wirkt eher wie der Versuch, das zu standardisieren und als Dienst anzubieten.

  • Wenn ich das richtig verstanden habe, wirkt es eher wie eine meinungsstarke WebRTC-Konfiguration, die Clients eine dauerhafte ID gibt. Das heißt, einem wird die Arbeit abgenommen, einen Signalisierungsserver zu bauen, und das Ganze ist allgemein genug und günstig genug, dass auch community-gehostete Server praktikabel sind.
    Es ist auch ein wenig vergleichbar mit dem, was man von Steams proprietärer P2P-gamenetworkingsocket-Infrastruktur bekommt.
  • Ich verstehe, auf welchen Zielmarkt sie zielen, aber laut Preismodell skaliert das nach der Zahl der gleichzeitigen Nutzer, und das normale Tier hat eine Obergrenze von 5.000. Das erscheint mir ziemlich niedrig.

• Vielleicht übersehe ich etwas, aber alles an einen einzigen Schlüssel zu hängen, wirkt ziemlich riskant. Ich frage mich, was passiert, wenn dieser Schlüssel verloren geht oder kompromittiert wird.
  Ich habe in der Iroh-Dokumentation kurz nach „key rotation“ gesucht, aber nichts gefunden.

  • Das sind öffentliche Schlüssel. In Iroh ersetzen sie als Mittel, andere Knoten zu erreichen, die ebenfalls öffentlichen IP-Adressen.
  • Wie Schlüssel gespeichert oder rotiert werden, muss der Entwickler entscheiden. Hier handelt es sich um ein Ed25519-Schlüsselpaar, und weil der öffentliche Schlüssel als Identität dient, muss man bei einer Rotation den neuen öffentlichen Schlüssel den Peers irgendwie bekannt machen.
    Einige Anwendungen mit Iroh speichern Schlüssel dauerhaft, andere erzeugen sie für jede Sitzung neu.
    Wenn der private Schlüssel kompromittiert wird, kann ein Angreifer sich als ich ausgeben, wenn er Verbindungen initiiert oder annimmt. Geht der Schlüssel verloren, kann ich Peers meine Identität nicht mehr nachweisen. Soweit ich das verstehe, ist das ein ähnliches Risiko wie beim Verlust oder Diebstahl eines normalen Passworts oder privaten Schlüssels.

• Welche ähnlichen Alternativen gibt es? Host Identity Protocol? https://mkomu.kapsi.fi/hipl/index.php?index=how

• Ich versuche das Projekt zu verstehen, aber der Unterschied zwischen Schlüssel und IP wird mir nicht ganz klar. Irgendwann wird der Schlüssel doch auf eine IP-Adresse abgebildet, damit IP-Routing überhaupt funktioniert, oder?
  Ist der Schlüssel einfach ein langlebiger Identifikator, der an die IP-Adresse gebunden wird und URL oder DNS ersetzt?

  • Genau, der „Schlüssel“ ersetzt URL/DNS, wird aber nicht einer bestimmten IP zugewiesen. Iroh macht P2P-Hole-Punching und Relay, und die Schlüssel werden auf Iroh-Relay-Servern veröffentlicht. Man kann diese auch selbst betreiben.
    Wenn man versucht, einen Knoten über seinen Schlüssel mit einem anderen zu verbinden, wird der Schlüssel auf einem der Relay-Server nachgeschlagen, und dann werden verschiedene Methoden ausprobiert: von einer direkten IP-Verbindung über Hole-Punching bis hin zu einer weitergeleiteten Verbindung über den Relay-Server.
    Außerdem werden die Schlüssel auch für Ende-zu-Ende-Verschlüsselung über QUIC verwendet.

• Gibt es eine Möglichkeit, einen eigenen Relay-Server für eine bestimmte Anwendung zu hosten? Scheint möglich zu sein. Etwas seltsam wirkt nur, dass es eine Preisübersicht für dedizierte Relays gibt.

  • Ich würde annehmen, dass man mit dem verlinkten Code selbst hosten kann, getrennt von den kostenpflichtigen Managed-Relays.
  • Ja, man kann eigene Relay-Server betreiben, und der verlinkte Code ist der richtige. DeltaChat führt das zum Beispiel als Teil seines chatmail-Relays aus. Manche betten das auch in bestehende Webserver ein.
    Gehostete Relays sollen das ohne den Aufwand der eigenen Serververwaltung ermöglichen und zugleich mehr Sichtbarkeit ins Netzwerk geben.

• Das fühlt sich eher nach Reticulum als nach Yggdrasil oder Netbird an.

• Es ist schwer zu verstehen, was das eigentlich ist. Mich erinnert es an Yggdrasil, aber ich weiß nicht genau, wie die beiden im Vergleich zueinander stehen.