Iroh 1.0 - IP नहीं, key से कनेक्ट करें - मनचाहे डिवाइस कनेक्शन के लिए networking लाइब्रेरी

 (iroh.computer)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Iroh 1.0 पहली स्थिर रिलीज़ है, और wire protocol तथा language API स्थिरता की गारंटी देती है, जिससे iroh v1 endpoint आपस में minor version या language की परवाह किए बिना संचार कर सकते हैं
  • Rust crate के अलावा Python, Node.js, Swift, Kotlin का आधिकारिक समर्थन है, और Swift iOS एप्लिकेशन तथा Kotlin Android ऐप्स में iroh को embed किया जा सकता है
  • wire स्थिरता को प्रभावित करने वाले बदलाव हमेशा major release के साथ होंगे, और आगे चलकर language API version तथा wire compatibility को स्वतंत्र रूप से version किया जा सकता है
  • 1.0 के बाद major और minor version को support schedule के अनुसार समर्थन मिलेगा, जबकि 0.35 minor version को अतिरिक्त रिलीज़ नहीं मिलेगी
  • Public relay समर्थन v1.0 के लिए End of Life तक, v0.35x के लिए 31 दिसंबर 2026 तक, और v0.9x तथा v1.0.0-rcX के लिए 30 सितंबर 2026 तक संचालित होगा
  • public relay आम तौर पर हर रिलीज़ के तुरंत बाद 24 घंटे के भीतर नवीनतम version पर अपडेट हो जाते हैं, और wire-breaking relay बदलावों में पुराने client चलते रहें इसके लिए नया URL इस्तेमाल किया जाता है
  • कनेक्टिविटी फीचर्स में QUIC multipath, QUIC NAT traversal, local-first configuration, WASM और browser execution, connection control hook, तथा custom transport support शामिल हैं
  • कनेक्शन में डेटा का 95% सीधे डिवाइसों के बीच ट्रांसफर होना सामान्य है, और विवरण के अनुसार direct connection cloud के जरिए होने वाले hop और egress लागत को कम करता है {p:95}
  • public relay के relayed traffic पर rate limit लागू है, और यह सीमा किसी भी समय बदली जा सकती है

संबंधित पढ़ाई

