Tangled - แพลตฟอร์มความร่วมมือ Git บนพื้นฐาน atproto

 (blog.tangled.org)
3 คะแนน โดย GN⁺ 2025-10-12 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Tangled คือ แพลตฟอร์มความร่วมมือ Git ที่มีฟีเจอร์โซเชียล บนพื้นฐานของ AT Protocol ซึ่งออกแบบมาให้ผู้พัฒนายังคงมีสิทธิ์ความเป็นเจ้าของโค้ดอย่างสมบูรณ์ ขณะเดียวกันก็ทำให้ชุมชนโอเพนซอร์สสามารถ บริหารจัดการกันเองได้อย่างอิสระ
  • ใช้ โครงสร้างความร่วมมือด้านโค้ดแบบกระจายศูนย์ ที่ผสานข้อดีของโมเดลแบบ federated ที่เน้น ActivityPub(Forgejo) และโมเดล P2P เต็มรูปแบบของ Radicle
  • แนวคิดหลักอย่าง ‘Knot’ คือเซิร์ฟเวอร์ Git แบบ headless ที่มีน้ำหนักเบา รองรับทั้ง self-hosting ส่วนบุคคล และ สภาพแวดล้อมแบบ multi-tenant ในระดับชุมชน
  • App View(tangled.sh) มอบมุมมองรวมของรีโพซิทอรีทั่วทั้งเครือข่าย ทำให้สามารถ สำรวจ·โคลน·ร่วมพัฒนา รีโพซิทอรีที่อยู่บน Knot ต่างกันได้อย่างราบรื่น
  • ขณะนี้ยังอยู่ในช่วงเบตา โดยยึด ความเป็นเจ้าของข้อมูล·อุปสรรคในการเริ่มต้นที่ต่ำ·การรักษาประสบการณ์ผู้ใช้ เป็นหลักการสำคัญ และมุ่งสร้าง ระบบนิเวศ Git แบบกระจายศูนย์ที่เปิดอย่างสมบูรณ์ ในอนาคต

ภาพรวมของ Tangled

  • Tangled เป็นแพลตฟอร์มใหม่ที่มอบ สภาพแวดล้อมความร่วมมือ Git ที่มีปฏิสัมพันธ์ทางสังคม โดยผู้พัฒนายังคงมีสิทธิ์ความเป็นเจ้าของทั้งโค้ดและตัวตนของตนเอง
  • พัฒนาบนพื้นฐานของ AT Protocol และนำสถาปัตยกรรมแอปโซเชียลแบบกระจายศูนย์มาปรับใช้กับความร่วมมือบน Git
  • เป้าหมายคือทำให้การร่วมพัฒนาโค้ดกลับมาเป็น กระบวนการที่เปิดกว้างและสนุกอีกครั้ง

โมเดลแบบกระจายศูนย์และ AT Protocol

  • โมเดลความร่วมมือด้านโค้ดแบบกระจายศูนย์ที่มีอยู่เดิมมีแนวทางดังนี้
    • Forgejo(ActivityPub): ความร่วมมือผ่าน federation ระหว่างเซิร์ฟเวอร์
    • Radicle: โครงสร้าง P2P(peer-to-peer) แบบสมบูรณ์
  • Tangled ผสานข้อดีของทั้งสองโมเดล และเลือกใช้ atproto ที่รองรับการจัดการตัวตนแบบศูนย์กลางได้
  • ด้วยเหตุนี้ ผู้ใช้จึงสามารถรักษา ID และโครงสร้างการยืนยันตัวตนที่สอดคล้องกัน ได้แม้อยู่ในเครือข่ายแบบกระจายศูนย์

โครงสร้าง Knot

  • Knot เป็นองค์ประกอบหลักของ Tangled เป็นเซิร์ฟเวอร์น้ำหนักเบาที่ช่วยให้ผู้ใช้สามารถ โฮสต์ Git repository ได้ด้วยตนเอง
    • รองรับทั้ง การตั้งค่าแบบ single-tenant และ multi-tenant
    • สามารถ self-host บนอุปกรณ์ขนาดเล็กอย่าง Raspberry Pi ได้
  • โดยพื้นฐานแล้ว Tangled มี บริการ Knot แบบ managed ฟรี ให้ใช้งาน
  • ด้วยโครงสร้างนี้ จึงก่อให้เกิด เครือข่าย Git แบบกระจายศูนย์ ที่เชื่อมต่อกันอย่างเป็นธรรมชาติระหว่างเซิร์ฟเวอร์ส่วนบุคคลกับเซิร์ฟเวอร์ชุมชน

