Iroh 1.0 - Terhubung dengan kunci, bukan IP - pustaka jaringan untuk menghubungkan perangkat arbitrer

 (iroh.computer)
1 poin oleh GN⁺ 4 jam lalu | 2 komentar | Bagikan ke WhatsApp
  • Iroh 1.0 adalah rilis stabil pertamanya, dan menjamin stabilitas wire protocol serta API bahasa sehingga endpoint iroh v1 dapat saling berkomunikasi terlepas dari minor version atau bahasanya
  • Selain Rust crate, kini ada dukungan resmi untuk Python, Node.js, Swift, Kotlin, sehingga iroh dapat di-embed ke aplikasi Swift iOS dan aplikasi Kotlin Android
  • Perubahan yang memengaruhi stabilitas wire selalu hadir bersama major release, dan ke depannya versi API bahasa serta kompatibilitas wire dapat dikelola versinya secara terpisah
  • Setelah 1.0, major dan minor version akan didukung sesuai jadwal dukungan, dan minor version 0.35 tidak akan menerima rilis tambahan
  • Dukungan Public relay akan berlanjut hingga End of Life untuk v1.0, hingga 31 Desember 2026 untuk v0.35x, dan hingga 30 September 2026 untuk v0.9x serta v1.0.0-rcX
  • Public relay biasanya diperbarui ke versi terbaru dalam waktu 24 jam setelah setiap rilis, dan perubahan relay yang memutus kompatibilitas wire akan menggunakan URL baru agar klien lama tetap dapat berjalan
  • Fitur koneksi mencakup QUIC multipath, QUIC NAT traversal, konfigurasi local-first, eksekusi WASM dan browser, hook kontrol koneksi, serta dukungan custom transport
  • Dalam koneksi, umumnya 95% data ditransfer langsung antarperangkat, dan dijelaskan bahwa koneksi langsung mengurangi hop melalui cloud serta biaya egress {p:95}
  • Relayed traffic pada public relay memiliki rate limit, dan batas tersebut dapat berubah kapan saja

Bacaan terkait