2 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • अगर आप पहली बार Iroh देख रहे हैं, तो मोटे तौर पर इसे network layer नहीं बल्कि application layer का Tailscale समझ सकते हैं
    “बस Tailscale ही क्यों न इस्तेमाल करें?” ऐप डेवलपर के नज़रिए से बात अलग है। अगर app instances को आपस में आसानी से connect कराना हो, तो सैद्धांतिक रूप से Tailscale की functionality को ऐप में embed किया जा सकता है, लेकिन तब user को Tailscale account चाहिए होगा और ऐप भी Tailscale पर निर्भर हो जाएगा
    Iroh आपको यह functionality सीधे embed करने देता है, और public fallback relay भी देता है। अगर ऐप इतना बड़ा हो जाए कि public relay संभालना मुश्किल हो, तो अपने relay पर switch करना लगभग एक switch flip करने जितना आसान है

    • यह व्याख्या पढ़कर ही मुझे वीडियो से ज़्यादा अच्छी तरह समझ आया कि Iroh क्या करता है. अब जिज्ञासा यह है कि Iroh इसे कैसे implement करता है
    • अब value proposition समझ में आ गया। आपने landing page से कहीं बेहतर समझाया है, इतना कि आपको marketing copy भी लिखनी चाहिए
    • “Tailscale क्यों नहीं?” इसका एक जवाब यह भी है कि Tailscale एक ऐसी कंपनी है जो पैसा कमाना चाहती है, और distributed technology को कुछ गिने-चुने central owners के हाथों में और सिमटने देना बेवकूफी है
      खासकर तब, जब Iroh ने सही तरीके से काम करना इतना आसान और शानदार बना दिया हो
    • बिल्कुल वही। शायद मैं “क्या हम अपने ऐप के साथ Tailscale ship कर सकते हैं?” यह सोचते-सोचते Iroh तक पहुँचा था
      जहाँ users को local instances तक पहुँच चाहिए, वहाँ Iroh game changer हो सकता है। हमारे लिए इसका उपयोग फ़ोन या दूसरे devices से software को आसानी से control करने में है
      पहले शायद यह देखना पड़ता कि वे एक ही LAN पर हैं या नहीं, लेकिन Iroh के साथ यह किसी भी environment में काम करता है
    • सबसे नज़दीकी तुलना OpenZiti से है
      Iroh और OpenZiti दोनों को ऐप में embed किया जा सकता है, और service में embedding करना चाहने वाले app developers के लिए दोनों अच्छे use case हैं
      OpenZiti उन services में इस्तेमाल होता है जहाँ scale और security महत्वपूर्ण हैं, जबकि Iroh ऐसे participants को भी साथ आने देता है जिनका पहले से कोई संबंध नहीं है, इसलिए यह बहुत सुविधाजनक हो सकता है

  • मैं Iroh के developers में से एक हूँ
    बार-बार पूछा जाने वाला सवाल है कि Iroh WebRTC, BLE, LoRa वगैरह को कब support करेगा
    अभी Iroh default रूप से सिर्फ IPv4, IPv6 और relay transport को support करता है। दिलचस्प transport तरीकों की संख्या इतनी ज़्यादा है कि अगर हम सबको support करने लगें, तो codebase feature flags की ऐसी भूलभुलैया बन जाएगा जिसे maintain करना असंभव होगा
    इसके बजाय हमने custom transports implement करने की सुविधा दी है, और transport implementation को पूरी तरह अलग crate में रखा जा सकता है
    मौजूदा experimental custom transports में Tor, Nym और BLE शामिल हैं। https://github.com/mcginty/iroh-ble-transport
    यह अंदर से कैसे काम करता है, यहाँ देखा जा सकता है: https://www.iroh.computer/blog/iroh-0-97-0-custom-transports...

    • docs देखते हुए यह काफ़ी बढ़िया project लगा, और मुझे P2P chat example भी मिला
      अगर इससे P2P client/server setup या दो peer machines बनाई जाएँ, तो मैं यह जानना चाहता हूँ कि दो applications के बीच connection के लिए अतिरिक्त रूप से क्या configure करना पड़ता है, और इसकी सीमाएँ क्या हैं
      उदाहरण के लिए, अगर मैं एक ऐप फ़ोन पर और दूसरी ऐप laptop पर चलाऊँ, तो क्या मुझे वास्तव में दोनों के बीच direct और secure connection मिल सकता है, या यह किसी और समस्या का समाधान कर रहा है?
      -[0]: p2p chat, in rust, from scratch: https://www.youtube.com/watch?v=ogN_mBkWu7o
    • मैंने पहले libp2p के आधार पर काफ़ी कुछ बनाया है, इसलिए app developers के नज़रिए से कोई updated comparison देखना चाहूँगा
      पिछले साल दोनों में से एक चुनते समय मैंने वही चुना जिससे मैं ज़्यादा परिचित था, लेकिन अब लगता है कि Iroh के पक्ष में साफ़ momentum है
    • मैं जानना चाहता हूँ कि public relay चलाने में क्या जोखिम हैं। अवधारणात्मक रूप से, क्या यह Tor Guard Node या relay चलाने जैसा है?
    • Tor transport https://github.com/n0-computer/iroh-tor-transport पर है
      यहाँ Tor daemon का उपयोग किया जा रहा है। Tor की एक Rust implementation है, और Rust में इसका इस्तेमाल stream object जैसी किसी चीज़ के रूप में किया जा सकता है
      उपयोग का उदाहरण https://gitlab.torproject.org/tpo/core/oniux में देखा जा सकता है
    • अगर maintainability की चिंता है, तो feature flag API पर विचार किया जा सकता है
      strategy pattern और centralized feature management अच्छे रहते हैं

  • मुझे नहीं पता कि वीडियो में “Dial keys” थे या नहीं, लेकिन मेरा मानना है कि पहले पैराग्राफ़ में साफ़ होना चाहिए कि ये किस तरह की keys हैं और इनकी ज़रूरत क्यों है
    क्या ये cryptographic keys हैं, क्या ये asymmetric keys हैं, कम-से-कम बुनियादी स्तर पर भी ये कैसे काम करती हैं इसका कोई explanation नहीं है। यह तुरंत abstract superiority claims और usage statistics पर चला जाता है
    लगता है relay इससे जुड़ा हुआ है, लेकिन लोगों को यह HN discussion में खोजने पर मजबूर करने के बजाय शुरू से ही बता देना बेहतर होगा

    • पहली page बहुत गहराई में नहीं जाती, लेकिन docs तुरंत समझा देते हैं
      पहले https://docs.iroh.computer/what-is-iroh है, और उसके बाद how it works section है। अभी तक देखने पर docs सचमुच ठीक लगते हैं, और उठे हुए सवालों के जवाब काफ़ी जल्दी दे देते हैं
    • वीडियो देखने के बाद भी मुझे अभी तक नहीं पता कि ये क्या हैं। और फिर “कभी lock-in नहीं” कहते हैं, लेकिन “pricing” भी है, और relay को self-hosted बताया जाता है, तो फिर “apps” के लिए पैसे क्यों देने हैं यह भी समझ नहीं आता
    • “Dial keys. Not IPs.” वाला explanation मुझे DNS के reimplementation जैसा लगता है
      यह distributed हो सकता है, free हो सकता है, monolith न भी हो सकता है, लेकिन बड़े तौर पर यह उसी category में आता है
    • जब मैंने “keys” पढ़ा, तो मैंने सोचा यह .ssh/config के named hosts जैसा कोई “name” होगा, जिसे key से access किया जाता है
      लेकिन और सुनने पर यह QUIC के ऊपर networking करने के एक नए तरीके जैसा लगा
    • कुछ देर समझने की कोशिश करने के बाद, मुझे लगता है कि ये keys दोहरी भूमिका निभाती हैं: encryption keys भी, और WebRTC video calls में इस्तेमाल होने वाले session cookie जैसे stable identifiers भी
      मैं expert नहीं हूँ और यह project आज ही पहली बार देखा है, इसे ध्यान में रखते हुए Lobste.rs summary यह है: यह client को persistent ID assign करने वाले, opinionated WebRTC setup के ज़्यादा क़रीब है। signaling server बनाने का काम इसमें पहले से handled है, और solution इतना generic और सस्ता है कि community-hosted servers भी इस्तेमाल किए जा सकते हैं। Steam की proprietary P2P gamenetworkingsocket infrastructure से जो मिलता है, उससे थोड़ा मिलता-जुलता है
      https://lobste.rs/s/cslljn/iroh_1_0_dial_keys_not_ips#c_s3na...

  • मुझे शुरुआत से ही समझ नहीं आता कि यह कौन-सी problem solve करना चाहता है। IP और DNS तो ठीक से काम करते हैं
    हमारे पास पहले से IPv6 और QUIC हैं, और इस क्षेत्र में meaningful traction पाने के लिए vendors और major software की ज़रूरत होगी

    • Iroh, QUIC ही है। यह wheel को फिर से invent करने की कोशिश नहीं कर रहा, बल्कि existing IETF RFCs को creative तरीके से जोड़ रहा है
      मान लीजिए एक device घर के WLAN के NAT के पीछे है, और दूसरा device 4G network या किसी कंपनी के दूसरे NAT के पीछे है
      ज़्यादातर मामलों में hole punching के ज़रिए दोनों devices के बीच बहुत तेज़ी से direct connection बनाया जा सकता है, और इससे highest possible bandwidth और lowest latency मिलती है
      यह समस्या अभी तक हल की हुई समस्या नहीं रही है
    • Iroh से मेरा कोई लेना-देना नहीं है और मैं इसे इस्तेमाल भी नहीं करता, लेकिन “IP ठीक से काम करता है” कहना बेमानी है। यह solved problem नहीं है
    • उल्टा, आज के internet infrastructure में direct connection establish करना कहीं ज़्यादा मुश्किल समस्या है
    • मेरी नज़र में Iroh, OSI model में missing session layer बनाने की कोशिश कर रहा है। Cisco का Location-Identity Separation Protocol भी कुछ ऐसा ही प्रयास है
      TCP/IP में असली session layer नहीं होने की वजह से vMotion आमतौर पर सिर्फ़ एक single broadcast domain के भीतर ही संभव होता है। इस स्थिति में addressing के लिए लगभग सिर्फ़ MAC address का इस्तेमाल होता है, और vMotion के बाद MAC address बदल जाए तब भी IP को stable identifier की तरह इस्तेमाल किया जा सकता है। mapping का काम switch की MAC address table संभालती है
    • DNS decentralization से ज़्यादा federated है। कम-से-कम मैंने पिछली बार जब देखा था, तब Iroh में यहाँ DHT इस्तेमाल करने का option था

  • networking का future decentralization है। मुझे Yggdrasil और I2P बहुत पसंद हैं
    आपको एक mini PC खरीदकर उसे 24/7 चलाना चाहिए, उस पर ज़रूरी चीज़ें host करनी चाहिए, और दूसरे लोगों से आसानी से connect कर पाना चाहिए। बहुत-से तकनीकी लोग पहले से ही पुराने spare machines रखते हैं जिन पर धूल जम रही होती है, और उन्हें server बनाया जा सकता है
    लंबे समय में यह domains और server hosting संभालने की तुलना में बहुत सस्ता होगा और maintenance भी आसान होगा। Iroh team के काम की मैं सच में सराहना करता हूँ

    • कम-से-कम 20 साल से यही future बताया जा रहा है

  • Iroh के साथ काम करना वाकई बहुत अच्छा था, और Discord channel के engineers भी बहुत मददगार थे
    P2P को बस काम करने लायक बना देने वाला practical approach समझना आसान था, और YouTube channel का content भी शानदार है। v1 release पर बधाई
    https://youtube.com/@n0computer

  • जो protocol IP address जैसी functionality देना चाहता है, उसके साथ price tag होना अजीब नहीं लगता? हो सकता है मैं कुछ ग़लत समझ रहा हूँ

    • जैसा कि दूसरे लोग पहले ही कह चुके हैं, iroh की core library और protocol पूरी तरह open source हैं
      लेकिन development cost निकालने के लिए, ख़ासकर बड़े या विशेष use cases में deployment और operation आसान बनाने वाली अतिरिक्त services दी जाती हैं
    • यह Tailscale syndrome है
      यानी “लोगों के लिए infrastructure बनना है, और experts के लिए business भी बनना है” वाली स्थिति
      यह “इसे चलाने के लिए पैसा चाहिए” और “हम public-good infrastructure system बनना चाहते हैं” के बीच फँसा हुआ है, और for-profit company के नकारात्मक पहलुओं को “लेकिन यह open source है” कहकर साइड में कर दिया जाता है
      जब तक “open source” का मतलब पूरी तरह custom और समझ से बाहर codebase न हो, मुझे लगता है ऐसा business concept कुछ हद तक ठीक है
    • उसी pricing page को देखें तो सब कुछ अतिरिक्त services ही हैं। observability, relay hosting, support engineers जैसी चीज़ें
    • अगर उनकी पेशकश की तुलना IP address से करनी हो, तो यह BGP router या ISP चलाने, या data center networking के लिए network engineers को contract पर रखने के ज़्यादा क़रीब है
      यह तो तय है कि ISP या AS चलाने में काफ़ी पैसा लगता है
    • लगता है वे “Iroh apps के लिए custom hosting और monitoring” दे रहे हैं

  • हमारी company production में Iroh इस्तेमाल कर रही है और हमें यह वाकई बहुत पसंद है
    मैं इसे मुख्य रूप से Rust crate के रूप में दिया गया Tailscale-जैसा hole punching कहूँगा, लेकिन बेशक base QUIC connection के ऊपर बहुत-सी बढ़िया P2P functionality भी जोड़ी जा सकती है

  • हमारी company ने production distributed machine learning training system में Iroh इस्तेमाल किया था, और हम इससे बहुत संतुष्ट थे
    enterprise support contract साइन करने से पहले ही team अविश्वसनीय रूप से तेज़ जवाब दे रही थी, उनका knowledge भी बहुत गहरा था, और library ख़ुद भी हैरान कर देने लायक अच्छी तरह काम कर रही थी। मैं libp2p की बजाय कभी भी फिर से यही library इस्तेमाल करूँगा

  • लॉन्च के लिए बधाई
    tailscale/netbird/netmaker/zerotier/twingate/openziti के साथ तुलना करने वाला versus पेज तुरंत चाहिए
    सिर्फ़ use case देखने पर अभी ऐसा कुछ नहीं दिखता जो Tailscale से नहीं किया जा सकता
 
