Radicle: โค้ดฟอร์จแบบอัตโนมัติ

 (radicle.xyz)
1 คะแนน โดย GN⁺ 2026-01-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Radicle คือ เครือข่ายความร่วมมือเขียนโค้ดโอเพนซอร์สแบบกระจายศูนย์ ที่สร้างบน Git โดยสามารถโคลนและจัดการรีโพซิทอรีกันได้โดยตรงระหว่างเพื่อนร่วมงานโดยไม่ต้องมีเซิร์ฟเวอร์กลาง
  • ข้อมูลทั้งหมดและ โซเชียลอาร์ติแฟกต์ ถูกลงลายเซ็นด้วยการเข้ารหัสกุญแจสาธารณะ ทำให้ ตรวจสอบความแท้จริงและผู้เขียน ได้
  • ผู้ใช้สามารถรันโหนดของตนเองเพื่อรักษา สภาพแวดล้อมการทำงานร่วมกันที่ทนต่อการเซ็นเซอร์ และทำงานแบบ local-first ได้แม้ไม่มีการเชื่อมต่ออินเทอร์เน็ต
  • ผ่าน Collaborative Objects (COBs) ฟีเจอร์การทำงานร่วมกัน เช่น issue, การสนทนา และ code review ถูกทำให้เป็นอ็อบเจ็กต์ของ Git และนักพัฒนาสามารถขยายฟังก์ชันได้อย่างอิสระ
  • มีโครงสร้างแบบ โมดูลาร์ ทั้ง CLI, เว็บ และ TUI ทำให้เป็น แพลตฟอร์มโค้ดฟอร์จที่ขยายได้สูง ซึ่งรองรับการพัฒนาและสลับใช้ไคลเอนต์ได้หลากหลาย

ภาพรวม (Synopsis)

  • Radicle คือ สแตกความร่วมมือเขียนโค้ดแบบเพียร์ทูเพียร์บน Git ซึ่งต่างจากแพลตฟอร์มโฮสต์โค้ดแบบรวมศูนย์ตรงที่ไม่มีผู้ควบคุมเพียงรายเดียว
    • รีโพซิทอรีถูกจำลองแบบแบบกระจายระหว่างเพียร์ และผู้ใช้ควบคุมข้อมูลและเวิร์กโฟลว์ของตนได้อย่างเต็มที่
  • เปิดให้ใช้งานเป็นโอเพนซอร์ส และใช้งานได้อย่างอิสระภายใต้ ไลเซนส์ MIT และ Apache 2.0
  • รีโพซิทอรีหลักมีตัวระบุเป็น rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5

การติดตั้งและเริ่มต้นใช้งาน

  • สามารถติดตั้งได้จากเชลล์ด้วยคำสั่งต่อไปนี้:
    curl -sSLf https://radicle.xyz/install | sh
  • หรือคอมไพล์ได้โดยตรงจากซอร์สโค้ด
  • ปัจจุบันรองรับเฉพาะ Linux, macOS และตระกูล BSD
  • ยังมีไคลเอนต์ Radicle Desktop สำหรับสภาพแวดล้อมการทำงานร่วมกันแบบกราฟิก

วิธีการทำงาน (How it works)

  • ใช้ ระบบอัตลักษณ์เชิงเข้ารหัส เพื่อรับประกันความสมบูรณ์ของโค้ดและข้อมูลโซเชียล รวมถึงการยืนยันตัวผู้เขียน
  • ใช้ Git เพื่อถ่ายโอนข้อมูลระหว่างเพียร์อย่างมีประสิทธิภาพ
  • แลกเปลี่ยนเมทาดาทาของรีโพซิทอรีผ่าน โปรโตคอลกอสซิปแบบกำหนดเอง

ความปลอดภัยและความคงทนของข้อมูล

  • โซเชียลอาร์ติแฟกต์ทั้งหมดถูกเก็บไว้ใน Git และ ลงลายเซ็นด้วยการเข้ารหัสกุญแจสาธารณะ
  • Radicle ตรวจสอบ ความแท้จริงของข้อมูลและตัวตนของผู้เขียน โดยอัตโนมัติ

ความเป็นอิสระและความทนต่อการเซ็นเซอร์

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

Local-first

  • มอบความสามารถที่ เข้าถึงได้ตลอดเวลา แม้ไม่มีการเชื่อมต่ออินเทอร์เน็ต
  • ผู้ใช้เป็นเจ้าของข้อมูลของตนเอง และสามารถ ย้าย สำรอง และเข้าถึง ได้ง่าย