2 komentar

 
GN⁺ 3 jam lalu
Komentar Hacker News

  • Jika baru pertama kali melihat Iroh, kira-kira anggap saja ini sebagai Tailscale di lapisan aplikasi, bukan lapisan jaringan
    Pertanyaan “kenapa tidak pakai Tailscale saja?” berbeda jika dilihat dari sudut pandang pengembang aplikasi. Jika ingin instance aplikasi bisa saling terhubung dengan mudah, secara teori kita bisa menanamkan fungsi Tailscale ke dalam aplikasi, tetapi itu berarti pengguna memerlukan akun Tailscale dan aplikasinya juga jadi bergantung pada Tailscale
    Iroh memungkinkan fungsi ini ditanamkan secara langsung, dan juga menyediakan relay publik cadangan. Jika aplikasi berkembang sampai relay publik tidak lagi sanggup menanganinya, beralih ke relay sendiri hampir seperti hanya menekan satu sakelar

    • Baru setelah membaca penjelasan ini saya lebih paham apa yang dilakukan Iroh dibanding menonton videonya
    • Sekarang proposisi nilainya jadi masuk akal. Penjelasannya jauh lebih bagus daripada landing page, sampai rasanya orang ini bisa sekalian disuruh menulis copy pemasaran
    • Jawaban lain untuk “kenapa tidak pakai Tailscale” adalah karena Tailscale adalah perusahaan yang ingin menghasilkan uang, dan bodoh jika kita terus memusatkan teknologi terdistribusi ke segelintir pemilik terpusat
      Apalagi jika Iroh membuat cara yang benar menjadi semudah dan sebagus ini
    • Tepat sekali. Sepertinya saya menemukan Iroh setelah berpikir, “bisakah kita mendistribusikan aplikasi kita bersama Tailscale?”
      Dalam lingkungan tempat pengguna perlu mengakses instance lokal, saya rasa Iroh bisa menjadi game changer. Bagi kami, ini dipakai agar perangkat lunak bisa dikendalikan dengan mudah dari ponsel atau perangkat lain
      Dulu mungkin kami harus memastikan semua ada di LAN yang sama, tetapi dengan Iroh ini bisa berjalan di lingkungan apa pun
    • Pembanding terdekatnya adalah OpenZiti
      Iroh dan OpenZiti sama-sama bisa ditanamkan ke dalam aplikasi, dan keduanya cocok sebagai use case bagi pengembang aplikasi yang ingin menanamkannya ke dalam layanan
      OpenZiti dipakai untuk layanan yang mengutamakan skala dan keamanan, sedangkan Iroh bisa sangat praktis karena memungkinkan peserta tanpa hubungan awal untuk ikut bergabung

  • Saya salah satu pengembang Iroh
    Pertanyaan yang sering muncul adalah kapan Iroh akan mendukung WebRTC, BLE, LoRa, dan sebagainya
    Saat ini Iroh secara default hanya mendukung IPv4, IPv6, dan transfer melalui relay. Ada terlalu banyak metode transport yang menarik; kalau mencoba mendukung semuanya, codebase akan berubah menjadi labirin feature flag yang mustahil dipelihara
    Sebagai gantinya, kami membuatnya agar transport kustom bisa diimplementasikan, dan implementasi transport bisa ditempatkan di crate yang sepenuhnya terpisah
    Transport kustom eksperimental yang sudah ada mencakup Tor, Nym, dan BLE. https://github.com/mcginty/iroh-ble-transport
    Cara kerja internalnya bisa dilihat di sini: https://www.iroh.computer/blog/iroh-0-97-0-custom-transports...

    • Saat melihat dokumentasinya, proyek ini tampak cukup keren, dan saya juga menemukan contoh chat P2P
      Jika membuat konfigurasi klien/server P2P atau dua mesin peer dengan ini, saya penasaran batasannya seperti apa terkait hal lain yang masih perlu dikonfigurasi agar dua aplikasi itu bisa saling terhubung
      Misalnya, jika saya membuat aplikasi yang berjalan di ponsel dan aplikasi yang berjalan di laptop, apakah saya benar-benar bisa mendapatkan koneksi langsung dan aman di antara keduanya, atau justru ini menyelesaikan masalah yang berbeda?
      -[0]: p2p chat, in rust, from scratch: https://www.youtube.com/watch?v=ogN_mBkWu7o
    • Dari sudut pandang orang yang dulu banyak membangun sesuatu dengan basis libp2p, saya ingin melihat perbandingan terbaru yang berfokus pada pengembang aplikasi
      Tahun lalu saya memilih salah satu dari keduanya dan akhirnya memilih yang lebih familiar, tetapi sekarang terasa ada momentum yang jelas di pihak Iroh
    • Saya penasaran, jika ada risiko dalam menjalankan relay publik, apakah secara konsep ini mirip dengan menjalankan Tor Guard Node atau relay?
    • Transport Tor ada di https://github.com/n0-computer/iroh-tor-transport
      Di sini mereka menggunakan daemon Tor. Tor memiliki implementasi Rust, dan jika dipakai dari Rust bisa digunakan dalam bentuk seperti objek stream
      Contoh penggunaannya bisa dilihat di https://gitlab.torproject.org/tpo/core/oniux
    • Jika khawatir akan menjadi sulit dipelihara, mungkin layak mempertimbangkan API feature flag
      Pola strategi dan pengelolaan fitur yang terpusat itu bagus

  • Saya tidak tahu apakah “Dial keys” ada di video itu, tetapi menurut saya paragraf pertama seharusnya memperjelas jenis key apa ini dan mengapa diperlukan
    Tidak ada penjelasan apakah ini kunci kriptografis, apakah kunci asimetris, atau setidaknya bagaimana cara kerjanya pada tingkat paling dasar. Langsung masuk ke klaim keunggulan yang abstrak dan statistik penggunaan
    Sepertinya relay ada kaitannya, tetapi lebih baik dijelaskan dari awal daripada membuat orang harus menemukannya sendiri di diskusi HN

    • Halaman pertama memang tidak terlalu mendalam, tetapi dokumentasinya menjelaskan dengan cepat
      Pertama ada https://docs.iroh.computer/what-is-iroh, lalu ada bagian tentang cara kerjanya. Dari yang saya lihat sejauh ini, dokumentasinya sebenarnya cukup bagus, dan pertanyaan-pertanyaan yang muncul tampaknya dijawab dengan cukup cepat
    • Saya sudah menonton videonya, tetapi masih belum paham itu apa. Selain itu, mereka bilang “tidak pernah terkunci pada vendor”, tetapi ada “pricing”, dan kalau relay-nya bisa self-hosted, saya juga tidak paham kenapa harus membayar untuk “apps”
    • Penjelasan “Dial keys. Not IPs.” terdengar bagi saya seperti implementasi ulang DNS
      Mungkin terdistribusi, mungkin gratis, mungkin bukan monolit, tetapi secara luas masih termasuk kategori yang sama
    • Saat membaca “keys”, saya mengira itu “nama” untuk mengakses lewat key, seperti host bernama di .ssh/config
      Tetapi setelah mendengar lebih lanjut, ini terdengar seperti cara baru melakukan networking di atas QUIC
    • Setelah mencoba memahaminya beberapa saat, sepertinya key ini berperan ganda sebagai kunci enkripsi sekaligus pengenal stabil mirip cookie sesi yang bisa dipakai untuk panggilan video WebRTC
      Ringkasan versi Lobste.rs dari saya, dengan catatan saya bukan ahli dan ini proyek yang baru pertama kali saya lihat hari ini, adalah: ini lebih mirip setup WebRTC yang opinionated, yang memberi klien ID persisten. Pekerjaan membuat server signaling sudah ditangani, dan solusinya cukup umum serta murah sehingga Anda bisa memakai server yang di-host komunitas. Agak mirip dengan yang didapat dari infrastruktur P2P gamenetworkingsocket milik Steam yang bersifat eksklusif
      https://lobste.rs/s/cslljn/iroh_1_0_dial_keys_not_ips#c_s3na...

  • Dari awal saya tidak paham masalah apa yang sebenarnya ingin diselesaikan. IP dan DNS sudah bekerja dengan baik
    Kita sudah punya IPv6 dan QUIC, dan untuk mendapatkan adopsi yang berarti di area ini dibutuhkan vendor serta software utama

    • Iroh memang QUIC. Ini bukan upaya menciptakan ulang roda, melainkan menggabungkan RFC IETF yang sudah ada secara kreatif
      Secara spesifik, bayangkan ada satu perangkat di balik NAT pada WLAN rumah, dan perangkat lain di jaringan 4G atau di balik NAT lain di kantor
      Dalam banyak kasus, hole punching bisa membuat koneksi langsung di antara kedua perangkat dengan sangat cepat, sehingga mendapatkan bandwidth setinggi mungkin dan latensi serendah mungkin
      Masalah ini sampai sekarang belum benar-benar terselesaikan
    • Saya tidak terkait dengan Iroh dan juga tidak memakainya, tetapi mengatakan bahwa “IP bekerja dengan baik” itu tidak masuk akal. Ini bukan masalah yang sudah selesai
    • Sebaliknya, membangun koneksi langsung justru merupakan masalah yang jauh lebih sulit dalam infrastruktur internet saat ini
    • Menurut saya, Iroh tampaknya mencoba membuat session layer yang hilang dari model OSI. Location-Identity Separation Protocol milik Cisco juga merupakan upaya serupa
      Karena TCP/IP tidak punya session layer yang sesungguhnya, vMotion biasanya hanya mungkin dalam satu broadcast domain. Dalam situasi itu, pengalamatan pada dasarnya hanya memakai alamat MAC, dan meskipun alamat MAC berubah setelah vMotion, IP masih bisa dipakai sebagai pengenal yang stabil. Pemetaan ini ditangani oleh tabel alamat MAC pada switch
    • DNS bukan benar-benar terdesentralisasi, melainkan lebih mendekati federatif. Setidaknya terakhir kali saya melihat, Iroh tampaknya punya opsi untuk menggunakan DHT di sini

  • Masa depan networking adalah desentralisasi. Saya sangat menyukai Yggdrasil dan I2P
    Kita seharusnya bisa membeli mini PC yang berjalan 24 jam untuk meng-host hal yang dibutuhkan, lalu terhubung mulus dengan orang lain. Banyak orang teknis sudah punya mesin cadangan lama yang cuma berdebu, dan itu bisa dijadikan server
    Dalam jangka panjang, ini jauh lebih murah dan lebih mudah dirawat daripada harus mengurus domain dan hosting server. Saya benar-benar menghargai pekerjaan tim Iroh

    • Itu setidaknya sudah disebut sebagai masa depan selama 20 tahun

  • Iroh sangat menyenangkan untuk dipakai, dan para engineer di channel Discord juga sangat ramah
    Pendekatan praktis untuk membuat P2P benar-benar bekerja mudah dipahami, dan konten di channel YouTube mereka juga luar biasa. Selamat atas rilis v1
    https://youtube.com/@n0computer

  • Bukankah aneh kalau protokol yang mencoba berfungsi mirip alamat IP punya label harga? Mungkin saya salah paham sesuatu

    • Seperti yang sudah dikatakan orang lain, library inti dan protokol iroh sepenuhnya open source
      Hanya saja, untuk menutup biaya pengembangan, mereka juga menawarkan layanan tambahan yang mempermudah deployment dan operasional, terutama untuk use case yang lebih besar atau lebih khusus
    • Ini sindrom Tailscale
      Keadaannya seperti “ingin menjadi infrastruktur bagi orang-orang, tetapi juga bisnis bagi para profesional”
      Terjepit di antara “butuh uang untuk beroperasi” dan “ingin menjadi sistem infrastruktur barang publik”, sementara sisi negatif sebagai perusahaan profit dibersihkan dengan “ya, tapi ini open source”
      Selama embel-embel “open source” itu tidak berarti codebase yang sepenuhnya kustom dan mustahil dipahami, saya rasa konsep bisnis seperti ini masih cukup masuk akal
    • Kalau melihat halaman harga yang sama, semuanya adalah layanan tambahan. Hal-hal seperti observabilitas, hosting relay, dan engineer dukungan
    • Jika dianalogikan ke alamat IP, yang mereka tawarkan lebih mirip menjalankan router BGP atau ISP, atau mengontrak network engineer untuk networking data center
      Jelas menjalankan ISP atau AS memang memerlukan biaya yang besar
    • Sepertinya mereka menyediakan “hosting dan monitoring kustom untuk aplikasi Iroh”

  • Perusahaan saya memakai Iroh di produksi dan kami sangat menyukainya
    Saya terutama akan menjelaskannya sebagai hole punching ala Tailscale yang disediakan sebagai crate Rust, tetapi tentu saja di atas koneksi QUIC dasar Anda juga bisa menambahkan banyak fitur P2P yang keren

  • Perusahaan kami memakai Iroh untuk sistem pelatihan machine learning terdistribusi di produksi, dan kami sangat puas
    Bahkan sebelum menandatangani kontrak dukungan enterprise, timnya merespons dengan sangat cepat, pengetahuannya sangat mendalam, dan library-nya sendiri bekerja dengan sangat baik. Saya akan memilih library ini lagi kapan saja dibanding libp2p

  • Selamat atas peluncurannya
    Hal yang sangat mendesak adalah halaman versus yang membandingkannya dengan tailscale/netbird/netmaker/zerotier/twingate/openziti
    Jika hanya melihat use case-nya, saat ini belum terlihat apa yang tidak bisa dilakukan oleh Tailscale
 
