Iroh 1.0 - เชื่อมต่อด้วยคีย์แทน IP - ไลบรารีเครือข่ายสำหรับเชื่อมต่ออุปกรณ์ตามต้องการ

 (iroh.computer)
1 คะแนน โดย GN⁺ 4 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Iroh 1.0 คือรุ่นเสถียรตัวแรก และรับประกันเสถียรภาพของ wire protocol และภาษา API ทำให้ endpoint ของ iroh v1 สื่อสารกันได้โดยไม่ขึ้นกับ minor version หรือภาษา
  • นอกจาก Rust crate แล้ว ยังรองรับ Python, Node.js, Swift, Kotlin อย่างเป็นทางการ และสามารถฝัง iroh ลงในแอปพลิเคชัน Swift บน iOS และแอป Kotlin บน Android ได้
  • การเปลี่ยนแปลงที่กระทบต่อ wire stability จะเกิดขึ้นพร้อมกับ major release เสมอ และในอนาคต เวอร์ชันของภาษา API กับความเข้ากันได้ของ wire อาจถูกจัดการเวอร์ชันแยกจากกัน
  • หลัง 1.0 เป็นต้นไป major และ minor version จะได้รับการสนับสนุนตามกำหนดการสนับสนุน และ minor version 0.35 จะไม่มีรีลีสเพิ่มเติม
  • การรองรับ Public relay จะดำเนินต่อไปจนถึง End of Life สำหรับ v1.0, จนถึงวันที่ 31 ธันวาคม 2026 สำหรับ v0.35x และจนถึงวันที่ 30 กันยายน 2026 สำหรับ v0.9x และ v1.0.0-rcX
  • โดยปกติ public relay จะอัปเกรดเป็นเวอร์ชันล่าสุดภายใน 24 ชั่วโมงหลังแต่ละรีลีส และการเปลี่ยนแปลง relay ที่ทำให้ wire ไม่เข้ากันจะใช้ URL ใหม่เพื่อให้ไคลเอนต์เดิมยังทำงานต่อได้
  • ความสามารถด้านการเชื่อมต่อประกอบด้วย QUIC multipath, QUIC NAT traversal, การตั้งค่าแบบ local-first, การรันบน WASM และเบราว์เซอร์, hook สำหรับควบคุมการเชื่อมต่อ และการรองรับ custom transport
  • โดยทั่วไป ข้อมูล 95% ในการเชื่อมต่อจะถูกส่งตรงระหว่างอุปกรณ์ และอธิบายว่าการเชื่อมต่อโดยตรงช่วยลด hop ที่ต้องผ่านคลาวด์และลดค่า egress ได้ {p:95}
  • relayed traffic บน public relay มีการจำกัดอัตรา และข้อจำกัดนี้อาจเปลี่ยนแปลงได้ทุกเมื่อ

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
GN⁺ 3 시간 전
ความคิดเห็นบน Hacker News

  • ถ้าเพิ่งเคยเห็น Iroh เป็นครั้งแรก ก็พอจะเข้าใจได้ว่าเป็น Tailscale ในชั้นแอปพลิเคชัน ไม่ใช่ชั้นเครือข่าย
    คำถามว่า “งั้นใช้ Tailscale ไปเลยไม่ได้เหรอ?” ถ้ามองจากมุมของนักพัฒนาแอปจะต่างกันอยู่ ถ้าอยากให้แต่ละอินสแตนซ์ของแอปเชื่อมต่อกันได้ง่าย ในทางทฤษฎีก็ฝังความสามารถของ Tailscale เข้าไปในแอปได้ แต่แบบนั้นผู้ใช้ก็ต้องมีบัญชี Tailscale และตัวแอปก็จะผูกติดกับ Tailscale ไปด้วย
    Iroh ทำให้ฝังความสามารถนี้เข้าไปได้โดยตรง และยังมี public fallback relay ให้ด้วย ถ้าแอปโตจนเกินกว่าที่ relay สาธารณะจะรองรับได้ การสลับไปใช้ relay ของตัวเองก็แทบจะเหมือนกดสวิตช์เดียว

    • อ่านคำอธิบายนี้แล้วถึงเข้าใจว่า Iroh ทำอะไรได้ชัดกว่าวิดีโอเสียอีก ตอนนี้สิ่งที่สงสัยคือ Iroh ทำสิ่งนี้อย่างไร
    • ตอนนี้เข้าใจคุณค่าที่มันเสนอแล้ว อธิบายได้ดีกว่าหน้า landing page มาก ถึงขั้นน่าจะฝากให้เขียนข้อความการตลาดได้เลย
    • คำตอบหนึ่งของ “ทำไมไม่ใช้ Tailscale” ก็คือ Tailscale เป็นบริษัทที่ต้องการทำกำไร และการที่เรายังคงรวม เทคโนโลยีแบบกระจายศูนย์ไว้กับเจ้าของศูนย์กลางเพียงไม่กี่ราย ก็เป็นเรื่องไม่ฉลาด
      โดยเฉพาะถ้า Iroh ทำให้การทำสิ่งที่ถูกต้องเป็นเรื่องง่ายและดีได้ขนาดนี้ก็ยิ่งใช่
    • ใช่เลย เหมือนเคยคิดว่า “เราจะ bundle Tailscale มากับแอปของเราได้ไหม?” แล้วสุดท้ายก็มาเจอ Iroh
      ในสภาพแวดล้อมที่ผู้ใช้จำเป็นต้องเข้าถึงอินสแตนซ์บนเครื่องตัวเอง Iroh อาจเป็น game changer ได้เลย สำหรับเรา มันใช้เพื่อทำให้ควบคุมซอฟต์แวร์จากมือถือหรืออุปกรณ์อื่นได้ง่าย
      เมื่อก่อนอาจต้องตรวจว่าอยู่ใน LAN เดียวกันหรือไม่ แต่ถ้าใช้ Iroh มันทำงานได้ในทุกสภาพแวดล้อม
    • สิ่งที่ใกล้เคียงที่สุดคือ OpenZiti
      ทั้ง Iroh และ OpenZiti ฝังเข้าแอปได้ และทั้งคู่ก็เป็น use case ที่ดีสำหรับนักพัฒนาแอปที่อยากฝังไว้ในบริการ
      OpenZiti ใช้กับบริการที่ขนาดระบบและความปลอดภัยสำคัญ ส่วน Iroh ช่วยให้ผู้เข้าร่วมที่ไม่มีความสัมพันธ์กันมาก่อนก็เข้าร่วมได้ จึงอาจสะดวกมาก

  • ผมเป็นหนึ่งในนักพัฒนา Iroh
    คำถามที่เจอบ่อยคือ Iroh จะรองรับ WebRTC, BLE, LoRa และอื่น ๆ เมื่อไร
    ตอนนี้ Iroh รองรับแค่ IPv4, IPv6 และ relay transport เป็นค่าเริ่มต้น มี transport ที่น่าสนใจอยู่เยอะมาก ถ้าพยายามรองรับทั้งหมด codebase จะกลายเป็นเขาวงกตของ feature flag ที่บำรุงรักษาไม่ได้
    เลยเลือกทำให้สามารถเขียน custom transport ได้แทน และ implementation ของ transport สามารถแยกไปอยู่ใน crate คนละตัวได้ทั้งหมด
    custom transport เชิงทดลองที่มีอยู่แล้วได้แก่ Tor, Nym และ BLE: https://github.com/mcginty/iroh-ble-transport
    ดูวิธีทำงานภายในได้ที่นี่: https://www.iroh.computer/blog/iroh-0-97-0-custom-transports...

    • ดูเอกสารอยู่แล้วรู้สึกว่าเป็นโปรเจกต์ที่เจ๋งมาก และยังเจอตัวอย่าง แชต P2P ด้วย
      ถ้าสร้างโครงแบบไคลเอนต์/เซิร์ฟเวอร์ P2P หรือทำ peer machine สองตัวด้วยสิ่งนี้ ก็สงสัยว่ามีข้อจำกัดอะไรบ้างในแง่ที่ต้องตั้งค่าเพิ่มเติมเพื่อให้สองแอปเชื่อมต่อกัน
      เช่น ถ้าทำแอปที่รันบนมือถือกับแอปที่รันบนโน้ตบุ๊ก จะได้การเชื่อมต่อที่ตรงและปลอดภัยระหว่างกันจริงหรือไม่ หรือมันกำลังแก้ปัญหาอีกแบบหนึ่งอยู่
      -[0]: p2p chat, in rust, from scratch: https://www.youtube.com/watch?v=ogN_mBkWu7o
    • จากมุมของคนที่เคยสร้างอะไรด้วย libp2p มาเยอะ อยากเห็นการเปรียบเทียบแบบอัปเดตในมุมนักพัฒนาแอป
      ปีที่แล้วตอนต้องเลือกหนึ่งในสอง ผมเลือกตัวที่คุ้นเคยกว่า แต่ตอนนี้รู้สึกว่า ฝั่ง Iroh มีแรงส่งที่ชัดเจนกว่า
    • ถ้าจะรัน public relay ความเสี่ยงมีอะไรบ้าง อยากรู้ว่าในเชิงแนวคิดมันคล้ายกับการรัน Tor Guard Node หรือ relay หรือเปล่า
    • Tor transport อยู่ที่ https://github.com/n0-computer/iroh-tor-transport
      ตรงนี้ใช้ Tor daemon อยู่ Tor มี implementation ภาษา Rust และถ้าใช้จาก Rust ก็สามารถใช้งานในรูปแบบคล้าย stream object ได้
      ดูตัวอย่างการใช้งานได้ที่ https://gitlab.torproject.org/tpo/core/oniux
    • ถ้ากังวลว่าจะบำรุงรักษาไม่ได้ อาจลองพิจารณา feature flag API
      strategy pattern กับการจัดการฟีเจอร์แบบรวมศูนย์ก็ดี

  • ไม่แน่ใจว่าในวิดีโอมีพูดถึง “Dial keys” หรือเปล่า แต่ผมคิดว่าย่อหน้าแรกควรทำให้ชัดว่าเป็นคีย์ประเภทไหนและทำไมถึงจำเป็น
    ว่าเป็นคีย์เข้ารหัสลับหรือไม่ เป็นคีย์แบบอสมมาตรหรือเปล่า หรืออย่างน้อยก็ควรอธิบายว่ามันทำงานอย่างไรในระดับพื้นฐานที่สุด ตอนนี้กลับกระโดดไปพูดถึงข้ออ้างเชิงนามธรรมเรื่องความเหนือกว่าและสถิติการใช้งานทันที
    ดูเหมือนว่ารีเลย์จะมีส่วนเกี่ยวข้อง ซึ่งก็ควรบอกมาตั้งแต่แรก ไม่ใช่ปล่อยให้คนไปขุดหาเอาเองจากกระทู้ HN

    • หน้าแรกไม่ได้ลงลึกมาก แต่เอกสารอธิบายค่อนข้างเร็ว
      เริ่มจาก https://docs.iroh.computer/what-is-iroh แล้วก็มีส่วนอธิบายวิธีการทำงานต่อ จากที่ดูจนถึงตอนนี้ เอกสารถือว่าทำได้ดี และคำถามที่โผล่มาก็ดูจะมีคำตอบค่อนข้างไว
    • ดูวิดีโอแล้วก็ยังไม่รู้ว่ามันคืออะไรอยู่ดี อีกอย่างพูดว่า “ไม่ผูกติดอย่างเด็ดขาด” แต่กลับมี “pricing” และก็บอกว่ารีเลย์โฮสต์เองได้ งั้นทำไมต้องจ่ายเงินให้ “apps” ด้วยก็ยังไม่เข้าใจ
    • คำอธิบายว่า “Dial keys. Not IPs.” สำหรับผมฟังดูเหมือนการทำ DNS ขึ้นมาใหม่
      มันอาจจะกระจายศูนย์ อาจฟรี และอาจไม่เป็นเอกเทศ แต่ถ้ามองกว้าง ๆ ก็ยังอยู่ในหมวดเดียวกัน
    • ตอนแรกที่อ่านคำว่า “keys” ผมนึกว่าเป็น “ชื่อ” สำหรับเข้าถึงด้วยคีย์ เหมือน named host ใน .ssh/config
      แต่พอฟังต่อกลับเหมือนเป็นวิธีทำเครือข่ายแบบใหม่บน QUIC
    • หลังจากพยายามทำความเข้าใจอยู่พักหนึ่ง ดูเหมือนว่าคีย์พวกนี้มีบทบาทสองอย่าง คือเป็นทั้งคีย์เข้ารหัสและตัวระบุที่เสถียรคล้าย session cookie ที่ใช้กับวิดีโอคอลแบบ WebRTC ได้
      สรุปแบบ Lobste.rs จากคนที่ไม่ใช่ผู้เชี่ยวชาญและเพิ่งเห็นโปรเจกต์นี้วันนี้คือ: มันใกล้เคียงกับชุดตั้งค่า WebRTC แบบมีความเห็นชัดเจนที่กำหนด persistent ID ให้ไคลเอนต์ งานสร้าง signaling server ถูกจัดการไว้แล้ว และแนวทางแก้ปัญหาก็ดูทั่วไปพอและราคาถูกพอจนใช้เซิร์ฟเวอร์ที่ชุมชนโฮสต์ก็ได้ คล้าย ๆ กับสิ่งที่ได้จากโครงสร้างพื้นฐาน P2P gamenetworkingsocket แบบผูกขาดของ Steam อยู่บ้าง
      https://lobste.rs/s/cslljn/iroh_1_0_dial_keys_not_ips#c_s3na...

  • ผมไม่เข้าใจตั้งแต่แรกว่ามันกำลังพยายามแก้ปัญหาอะไรอยู่ IP กับ DNS ก็ทำงานได้ดีอยู่แล้ว
    เรามีทั้งIPv6 และ QUICอยู่แล้ว และถ้าจะให้เกิดแรงดึงดูดที่มีความหมายในพื้นที่นี้ ก็ต้องมีทั้งผู้ขายและซอฟต์แวร์หลักเข้าร่วม

    • Iroh ก็คือ QUIC มันไม่ได้พยายามประดิษฐ์วงล้อขึ้นใหม่ แต่กำลังนำ RFC ของ IETF ที่มีอยู่มาประกอบกันอย่างสร้างสรรค์
      เอาแบบเป็นรูปธรรม สมมติว่ามีอุปกรณ์หนึ่งอยู่หลัง NAT ของ WLAN ที่บ้าน และอีกอุปกรณ์หนึ่งอยู่บนเครือข่าย 4G หรืออยู่หลัง NAT คนละตัวในบริษัท
      ในหลายกรณี hole punching สามารถสร้างการเชื่อมต่อโดยตรงระหว่างอุปกรณ์ทั้งสองได้อย่างรวดเร็วมาก ทำให้ได้ทั้งแบนด์วิดท์สูงสุดและ latency ต่ำสุดเท่าที่เป็นไปได้
      ปัญหานี้ยังไม่ใช่ปัญหาที่ถูกแก้ไปแล้วจนจบ
    • ผมไม่ได้เกี่ยวอะไรกับ Iroh และก็ไม่ได้ใช้อยู่ แต่คำพูดว่า “IP ทำงานได้ดี” นี่ฟังไม่ขึ้นเลย นี่ไม่ใช่ปัญหาที่แก้เสร็จแล้ว
    • ในทางกลับกัน การตั้งการเชื่อมต่อโดยตรงนั้นเป็นปัญหาที่ยากกว่ามากภายใต้โครงสร้างพื้นฐานอินเทอร์เน็ตปัจจุบัน
    • จากที่ผมมอง Iroh เหมือนกำลังพยายามสร้างsession layerที่หายไปในโมเดล OSI Cisco ก็มีความพยายามคล้ายกันในชื่อ Location-Identity Separation Protocol
      เพราะใน TCP/IP ไม่มี session layer ที่แท้จริง vMotion จึงมักทำได้แค่ภายใน broadcast domain เดียว ในสถานการณ์นั้นการระบุตำแหน่งจริง ๆ ใช้แค่ MAC address และแม้ MAC address จะเปลี่ยนหลัง vMotion ก็ยังใช้ IP เป็นตัวระบุที่เสถียรได้ การแมปถูกจัดการโดยตาราง MAC address ของสวิตช์
    • DNS ไม่ได้กระจายศูนย์เสียทีเดียว แต่ใกล้เคียงกับแบบสหพันธรัฐมากกว่า อย่างน้อยเท่าที่ผมดูครั้งล่าสุด Iroh ก็มีตัวเลือกให้ใช้ DHT ได้ตรงนี้

  • อนาคตของเครือข่ายคือการกระจายศูนย์ ผมชอบ Yggdrasil กับ I2P มาก
    เราควรซื้อ mini PC สักเครื่องมารัน 24 ชั่วโมงเพื่อโฮสต์สิ่งที่ต้องการ แล้วเชื่อมต่อกับคนอื่นได้อย่างลื่นไหล คนสายเทคนิคหลายคนก็มีเครื่องสำรองเก่า ๆ ที่ตอนนี้ได้แต่นอนกินฝุ่นอยู่แล้ว และเอามาทำเป็นเซิร์ฟเวอร์ได้
    ในระยะยาวมันถูกกว่าและดูแลง่ายกว่าการต้องจัดการโดเมนกับโฮสติ้งเซิร์ฟเวอร์มาก ผมชื่นชมงานของทีม Iroh อย่างจริงใจ

    • นั่นก็เป็นอนาคตมาอย่างน้อย 20 ปีแล้ว

  • Iroh ใช้งานด้วยแล้วดีมากจริง ๆ และวิศวกรในช่อง Discord ก็เป็นมิตรมาก
    แนวทางเชิงปฏิบัติที่ทำให้ P2P ใช้งานได้จริงนั้นเข้าใจง่าย และคอนเทนต์ในช่อง YouTube ก็ดีมากด้วย ยินดีกับการออก v1
    https://youtube.com/@n0computer

  • มันไม่แปลกเหรอที่โปรโตคอลที่พยายามทำหน้าที่คล้าย IP address กลับมีป้ายราคาติดอยู่ด้วย? หรือผมอาจกำลังเข้าใจอะไรผิดไป

    • อย่างที่คนอื่นบอกไปแล้ว ไลบรารีหลักและโปรโตคอลของ iroh เป็นโอเพนซอร์สทั้งหมด
      เพียงแต่เพื่อชดเชยต้นทุนการพัฒนา พวกเขาจึงมีบริการเสริมที่ช่วยให้การ deploy และการปฏิบัติการง่ายขึ้น โดยเฉพาะสำหรับกรณีใช้งานที่ใหญ่หรือเฉพาะทางมากขึ้น
    • นี่คืออาการแบบ Tailscale
      อยู่ในสภาพที่ “อยากเป็นโครงสร้างพื้นฐานสำหรับคนทั่วไป และเป็นธุรกิจสำหรับผู้เชี่ยวชาญ”
      ติดอยู่ระหว่าง “ต้องมีเงินถึงจะรันได้” กับ “อยากเป็นระบบโครงสร้างพื้นฐานสาธารณะ” และด้านลบของการเป็นบริษัทแสวงกำไรก็ถูกปัดด้วยคำว่า “แต่มันโอเพนซอร์สนะ”
      ถ้าคำว่า “โอเพนซอร์ส” ไม่ได้พ่วงมาพร้อม codebase ที่ปรับแต่งจนสุดทางและไม่มีใครเข้าใจ ผมคิดว่าแนวคิดธุรกิจแบบนี้ก็พอรับได้ในระดับหนึ่ง
    • ถ้าดูจากหน้า pricing เดียวกัน ทั้งหมดนั้นเป็นบริการเสริม observability, การโฮสต์รีเลย์, วิศวกรซัพพอร์ต อะไรทำนองนั้น
    • ถ้าจะเทียบสิ่งที่พวกเขาให้กับ IP address มันใกล้เคียงกับการรัน BGP router หรือ ISP หรือการจ้างวิศวกรเครือข่ายสำหรับ data center networking มากกว่า
      การรัน ISP หรือ AS ต้องใช้เงินจำนวนมากอยู่แล้วแน่นอน
    • ดูเหมือนว่าพวกเขากำลังให้บริการ “โฮสติ้งและมอนิเตอร์แบบคัสตอมสำหรับแอป Iroh”

  • บริษัทผมใช้ Iroh ในโปรดักชันอยู่ และชอบมากจริง ๆ
    ถ้าจะอธิบายแบบสั้น ๆ ผมคงเรียกมันว่า hole punching สไตล์ Tailscale ที่มาในรูป Rust crate แต่แน่นอนว่าคุณยังต่อยอดฟีเจอร์ P2P เจ๋ง ๆ ได้อีกมากบนการเชื่อมต่อ QUIC พื้นฐาน

  • บริษัทเรานำ Iroh ไปใช้กับระบบฝึกแมชชีนเลิร์นนิงแบบกระจายในโปรดักชัน และพอใจมาก
    แม้ก่อนจะมีสัญญาซัพพอร์ตระดับองค์กร ทีมงานก็ตอบสนองได้เร็วอย่างเหลือเชื่อ มีความรู้ลึกมาก และตัวไลบรารีเองก็ทำงานได้ดีอย่างน่าทึ่ง ถ้าให้เลือกอีกครั้ง ผมก็จะใช้ไลบรารีนี้แทน libp2p ทุกเมื่อ

  • ยินดีด้วยกับการเปิดตัว
    จำเป็นอย่างเร่งด่วนที่จะต้องมีหน้า versus สำหรับเปรียบเทียบกับ tailscale/netbird/netmaker/zerotier/twingate/openziti
    ถ้าดูจากกรณีการใช้งานอย่างเดียว ตอนนี้ยังมองไม่เห็นว่าอะไรที่ทำไม่ได้ด้วย Tailscale
 