ความสามารถในการขยายและการพัฒนาต่อ

  • ผ่าน Collaborative Objects (COBs) ฟีเจอร์อย่าง issue, การสนทนา และ code review ถูกทำให้เป็นอ็อบเจ็กต์ของ Git
  • นักพัฒนาสามารถขยาย COBs เพื่อสร้าง เวิร์กโฟลว์การทำงานร่วมกันรูปแบบใหม่ ได้

การออกแบบแบบโมดูลาร์ (Modular by Design)

  • Radicle Stack ประกอบด้วย CLI, เว็บอินเทอร์เฟซ และ TUI
    • ทั้งหมดนี้ได้รับการรองรับโดย Radicle Node และ HTTP Daemon
  • แต่ละองค์ประกอบสามารถสลับเปลี่ยนได้ และยังสามารถพัฒนา ไคลเอนต์อื่น ๆ ได้ด้วย

ชุมชนและการมีส่วนร่วม

  • Radicle เป็น ซอฟต์แวร์เสรีและโอเพนซอร์ส ที่ทุกคนสามารถร่วมเขียนโค้ดได้
  • ชุมชนเคลื่อนไหวอยู่บน Zulip, Mastodon, Bluesky และ Twitter เป็นต้น
  • สามารถส่งฟีดแบ็กไปที่ feedback@radicle.xyz และข้อความจะถูกโพสต์ไปยังช่อง #feedback บน Zulip โดยอัตโนมัติ

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

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

 
GN⁺ 2026-01-25
ความคิดเห็นจาก Hacker News

  • รู้สึกว่าข้อความแนะนำของ Radicle ยังไม่ชัดเจนว่าแตกต่างจาก Git แบบ self-hosted อย่างไร
    ถ้าเป็นทางเลือกแบบ gitea หรือ forgejo ก็น่าจะดีถ้าอธิบายสั้น ๆ ว่าเพิ่มความสามารถอะไรบน Git บ้าง

    • หลังจากอ่านคำแนะนำแล้ว รู้สึกว่ามันคล้าย local-first Git สำหรับทีม
      เข้าใจว่าเป็นเครื่องมือสำหรับทำงานร่วมกันโดยไม่ต้องเจอกับความวุ่นวายของการแชร์แพตช์ผ่านอีเมล
      ไม่รู้จัก gitea หรือ forgejo อยู่แล้ว เลยรู้สึกว่าการเปรียบเทียบไม่ได้ช่วยมากนัก
    • คิดว่าสรุปเดิมก็ดีพออยู่แล้ว
      การระบุ Git ในประโยคแรกทำให้ชัดเจนดี
      ในทางกลับกัน หน้า landing page ของ forgejo กลับหลีกเลี่ยงการพูดถึง Git หรือ source control เลยยิ่งทำให้งง
    • Radicle คือ ทางเลือกแบบกระจายศูนย์ของ GitHub
      มันมีความสามารถสำหรับโฮสต์บนเครื่องตัวเองเหมือน forgejo/gitea/gitlab แต่ทำงานบน เครือข่าย P2P จึงทนต่อความขัดข้องได้ดีกว่า และทำให้โฮสต์โปรเจ็กต์สาธารณะแบบไร้ศูนย์กลางได้
    • AD: เราเป็นโปรเจ็กต์โอเพนซอร์ส เลยยินดีรับข้อเสนอหรือแพตช์เสมอ
      ถ้ามีข้อเสนอโดยตรงว่าเขียนแบบไหนจะดีกว่า ก็ดีมากเลย
    • จากที่ดูหน้าเว็บ รู้สึกว่ามันเหมือน GitHub แบบกระจายศูนย์ ที่ทำให้ทีมทำงานร่วมกันได้โดยที่บริษัทไม่ต้องเข้าถึงโค้ด

  • ดีใจที่มีความพยายามสร้าง social forge (Forge) ตัวใหม่
    แค่โปรเจ็กต์แบบนี้สร้างแรงกดดันให้ GitHub และ GitLab ต้องปรับปรุงก็นับว่ามีความหมายแล้ว
    ดูจาก FAQ แล้ว Radicle พยายามแก้ปัญหาเรื่องความน่าเชื่อถือใน Git ด้วย ระบบตัวตนบน PKI
    แต่ก็ยังรู้สึกว่าปัญหาว่า “จะเชื่อถือใคร” นั้นยังคงอยู่

    • AD: แต่ละ repository ถูกจัดการด้วย เอกสารตัวตนที่มีลายเซ็นของ delegate
      ตอนนี้ยังแมปแบบ 1:1 กับ SSH key แต่กำลังขยายไปสู่ตัวตนแบบกลุ่ม
      มันไม่ใช่คำตอบที่สมบูรณ์แบบ แต่ด้วย ตัวตนเชิงคริปโตกราฟี เราสามารถสร้างโครงสร้างที่ ‘ขยายจากความไว้วางใจของบางส่วนไปสู่มากขึ้น’ ได้
      ท้ายที่สุดแล้ว ความไว้วางใจก็ถูกกระจายผ่าน ความเชื่อมโยงทางสังคม เหมือนความสัมพันธ์ระหว่างผู้คน
    • ความไว้วางใจต้องเกิดจากช่องทางอื่นหรือจาก code review
      พอมีความไว้วางใจแล้ว ก็สามารถไปดู repository อื่น ๆ ที่มี DID เดียวกันได้
      ถ้ามีหลายเวอร์ชัน ก็เลือกจาก แหล่งที่เชื่อถือได้ หรือ repository ที่มีความเคลื่อนไหวมากก็พอ

  • พอได้คลุกคลีกับกลุ่ม sysadmin ขนาดเล็กที่ชอบรันบริการอินเทอร์เน็ตเก่า ๆ อย่าง IRC หรือ Gopher ก็เลยคิดถึงปัญหา การลบไม่ได้ของระบบ P2P
    ถ้าเผลออัปโหลดข้อมูลส่วนตัว หรืออัปโหลดเนื้อหาที่ภายหลังกลายเป็นปัญหาเพราะกฎหมายเปลี่ยน จะทำอย่างไรดี
    มีกรณีเสี่ยงอย่าง การจับกุมนักวิทยุสมัครเล่นในเบลารุส ด้วย
    ไม่ได้หมายความว่า P2P ไม่ดี แต่ปัญหาเรื่อง การลบข้อมูล ก็ยังแก้ยากอยู่ดี

    • โพสต์เก่า ๆ ใน Usenet ส่วนใหญ่ก็ยังคงอยู่มาจนถึงตอนนี้
      ต่อให้บน GitHub ถ้ามีการอัปโหลดโค้ดที่มี secret key เข้าไป บ่อยครั้งก็สายเกินไปแล้ว
      แทนที่ P2P จะสร้างปัญหาใหม่ มันเหมือนแค่เผยให้เห็นปัญหาเดิมอย่างตรงไปตรงมา
    • ต้องยอมรับความจริงว่าเนื้อหาที่เผยแพร่สู่สาธารณะนั้นแทบจะ ถาวร
      น่าจะดีถ้ามี ฟีเจอร์หน่วงเวลาการเผยแพร่ แบบที่ยังยกเลิกการส่งได้ภายในช่วงเวลาหนึ่งเหมือนอีเมล
    • AD: เรารับรู้ปัญหานี้อยู่ และกำลังทำให้ ค่าตั้งต้นปลอดภัยขึ้น
      ที่ระดับเครือข่ายก็มีการพูดคุยเรื่อง ฟีเจอร์ยกเลิก/ทิ้งคอนเทนต์ อยู่เช่นกัน
    • ระบบรวมศูนย์ก็ไม่ได้ปลอดภัยสมบูรณ์
      ผู้ดูแลอาจบิดเบือนการลบหรือรายงานให้รัฐบาลก็ได้
      ปัญหาทางกฎหมายสุดท้ายแล้วก็ขึ้นอยู่กับ ความเป็นธรรมของระบอบการเมือง
    • แม้แต่บริการแบบรวมศูนย์ ผู้คนก็ยังดาวน์โหลดคอนเทนต์เก็บไว้ได้ ดังนั้นการลบแบบสมบูรณ์จึงเป็นไปไม่ได้

  • มีคำถามว่ามันต่างจาก Tangled อย่างไร

    • Radicle ใช้ สถาปัตยกรรมแบบ local-first โดยให้ผู้ใช้รันโหนดของตัวเองโดยตรง
      งานทุกอย่าง เช่น issue หรือ patch review เกิดขึ้นใน data store ภายในเครื่อง และ ไม่มีการวิ่งกลับไปกลับมาหาเซิร์ฟเวอร์
      เครือข่ายจะเข้ามาเกี่ยวข้องเฉพาะตอนซิงก์เท่านั้น
      ส่วน Tangled เป็น โครงสร้างแบบสหพันธ์ที่อิง AT Protocol ซึ่งในทางปฏิบัติต้องพึ่งพาเซิร์ฟเวอร์รวมศูนย์ (AppView)
      ในเชิงโครงสร้างจึงเป็นแบบ client-server
    • Tangled ใช้ AT Protocol เป็นตัวกลางให้ Git server หลายตัว (‘knots’) สื่อสารกัน
      ส่วน Radicle ไม่มีแนวคิดเรื่องเซิร์ฟเวอร์ และทุกโหนดเท่าเทียมกัน
      เพียงแต่บางโหนดอาจทำงานเป็น HTTP server เพื่อช่วยให้เข้าผ่านเบราว์เซอร์ได้

  • จาก FAQ, Radicle บอกว่าสำหรับ การใช้งานในทางที่ผิดและคอนเทนต์ผิดกฎหมาย แต่ละโหนดสามารถบล็อกได้ตามนโยบายของตัวเอง
    และยังรองรับ repository แบบ private ระหว่าง peer ที่เชื่อถือกัน
    ข้อมูลไม่ได้ถูกเข้ารหัส แต่ด้วยการ replicate แบบเลือกได้ จึงไม่ได้ถูกเปิดเผยไปทั้งเครือข่าย
    ลิงก์ FAQ

  • รู้สึกว่าหน้าแรกควรมีเกตเวย์ที่เข้าถึง ดัชนีของ repository สาธารณะ ได้
    จะได้สำรวจทั้งเครือข่ายได้
    ถ้ามีดัชนีแบบนี้ ก็น่าจะมีศักยภาพแทนที่ GitHub ได้

    • สามารถค้นหา repository สาธารณะได้ที่ search.radicle.xyz
      แต่ไม่แน่ใจว่ามีลิงก์จากหน้าแรกไว้อย่างชัดเจนหรือเปล่า

  • Radicle เป็นโปรเจ็กต์ที่เจ๋งจริง ๆ
    รันโหนดมาได้หลายเดือนแล้ว แต่ยังไม่ได้ใช้เป็นตัวหลัก
    เชื่อว่า P2P forge คืออนาคตของเว็บ

    • AD: ขอบคุณที่เข้าร่วม และฉันเองก็รัน seed node แบบ permissive อยู่
      การเข้าร่วมเองก็ถือเป็นการโหวตแล้ว
    • AD: อยากรู้เหมือนกันว่าทำไมถึงยังไม่ใช้เป็นตัวหลัก

  • ทุกครั้งที่เห็นโปรเจ็กต์ถูกบล็อกบน GitHub ก็จะคิดว่า “น่าจะใช้ Radicle”
    ถ้ารัน โหนดหลัง Tor ก็อาจเลี่ยงแรงกดดันทางกฎหมายได้ด้วย

    • สงสัยว่าสามารถเปิดโหนดบนหลายเครือข่ายพร้อมกันได้ไหม เช่น Tor, i2p, clearnet, yggdrasil เป็นต้น
      เมื่อก่อนบางโปรเจ็กต์เคยมีปัญหากับการตั้งค่าแบบนี้

  • สงสัยว่า seeder แบบ permissive ป้องกันตัวเองจากการอัปโหลดไบนารีขนาดใหญ่ได้อย่างไร
    ถ้าทุก issue และทุกการสนทนาถูกเก็บไว้ ขนาด repository ก็อาจโตมากเกินไป
    ดูเหมือนว่าควรมีการ replicate แบบบางส่วนคล้าย shallow clone ของ Git

  • มีคำถามว่าต่างจาก Forgejo (โปรโตคอล ForgeFed) อย่างไร

    • Radicle เป็น โครงสร้าง P2P เต็มรูปแบบ ไม่มีแนวคิดเรื่องเซิร์ฟเวอร์หรืออินสแตนซ์
      ทุกโหนดทำงานด้วยโปรเซสเดียวกัน และบัญชีผู้ใช้เป็นแบบ self-certifying
      ขณะที่ Forgejo เป็น โครงสร้างแบบสหพันธ์ ที่ให้เซิร์ฟเวอร์สื่อสารกันผ่าน ActivityPub
      เปรียบได้ว่า GitHub : Forgejo = Twitter : Mastodon และ file sharing : BitTorrent = software development : Radicle
      Radicle จัดการ reference ด้วย namespace เชิงคริปโตกราฟีในระดับโปรเจ็กต์ ไม่ใช่เซิร์ฟเวอร์กลาง
      การควบคุมการเข้าถึงก็อิงกับ ตัวตนของผู้ใช้ ไม่ใช่เซิร์ฟเวอร์