GN⁺ 4 jam lalu
Komentar Lobste.rs

  • Sepertinya baik di sini maupun di HN, banyak yang bingung bagaimana Iroh berbeda dari jaringan mesh yang berjalan di atas VPN (Tailscale, ZeroTier, Netbird, dll.). Menurut pemahaman saya, Iroh ditujukan untuk pengembang aplikasi yang ingin perangkat yang menjalankan aplikasi mereka bisa berkomunikasi P2P, sedangkan jaringan mesh ditujukan untuk administrator jaringan yang ingin menghubungkan perangkat yang mereka miliki atau kelola satu sama lain
    Misalnya Anda membuat aplikasi pesan P2P: satu pengguna mungkin memakai perangkat mobile yang terus berpindah antara WiFi dan data seluler sehingga tidak punya alamat yang stabil, sementara pihak lain mungkin memakai laptop di balik NAT dan CGNAT. Agar keduanya tetap bisa berkomunikasi meski alamat IP berubah, dibutuhkan mekanisme yang menangani hal itu
    Dulu biasanya kedua endpoint terhubung ke server perantara yang dioperasikan pengembang aplikasi lalu berbagi status di sana, dan Iroh tampaknya lebih dekat ke upaya menstandarkan pola itu serta menyediakannya sebagai layanan

    • Kalau pemahaman saya benar, ini tampak lebih mirip konfigurasi WebRTC yang opinionated yang memberi ID persisten ke klien. Artinya pekerjaan membuat server signaling ditangani untuk Anda, dan strukturnya cukup umum serta murah sehingga server yang di-host komunitas pun bisa dipakai
      Agak mirip juga dengan apa yang didapat dari infrastruktur P2P gamenetworkingsocket milik Steam yang proprietari
    • Saya paham bagaimana mereka membidik pasar, tetapi melihat daftar harga, skalanya berdasarkan jumlah pengguna bersamaan dan batas tier biasa adalah 5.000 orang. Rasanya ini cukup rendah, bukan?

  • Mungkin saya melewatkan sesuatu, tetapi menaruh semuanya pada satu kunci terdengar sangat berisiko. Saya penasaran apa yang terjadi jika kunci itu hilang atau dicuri
    Saya sempat mencari cepat “key rotation” di dokumentasi Iroh, tetapi tidak menemukannya

    • Kunci itu adalah kunci publik. Di Iroh, ia berperan sebagai cara untuk mencapai node lain, menggantikan alamat IP yang juga merupakan informasi publik
    • Cara menyimpan atau merotasi kunci harus ditentukan oleh pengembang. Di sini kuncinya adalah pasangan kunci Ed25519, dan karena kunci publik dipakai sebagai identitas, jika kunci dirotasi maka kunci publik baru harus diberitahukan ke peer dengan suatu cara
      Beberapa aplikasi yang memakai Iroh menyimpan kunci secara permanen, sementara yang lain membuatnya baru setiap sesi
      Jika kunci privat bocor, penyerang bisa menyamar sebagai saya saat memulai atau menerima koneksi. Jika saya kehilangan kuncinya, saya tidak akan bisa membuktikan identitas saya ke peer. Menurut pemahaman saya, risikonya mirip dengan saat kata sandi biasa atau kunci privat hilang atau dicuri

  • Alternatif serupa apa saja yang ada? Host Identity Protocol? https://mkomu.kapsi.fi/hipl/index.php?index=how

  • Saya sedang mencoba memahami proyek ini, tetapi perbedaan antara kunci dan IP masih belum terasa jelas. Pada akhirnya bukankah pada suatu titik kunci itu dipetakan ke alamat IP agar bisa memakai routing IP?
    Apakah kunci itu semacam pengenal yang bertahan lama yang dilekatkan pada alamat IP, sebagai pengganti URL atau DNS?

    • Ya, “kunci” memang menggantikan URL/DNS, tetapi tidak ditetapkan ke IP tertentu. Iroh melakukan P2P hole punching dan relay, dan kunci dipublikasikan ke server relay Iroh. Bisa juga dioperasikan sendiri
      Saat Anda mencoba menghubungkan satu node ke node lain dengan kunci, sistem akan mencari kunci itu di salah satu server relay, lalu mencoba berbagai cara mulai dari koneksi IP langsung, hole punching, hingga pada akhirnya koneksi relay melalui server relay
      Selain itu, kunci juga dipakai untuk enkripsi ujung-ke-ujung melalui QUIC

  • Apakah ada cara untuk meng-host server relay sendiri untuk aplikasi tertentu? Sepertinya ada. Hanya saja, agak terasa aneh karena ada halaman harga khusus relay dedicated

    • Dari kode yang Anda tautkan, saya melihat bahwa self-hosting memang dimungkinkan terpisah dari relay terkelola berbayar
    • Benar, Anda bisa menjalankan server relay sendiri, dan kode yang Anda tautkan memang yang tepat. Misalnya DeltaChat menjalankannya sebagai bagian dari relay chatmail. Ada juga yang menanamkan relay ke dalam web server yang sudah ada
      Relay ter-host disediakan untuk memberi hal yang sama tanpa repot mengelola server sendiri, sekaligus memberi visibilitas lebih besar ke jaringan

  • Rasanya ini lebih dekat ke Reticulum daripada ke Yggdrasil atau Netbird

  • Sulit memahami ini sebenarnya apa. Saya jadi teringat Yggdrasil, tetapi saya tidak begitu paham bagaimana keduanya dibandingkan