GN⁺ 4 시간 전
Lobste.rs की राय

  • लगता है यहाँ और HN दोनों जगह लोग इस बात को लेकर भ्रमित हैं कि Iroh, VPN के ऊपर चलने वाले mesh network (Tailscale, ZeroTier, Netbird आदि) से कैसे अलग है। मेरी समझ में Iroh उन application developers के लिए है जो अपने app चलाने वाले devices के बीच P2P communication चाहते हैं, जबकि mesh network उन network admins के लिए हैं जो अपने स्वामित्व या प्रबंधन वाले उपकरणों को आपस में जोड़ना चाहते हैं
    उदाहरण के लिए, मान लें आप एक P2P messaging app बना रहे हैं। एक तरफ का user ऐसा mobile device इस्तेमाल कर सकता है जो लगातार WiFi और mobile data के बीच बदलता रहता है, इसलिए उसका कोई स्थिर address नहीं है, और दूसरी तरफ का user NAT और CGNAT के पीछे बैठा laptop इस्तेमाल कर सकता है। अगर IP address बदलने पर भी इन दोनों को communicate कराना है, तो इसके लिए कोई mechanism चाहिए
    पहले आमतौर पर app developer द्वारा चलाए जाने वाले intermediary server से दोनों endpoints को जोड़कर state share कराई जाती थी, लेकिन Iroh इसे standardize करके service के रूप में देने के ज्यादा करीब लगता है

    • अगर मेरी समझ सही है, तो यह लगातार रहने वाली ID को clients से जोड़ने वाले opinionated WebRTC setup के ज्यादा करीब दिखता है। यानी signaling server बनाने का काम यह आपके लिए संभाल लेता है, और यह इतना general-purpose और सस्ता है कि community-hosted server का इस्तेमाल भी किया जा सके
      यह कुछ हद तक Steam के proprietary P2P gamenetworkingsocket infrastructure से मिलने वाली चीज़ जैसा भी है
    • इसका target market क्या है, यह तो समझ आता है, लेकिन pricing देखकर लगता है कि यह concurrent users के आधार पर scale होता है और सामान्य tier की सीमा 5,000 users है। यह काफ़ी कम नहीं है क्या?

  • हो सकता है मैं कुछ मिस कर रहा हूँ, लेकिन सब कुछ एक ही key पर टिका देना बहुत जोखिम भरा लगता है। अगर वह key खो जाए या compromise हो जाए तो क्या होगा, यह जानना चाहता हूँ
    Iroh docs में “key rotation” जल्दी से खोजा, लेकिन कुछ नहीं मिला

    • वे keys public keys हैं। Iroh में उनका काम दूसरे nodes तक पहुँचने के तरीके के रूप में, यानी वैसे ही सार्वजनिक information वाले IP address की जगह लेना है
    • keys को कैसे store या rotate करना है, यह developer को तय करना होता है। यहाँ key का मतलब Ed25519 key pair है, और क्योंकि public key को identity की तरह इस्तेमाल किया जाता है, इसलिए अगर आप key rotate करते हैं तो नई public key किसी न किसी तरीके से peers तक पहुँचानी होगी
      Iroh इस्तेमाल करने वाले कुछ applications keys को स्थायी रूप से store करते हैं, और कुछ हर session के लिए नई key बनाते हैं
      अगर private key लीक हो जाए तो attacker connection शुरू करते समय या receive करते समय मेरी नकल कर सकता है। अगर key खो जाए तो मैं peers के सामने अपनी identity साबित नहीं कर पाऊँगा। मेरी समझ में यह वही तरह का जोखिम है जैसा सामान्य password या private key खोने या चोरी होने पर होता है

  • इसी तरह के alternatives क्या हो सकते हैं? Host Identity Protocol? https://mkomu.kapsi.fi/hipl/index.php?index=how

  • मैं project को समझने की कोशिश कर रहा हूँ, लेकिन key और IP का फ़र्क ठीक से समझ नहीं आ रहा। आख़िर किसी बिंदु पर IP routing इस्तेमाल करने के लिए key को IP address से map नहीं करना पड़ेगा?
    क्या key, IP address के साथ लंबे समय तक रहने वाला identifier जोड़ने का तरीका है, यानी URL या DNS का विकल्प?

    • हाँ, “key” URL/DNS की जगह लेती है, लेकिन इसे किसी खास IP पर assign नहीं किया जाता। Iroh P2P hole punching और relay करता है, और key को Iroh relay servers पर publish किया जाता है। आप इन्हें खुद भी चला सकते हैं
      जब आप किसी node को उसकी key से किसी दूसरे node से जोड़ने की कोशिश करते हैं, तो यह relay servers में से किसी एक पर उस key को lookup करता है, फिर direct IP connection से लेकर hole punching और अंत में relay server के ज़रिए relay connection तक कई तरीके आज़माता है
      इसके अलावा key का इस्तेमाल QUIC के जरिए end-to-end encryption में भी होता है

  • क्या किसी खास application के लिए अपना relay server host करने का कोई तरीका है? संभव तो लगता है। लेकिन dedicated relay pricing page होना थोड़ा अजीब लगता है

    • मेरे हिसाब से आपने जो code link किया है, उसी से paid managed relay से अलग self-hosting संभव होनी चाहिए
    • हाँ, आप अपना relay server चला सकते हैं, और आपने जो code link किया है वही सही है। उदाहरण के लिए DeltaChat इसे chatmail relay के हिस्से के रूप में चलाता है। कुछ लोग relay को मौजूदा web server के अंदर embed भी करते हैं
      hosted relay का मकसद यह सुविधा बिना अपने server को manage करने की झंझट के देना है, और network पर ज्यादा visibility भी देना है

  • यह Yggdrasil या Netbird से ज़्यादा Reticulum के करीब लगता है

  • यह क्या है, समझना मुश्किल है। Yggdrasil याद आता है, लेकिन दोनों की तुलना कैसे होगी, यह साफ़ नहीं है