GN⁺ 4 시간 전
ความคิดเห็นจาก Lobste.rs

  • ดูเหมือนว่าทั้งที่นี่และบน HN หลายคนจะสับสนว่า Iroh ต่างจากเมชเน็ตเวิร์กที่ครอบอยู่บน VPN (เช่น Tailscale, ZeroTier, Netbird ฯลฯ) อย่างไร เท่าที่ผมเข้าใจ Iroh มีไว้สำหรับนักพัฒนาแอปที่อยากให้เครื่องที่รันแอปของตัวเองสื่อสารกันแบบ P2P ส่วนเมชเน็ตเวิร์กมีไว้สำหรับผู้ดูแลเครือข่ายที่ต้องการเชื่อมต่ออุปกรณ์ที่ตนเป็นเจ้าของหรือดูแลเข้าหากัน
    ยกตัวอย่างว่าถ้าจะทำแอปส่งข้อความแบบ P2P ผู้ใช้ฝั่งหนึ่งอาจเป็นอุปกรณ์พกพาที่สลับไปมาระหว่าง WiFi กับข้อมูลมือถืออยู่ตลอด จึงไม่มีแอดเดรสที่เสถียร ส่วนอีกฝั่งอาจเป็นโน้ตบุ๊กที่อยู่หลัง NAT และ CGNAT
    ถ้าต้องการให้ทั้งสองเครื่องสื่อสารกันได้แม้ IP address จะเปลี่ยนไป ก็จำเป็นต้องมีกลไกมาจัดการเรื่องนี้
    ในอดีตมักเป็นวิธีที่ทั้งสองเอนด์พอยต์เชื่อมต่อเข้าหา เซิร์ฟเวอร์ตัวกลาง ที่นักพัฒนาแอปเป็นผู้ดูแล แล้วแชร์สถานะกัน แต่ Iroh ดูจะใกล้เคียงกับการทำให้สิ่งนี้เป็นมาตรฐานและให้บริการมันในรูปแบบเซอร์วิสมากกว่า

    • ถ้าเข้าใจไม่ผิด มันดูใกล้เคียงกับ WebRTC แบบมีแนวทางชัดเจน ที่ผูก ID แบบถาวรให้กับไคลเอนต์มากกว่า หมายถึงมันช่วยจัดการงานที่ปกติต้องไปสร้าง signaling server เอง และมีโครงสร้างที่ใช้งานได้กว้างพอและต้นทุนต่ำพอจนใช้เซิร์ฟเวอร์ที่ชุมชนโฮสต์ให้ก็ได้
      คล้ายเล็กน้อยกับสิ่งที่ได้จากโครงสร้างพื้นฐาน P2P gamenetworkingsocket แบบปิดของ Steam
    • เข้าใจอยู่ว่าเขาวางตลาดเป้าหมายไว้แบบไหน แต่พอดูตารางราคาแล้วมันสเกลตาม จำนวนผู้ใช้พร้อมกัน และเพดานของ tier ทั่วไปอยู่ที่ 5,000 คน รู้สึกว่านี่ค่อนข้างต่ำหรือเปล่า

  • อาจมีอะไรที่ผมพลาดไป แต่การเอาทุกอย่างไปผูกไว้กับ คีย์เดียว ดูเสี่ยงมาก อยากรู้ว่าถ้าคีย์นั้นหายหรือถูกขโมยจะเกิดอะไรขึ้น
    ผมลองค้นหา “key rotation” แบบเร็ว ๆ ในเอกสารของ Iroh แต่หาไม่เจอ

    • คีย์เหล่านั้นเป็น public key ใน Iroh มันทำหน้าที่แทน IP address ซึ่งก็เป็นข้อมูลสาธารณะเช่นกัน ในฐานะวิธีสำหรับเข้าถึงโหนดอื่น
    • นักพัฒนาต้องเป็นคนตัดสินใจเองว่าจะเก็บหรือหมุนคีย์อย่างไร คีย์ในที่นี้คือ คู่คีย์ Ed25519 และเพราะ public key ถูกใช้เป็นตัวตน หากจะหมุนคีย์ก็ต้องแจ้ง public key ใหม่ให้เพียร์รับรู้ไม่ทางใดก็ทางหนึ่ง
      บางแอปที่ใช้ Iroh เก็บคีย์แบบถาวร ขณะที่บางแอปสร้างใหม่ทุกเซสชัน
      ถ้า private key รั่ว ผู้โจมตีสามารถปลอมเป็นผมได้เวลาจะเริ่มหรือรับการเชื่อมต่อ ถ้าคีย์หาย ผมก็จะไม่สามารถพิสูจน์ตัวตนของตัวเองต่อเพียร์ได้ เท่าที่ผมเข้าใจ ความเสี่ยงก็คล้ายกับกรณีที่รหัสผ่านหรือ private key ทั่วไปสูญหายหรือถูกขโมย

  • แล้วมีทางเลือกอื่นที่คล้ายกันไหม? Host Identity Protocol? https://mkomu.kapsi.fi/hipl/index.php?index=how

  • ผมกำลังพยายามทำความเข้าใจโปรเจกต์นี้ แต่ยังไม่ค่อยเห็นภาพ ความต่างระหว่างคีย์กับ IP สุดท้ายแล้วในจุดใดจุดหนึ่งคีย์ก็ต้องถูกแมปเป็น IP address เพื่อใช้ IP routing ไม่ใช่หรือ?
    คีย์เป็นเหมือนตัวระบุที่อยู่ได้นานและครอบอยู่บน IP address เพื่อมาแทน URL หรือ DNS หรือเปล่า?

    • ใช่ “คีย์” มาแทน URL/DNS แต่ไม่ได้ถูกกำหนดให้กับ IP ใด IP หนึ่ง Iroh ทำทั้ง P2P hole punching และรีเลย์ โดยคีย์จะถูกประกาศไว้บนรีเลย์เซิร์ฟเวอร์ของ Iroh ซึ่งคุณก็รันเองได้
      เมื่อพยายามเชื่อมต่อโหนดหนึ่งไปยังอีกโหนดด้วยคีย์ มันจะไปค้นหาคีย์นั้นจากรีเลย์เซิร์ฟเวอร์ตัวใดตัวหนึ่ง แล้วลองหลายวิธีตั้งแต่เชื่อมต่อ IP โดยตรง, hole punching ไปจนถึงการเชื่อมต่อผ่านรีเลย์เซิร์ฟเวอร์ในท้ายที่สุด
      นอกจากนี้คีย์ยังใช้สำหรับ การเข้ารหัสแบบต้นทางถึงปลายทาง ผ่าน QUIC ด้วย

  • มีวิธีโฮสต์ รีเลย์เซิร์ฟเวอร์ เองสำหรับแอปเฉพาะทางไหม? ดูเหมือนจะทำได้ แต่พอเห็นว่ามีหน้า pricing สำหรับรีเลย์โดยเฉพาะก็รู้สึกแปลกนิดหน่อย

    • ผมมองว่าแค่โค้ดในลิงก์นั้นก็เพียงพอให้ self-host ได้ แยกจากรีเลย์แบบ managed ที่ต้องจ่ายเงิน
    • ใช่ คุณสามารถรันรีเลย์เซิร์ฟเวอร์เองได้ และโค้ดที่ลิงก์มาก็ใช่เลย ตัวอย่างเช่น DeltaChat รันมันเป็นส่วนหนึ่งของ chatmail relay และบางคนก็ฝังรีเลย์ไว้ในเว็บเซิร์ฟเวอร์เดิมของตัวเอง
      รีเลย์แบบโฮสต์ให้มีเป้าหมายเพื่อมอบสิ่งนี้โดยไม่ต้องยุ่งยากกับการดูแลเซิร์ฟเวอร์เอง และเพื่อให้มองเห็นภาพของเครือข่ายได้มากขึ้น

  • อันนี้ให้ความรู้สึกว่าใกล้กับ Reticulum มากกว่า Yggdrasil หรือ Netbird

  • เข้าใจยากว่ามันคืออะไร ทำให้นึกถึง Yggdrasil แต่ก็ยังไม่แน่ใจว่าทั้งสองอย่างเทียบกันอย่างไร