App View และเครือข่ายแบบบูรณาการ

  • App View ที่ให้บริการบน tangled.sh ทำหน้าที่แสดงรีโพซิทอรีทั้งเครือข่ายในรูปแบบ มุมมองรวม เดียว
  • ผู้ใช้สามารถ โคลน(clone) และ มีส่วนร่วม(contribute) กับรีโพซิทอรีที่อยู่บน Knot อื่นได้อย่างง่ายดาย
  • การออกแบบนี้ช่วย ขจัดอุปสรรคของสภาพแวดล้อมแบบกระจายศูนย์ ขณะเดียวกันก็ยังคงเวิร์กโฟลว์เดิมของ Git เอาไว้ครบถ้วน

หลักการพัฒนา

  • ทีม Tangled ได้กำหนด หลักการ 3 ข้อ สำหรับทิศทางการพัฒนา ดังนี้
    • 1. ความเป็นเจ้าของข้อมูล — ผู้ใช้ทุกคนเป็นเจ้าของโค้ดและเมตาดาต้าที่ตนสร้างขึ้นโดยตรง
    • 2. อุปสรรคในการเริ่มต้นต่ำ — มอบโครงสร้างและอินเทอร์เฟซที่เรียบง่ายเพื่อให้ทุกคนเข้าร่วมได้ง่าย
    • 3. ความสม่ำเสมอของประสบการณ์ผู้ใช้ — แม้จะเป็นโครงสร้างแบบกระจายศูนย์ แต่ยังคงรับประกัน UX ในระดับบริการแบบรวมศูนย์
  • หลักการเหล่านี้สะท้อนอยู่ในการเลือกเทคโนโลยีและการออกแบบ UI/UX ของ Tangled โดยรวม

การเข้าถึงและชุมชน

  • ในช่วงแรกให้บริการแบบ invite-only และนักพัฒนาสามารถเข้าร่วมผ่านช่อง IRC #tangled บน libera.chat
  • ปัจจุบันเปิด ล็อกอินสาธารณะ แล้ว และทุกคนสามารถใช้งานได้ที่ tangled.sh/login
  • แม้ Tangled จะยังอยู่ในระยะเริ่มต้น แต่ก็เติบโตไปพร้อมกับการตรวจสอบฟีเจอร์ผ่านการใช้งานจริงภายในทีม (dogfooding)

บทสรุป

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

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

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

 
lamanus 2025-10-12

ไม่มีคอนเทนเนอร์อย่างเป็นทางการ เลยทำให้การตั้งค่าเริ่มต้นค่อนข้างยุ่งยากนิดหน่อยครับ
 
GN⁺ 2025-10-12
ความคิดเห็นจาก Hacker News
  • ในฐานะผู้ร่วมก่อตั้งของ Tangled ช่วงนี้เราเพิ่งเปลี่ยนไลบรารี OAuth แล้วเกิดปัญหาที่ผู้ใช้ใหม่ไม่ถูกเพิ่มเข้าไปใน knot และ spindle เริ่มต้น (เซิร์ฟเวอร์โฮสต์ git ภายในและ CI runner) ตอนนี้เพิ่งลงแพตช์แก้ไขแล้ว ดังนั้นหากออกจากระบบแล้วเข้าสู่ระบบใหม่ ก็จะสามารถสร้างรีโพซิทอรีได้ตามปกติ หากมีคำถามยินดีตอบเสมอ
    • คำถามแรกคือบน PDS ของ tngl.sh สามารถเปลี่ยน handle หรือลบบัญชีได้หรือไม่ ส่วนคำถามที่สองคืออยากรู้ว่าต้องใช้ทรัพยากรอะไรบ้างในการสร้างและดูแล AppView ใหม่ เช่น ถ้าสร้าง AppView บน PDS ที่อัปโหลดโฟลเดอร์เว็บไซต์แบบ static แล้วให้บริการตรง ๆ แบบ Cloudflare Pages ผู้ดูแล AppView จะต้องแบกรับค่าใช้จ่ายทราฟฟิกจำนวนมากทั้งหมดหรือไม่ อยากรู้ว่าภาระในการดูแลระบบแบบนี้เป็นอย่างไร
    • Tangled ใช้คำว่า “social-enabled” ซึ่งดูเหมือนจะเกี่ยวข้องกับ AT Protocol อยากรู้ว่าในอนาคต Tangled มีแผนจะเพิ่มฟีเจอร์โซเชียลที่หลากหลายกว่านี้หรือไม่ หรือแค่อยากสื่อว่ารองรับ AT Protocol เท่านั้น
  • คิดว่าโปรเจกต์นี้ยอดเยี่ยมมาก ชอบความพยายามที่จะรื้อโครงสร้างผูกขาดของบริการ code forge แบบเดิม ๆ เหตุผลที่ผมสนใจเรื่องนี้ก็เพราะรู้สึกว่า code forge พยายามแก้หลายปัญหาพร้อมกันจนกลับไม่มีประสิทธิภาพ ส่วนใหญ่ forge จะรวมทั้ง git repository, web viewer, เครื่องมือคอลแลบอเรชัน, CI/CD pipeline, การจัดการงาน และอื่น ๆ ไว้ในที่เดียว แต่ผมคิดว่าฟีเจอร์เหล่านี้ไม่ได้จำเป็นต้องถูกรวมกันเสมอไป เช่น ถ้าไม่จำเป็นต้องเข้าถึง git repository โดยตรง ก็สามารถมี web viewer แบบ static ล้วนอย่าง https://pgit.pico.sh ได้ หรือเรื่องการคอลแลบอเรชันก็อาจมีเซิร์ฟเวอร์แยกไว้สำหรับแบ่ง patch เพื่อตรวจรีวิวและจัดการแบบโลคัล (https://pr.pico.sh) ก็ได้ แค่เอา bare git repository ไปวางบน VPS ก็เพียงพอแล้ว และเป็นเรื่องที่ทำได้ง่ายมาก Git เองก็เป็นระบบแบบกระจายอยู่แล้ว การกลับไปสู่ความรวมศูนย์เพราะบริการเสริมอื่น ๆ จึงดูเป็น anti-pattern
    • คนชอบพูดกันบ่อยว่า “Git กระจายศูนย์อยู่แล้ว” แต่จริง ๆ แล้วแนวคิดเรื่องความกระจายนั้นก็ยังคลุมเครืออยู่บ้าง Git เองไม่ได้โฟกัสที่การกระจายเท่าไรนัก แต่โดยมากทำงานบนโปรโตคอลแบบ master-slave (เช่น HTTP) จึงมีแนวโน้มที่จะวนกลับไปสู่ความรวมศูนย์อยู่ดี
    • ถ้ามีหลายบริการ ก็จะเกิดปัญหาเรื่องความน่าเชื่อถือขึ้น ต้องคิดว่าจะตรวจสอบบริการเดียวที่ตอบโจทย์ได้ 80% หรือจะไปตรวจสอบบริการแยกกัน 10 ตัว นอกจากนี้ยังมองข้ามข้อได้เปรียบจากขนาดของโครงสร้างพื้นฐานและประโยชน์จากการรวมหลายฟังก์ชันเข้าด้วยกันไม่ได้ จึงยังมีคนจำนวนมากที่ชอบระบบ monolithic อยู่ และสุดท้ายก็ต้องชั่งน้ำหนักกับ trade-off ด้านประสบการณ์นักพัฒนา
    • การตั้งค่า git remote บน VPS นั้นง่ายมาก แค่เข้าผ่าน ssh ก็ใช้งานได้ทันที จริง ๆ แล้วประเด็นหลักคือเรื่อง 'lock-in' มากกว่า ทำไม Github และบริการคล้ายกันจึงโฟกัสที่ lock-in มากกว่าการให้บริการเอง? เบื้องหลังคือเรื่องการระดมทุนและโมเดลธุรกิจ วงจร รวมศูนย์ → lock-in → รายได้ ปรากฏซ้ำแล้วซ้ำเล่าในหลายบริการ ถ้าไม่มีโครงสร้างที่ทำรายได้จากตัวบริการโดยตรง ก็รู้สึกว่าเลี่ยงปรากฏการณ์นี้ได้ยาก
    • ในเชิงเทคนิคไม่ใช่ว่าจะแยกฟังก์ชันออกจากกันไม่ได้ แต่ก็มีปัญหาเรื่องความคุ้มค่าทางเศรษฐกิจ (แต่ละฟังก์ชันอาจไม่สร้างรายได้พอให้ดูแลแยกกันได้) และการใช้งาน (ผู้คนต้องการความสะดวกแบบ 'มีมาให้ครบ') เช่นเดียวกับโอเพนซอร์สที่หลายกรณีมักมองข้ามเรื่องเศรษฐศาสตร์ แต่สุดท้ายส่วนใหญ่ก็หายไปเมื่อผู้ดูแลเพียงคนเดียวเลิกทำ แม้แต่โปรเจกต์โอเพนซอร์สที่ประสบความสำเร็จที่สุดก็ส่วนมากมีโครงสร้างที่ได้รับการสนับสนุนจากสปอนเซอร์องค์กรหรือวิศวกร
    • ไม่ได้แปลว่าต้องแยกออกจากกัน แต่การรวมไว้ด้วยกันก็สะดวกกว่ามากจริง ๆ
  • เพิ่งทราบข่าวการรองรับ Jujutsu จากงาน JJ Con โดยดูรายละเอียดได้ที่ https://blog.tangled.org/stacking
    • บริการนี้รองรับ stacked PR จริง ๆ ซึ่ง Github ทำไม่ได้มาหลายสิบปีแล้ว ถ้าจะใช้ภายในองค์กรแบบ private อย่างเดียว ยังน่าเสียดายที่ยังไม่ชัดเจนว่าจะตั้งค่า Tangled instance อย่างไรไม่ให้เชื่อมต่อกับเครือข่ายภายนอก
  • ผมคิดว่า Github ไม่น่าเชื่อถืออีกต่อไปแล้ว อย่างน้อยการย้าย OSS stack ไปอยู่บน AT Protocol หรือโอเพนเน็ตเวิร์กอื่น ๆ น่าจะเป็นวิธีที่ดีในการป้องกันความเสี่ยงจากบริษัทยักษ์ใหญ่ การเซ็นเซอร์ และปัจจัยคล้ายกัน จึงยินดีที่ได้เห็นความพยายามแบบนี้
    • แต่คนส่วนใหญ่ไม่อยากดูแลเซิร์ฟเวอร์เอง น่าจะมีแค่องค์กร OSS ขนาดใหญ่เท่านั้นที่พอรับภาระได้ และนอกจากอีเมลแล้ว แม้แต่การให้บริการ PR ก็ยังทำได้ยาก
  • ผมเป็นหนึ่งใน 100 คนแรกที่สมัครใช้ tangled ความเร็วในการพัฒนาฟีเจอร์และโรดแมปสำหรับ PR review แบบ stacked patch น่าประทับใจมาก และก็รับรู้ถึงพลังบวกจากคอมมูนิตี้ด้วย รอติดตามมากว่าจะพัฒนาไปอย่างไรต่อ ถ้ายังเดินหน้าแบบนี้ต่อเนื่อง ก็น่าจะได้ทั้งประสบการณ์ที่ดีกว่า การควบคุมที่เป็นรากฐานกว่า และความยั่งยืนระยะยาวด้วย
  • ผมสนใจแนวทางคอลแลบอเรชัน git ที่กระจายมากขึ้นมาก อยากรู้ว่ามองว่าอุปสรรคที่ใหญ่ที่สุดต่อการแพร่หลายของแนวทางนี้คืออะไร เป็นเรื่องการดูแลเซิร์ฟเวอร์ การจัดการ private key หรือสุดท้ายแล้วเป็นเรื่อง network effect กันแน่
    • อุปสรรคใหญ่ที่สุดคือปัญหาสแปม เนื้อหาผิดกฎหมาย และปัญหา moderation โดยรวม ประสบการณ์ความเชื่อถือพังทลายเกิดขึ้นบ่อย เพราะ PDS สามารถเป็นโดเมนอะไรก็ได้ และ PDS หนึ่งตัวก็รองรับผู้ใช้ได้ไม่จำกัด ถ้ามีคนอัปโหลด ebook หรือรายการทีวีจำนวนมากลงใน git repo จะทำอย่างไร หรือถ้าโปรเจกต์หนึ่งโดนโจมตีด้วยสแปมเพราะประเด็นทางการเมือง ก็ต้องคิดหาวิธีแก้ ข้อดีของแนวคิด AppView คือสามารถมีทีม moderation ส่วนกลางแบบเดียวกับ BlueSky ที่ใช้นโยบายอย่างสม่ำเสมอได้ แต่ละคนจะอัปโหลดอะไรก็ได้ก็จริง แต่สุดท้ายฝั่งฟรอนต์เอนด์ยังสามารถคัดสรรการแสดงผลได้แบบเลือกสรร อย่างไรก็ตาม การตัดสินใจ moderation แบบรวมศูนย์ก็เป็นประเด็นถกเถียงเสมอ นี่จึงเป็นเหตุผลที่ไม่อยากรับภาระและความรับผิดชอบของเครือข่ายแบบกระจายอย่างเต็มรูปแบบ แม้ความเปิดของ AT Protocol จะเป็นข้อได้เปรียบเมื่อเทียบกับบริการอย่าง Twitter แต่ในอีกด้านก็ยังต้องมีระบบที่รวมศูนย์สำหรับการจัดการประจำวันและการมอบอำนาจอยู่ดี ส่วนตัวก็สงสัยว่าตอนนี้จะมีใครอาสาเป็นผู้ดูแล radicle seed node แบบ “ใจกว้าง” (อนุญาตให้อัปโหลด git แบบไม่ระบุตัวตน) หรือไม่
    • Github ฟรี แต่การกระจายศูนย์มีต้นทุน
    • พอใจมากที่ Tangled ทำให้ใช้งาน git อย่างอิสระได้โดยไม่ต้องดูแลเซิร์ฟเวอร์เอง ข้อเสียใหญ่ที่สุดคือมันยังใหม่เกินไป ยังไม่มีการรับรู้ในวงกว้าง และหลายคนก็ยังไม่รู้ว่า Bsky กับ PDS ให้อะไรได้บ้าง อยากให้มีฟีเจอร์เพิ่มขึ้นและมี alternate client มากขึ้น ถึงอย่างนั้นผมก็คิดว่าผู้ใช้กลุ่มแรกเริ่มก็ได้รับประสบการณ์ที่ดีมากแล้ว และกำลังรอวันที่นักพัฒนามากกว่านี้จะได้สัมผัสประสบการณ์แบบนี้
  • ดีใจที่มีการรองรับ CI pipeline แต่ก็แอบเสียดายที่หน้าตาดูคล้าย GitHub Actions มากเกินไป ผมไม่คิดว่าจำเป็นต้องใช้ YAML สำหรับการรันแบบลำดับง่าย ๆ เพราะใช้ bash script ก็พอแล้ว มองว่า YAML ของ pipeline จะมีความหมายเมื่อใช้แสดง dependency (DAG) มากกว่าจะใช้บอก flow ของโปรแกรม ซึ่ง Buildkite ทำเรื่องนี้ได้ดีกว่ามาก
  • พรุ่งนี้คงจะมีแพลตฟอร์มธุรกิจ no-code ชื่อ “Spaghetti” และบริการตู้นิรภัยเก็บข้อมูลสำคัญชื่อ “Lock-in” ออกมาต่อแน่ ๆ
  • ที่บริษัทจำเป็นต้องใช้ GitHub public org อย่างหลีกเลี่ยงไม่ได้ อยากรู้ว่าสามารถทำ code review (CR) บน tangled แล้วค่อยซิงก์ไป Github ทีหลังได้หรือไม่ และจะยังคงประสบการณ์รีวิวผ่านเครื่องมือ jj ไว้ได้หรือเปล่า
  • อยากรู้ว่าสามารถนำ Tangled ไปใช้ในงานระดับ enterprise/private ได้หรือไม่ เพราะ flow การรีวิว stacked diff ดูเข้ากับงานในองค์กรมาก
    • มีความเป็นไปได้ และกำลังคุยกันเรื่อง Tangled เวอร์ชันที่ airgapped ได้เต็มรูปแบบและแยกจาก AT แต่เป็นงานค่อนข้างใหญ่ เลยคงยังทำไม่ได้ในเร็ว ๆ นี้
    • ตอนนี้ยังไม่มีโซลูชันสำหรับองค์กรที่ชัดเจนโดยเฉพาะ สามารถดูประเด็นที่คุยกันได้ที่ https://tangled.org/@tangled.org/core/issues/60