ฟอร์จจำเป็นต้องมีการเฟเดอเรชัน

• การทำงานร่วมกันแบบโอเพนซอร์ส ตั้งอยู่บนมุมมองปัญหาว่า การผสานกันของโปรโตคอลแบบกระจายศูนย์ที่แยกหน้าที่การส่งโค้ดและการสื่อสารออกจากกัน เป็นแนวทางที่พึงประสงค์มากกว่าโครงสร้างที่พึ่งพาผู้ให้บริการรายเดียวอย่างหนัก
• เดิมทีการทำงานร่วมกันด้านโค้ดเกิดขึ้นจากการผสาน git กับอีเมล ต่อมาจึงย้ายไปเป็น git กับเว็บไซต์ GitHub และ ForgeFed ก็สานต่อด้วยการผสาน git กับ ActivityPub ส่วน Tangled กำลังต่อยอดด้วยการผสาน git กับ AT protocol
• Tangled ใช้โครงสร้างที่เฟเดอเรตเหตุการณ์ระหว่าง git server โดยเรียกแต่ละเซิร์ฟเวอร์ว่า knot และรองรับทั้งการทำงานร่วมกันบน repository แม้อยู่คนละเซิร์ฟเวอร์, fork ข้ามเซิร์ฟเวอร์, และ pull request ไปยัง repository ที่อยู่บนเซิร์ฟเวอร์อื่น
• สำหรับ Authenticated Transfer รอบตัวโค้ดนั้นใช้ AT โดยดูแลทั้ง issues, pull requests, event timeline, follows, stars และยังใช้สำหรับการเชิญผู้ร่วมพัฒนาและการแชร์ SSH public key
• แนวทางนี้คล้ายกับการรัน cgit instance เองแล้วส่งแพตช์ผ่านอีเมล แต่ก็แสดงทิศทางที่ต้องการรักษาความเป็นสังคมและความสนุกของการทำงานร่วมกัน พร้อมก้าวออกจาก GitHub monoculture

---

ความจำเป็นของการเฟเดอเรชันสำหรับฟอร์จ

• โครงสร้างที่พึ่งพาผู้ให้บริการรายเดียวสำหรับ การทำงานร่วมกันแบบโอเพนซอร์ส เป็นสัดส่วนมากนั้นไม่พึงประสงค์ และตั้งอยู่บนมุมมองว่า โปรโตคอลแบบกระจายศูนย์อยู่ได้นานกว่าระบบรวมศูนย์
• การทำงานร่วมกันด้านโค้ดใช้สองโปรโตคอลควบคู่กันมาเสมอ โดยตัวหนึ่งรับหน้าที่ การส่งโค้ด และอีกตัวรับหน้าที่ การสื่อสาร
  • ในช่วงแรกเป็นการผสานระหว่าง git กับอีเมล
  • ต่อมาจึงเปลี่ยนเป็นการผสานระหว่าง git กับเว็บไซต์ GitHub
  • ForgeFed เปิดความเป็นไปได้ของการผสานระหว่าง git กับ ActivityPub
  • Tangled กำลังสร้างขึ้นบนการผสานระหว่าง git กับ AT protocol
• Tangled ทำหน้าที่เฟเดอเรตเหตุการณ์ระหว่าง git server ต่าง ๆ และเรียกแต่ละเซิร์ฟเวอร์ว่า knot
  • ไม่ว่า repository จะอยู่บนเซิร์ฟเวอร์ใดก็ทำงานร่วมกันได้
  • รองรับ fork ข้ามเซิร์ฟเวอร์
  • หลังจาก push ไปยัง repository บนเซิร์ฟเวอร์ของตัวเองแล้ว ก็สามารถเปิด pull request ไปยัง repository ที่โฮสต์อยู่บนอีกเซิร์ฟเวอร์หนึ่งที่ต่างออกไปโดยสิ้นเชิงได้
• วิธีนี้คล้ายกับการรัน cgit instance เองและส่งแพตช์ผ่านอีเมลในหลายแง่มุม

บทบาทที่ Tangled รับผิดชอบ

• Tangled ใช้ AT สำหรับ Authenticated Transfer ของเหตุการณ์รอบตัวโค้ด
  • ใช้สำหรับการส่งต่อเหตุการณ์อย่าง issues และ pull requests
  • ดูแลฟีเจอร์เชิงสังคมอย่าง event timeline, follows และ stars ไปพร้อมกัน
  • vouches ก็มีกำหนดจะเพิ่มเข้ามาในเร็ว ๆ นี้
• AT ยังถูกใช้สำหรับการเชิญผู้ร่วมพัฒนาและการแชร์ SSH public key ส่วนอื่น ๆ นอกเหนือจากนั้นยังคงใช้ git แบบเดิม
• โอเพนซอร์สจำเป็นต้องก้าวออกจาก monoculture แบบ GitHub และในขณะเดียวกันก็ต้องรักษาความเป็นสังคมและความสนุกของการทำงานร่วมกันด้านโค้ดไว้
• tangled alpha
• docs
• source
• discord
• bluesky
• twitter (x)
• feed

[GN⁺]

ความคิดเห็นใน Hacker News

• ยังไม่ค่อยแน่ใจว่ามันจะดีกว่า Mastodon แค่ไหน

  • ATproto ไม่ได้เป็นโครงสร้างที่หลายเซิร์ฟเวอร์ส่งข้อความหากัน แต่จริง ๆ แล้วใกล้เคียงกับ RSS มากกว่า
    มีชั้นโฮสติ้งที่แยกจากแอป และใครก็สามารถโฮสต์ข้อมูลของตัวเองได้ จากนั้นแอปต่าง ๆ ก็ดึงข้อมูลจากทุกโฮสต์มารวมแล้วแสดงผล
    เพราะแบบนี้จึงไม่มีแนวคิดเรื่อง defederation แบบ Mastodon ตั้งแต่ต้น
    ถ้าอยากรู้เพิ่มดูได้ที่ https://overreacted.io/open-social/ และ https://overreacted.io/a-social-filesystem/
  • ATproto มีรูปแบบ federation ที่ต่างจาก Mastodon พอสมควร และไม่มีแนวคิดเรื่อง instance อยู่ในนี้
    บัญชีจะถูกโฮสต์อยู่บน PDS และบันทึกต่าง ๆ ก็ไปอยู่ที่นั่น แต่สิ่งที่เห็นในแอปนั้นมาจาก AppView ที่รวบรวมข้อมูลจากหลาย PDS
    เพราะงั้นไม่ว่าจะอยู่บน PDS ไหน ประสบการณ์ในแอปก็จะให้ความรู้สึกเหมือนบริการแบบรวมศูนย์ และ AppView ก็มีได้หลายตัวรวมถึงโฮสต์เองได้ด้วย
  • AppView ค่อนข้างต่างจาก fediverse และพึ่งพา shared relay มากกว่าการ federation แบบชัดเจน
    ค่าใช้จ่ายของการมี discoverability ระดับเกือบทั้งระบบแบบทุกวันนี้ก็น่าคิดอยู่ แต่ถึงอย่างนั้นก็ยากจะมองว่านี่เป็นแค่ Mastodon อีกตัว
  • ไม่เข้าใจว่าทำไมต้องเลือกเข้าข้างฝั่งใดฝั่งหนึ่ง หรือเลือกฝั่งที่เป็น คำตอบที่ถูกต้อง ด้วย
    จะไม่เลือกจุดยืนเลย หรือไปทางที่ตัวเองคิดว่าถูกก็ได้ไม่ใช่หรือ
  • พูดเกินจริงไปหน่อยก็จริง แต่ถึงจะเป็นแบบนั้น มันก็ดูดีกว่าโครงสร้างตอนนี้ที่ต้องพึ่ง GitHub กับ GitLab เพื่อให้พอมองเห็นตัวตนอยู่มาก

• ผมอาจมีอคติเพราะใช้งานฝั่ง atprotocol ค่อนข้างหนัก แต่ก็ใช้งาน Tangled แล้วพอใจมากจริง ๆ
  มันใกล้เคียงสิ่งที่ผมอยากได้จากตัวแทน GitHub มากที่สุด ฟีเจอร์อาจเรียบง่ายกว่า แต่ตลอดปีที่ผ่านมา มันเป็น social/git service หลักสำหรับโปรเจกต์โอเพนซอร์สส่วนตัวของผม
  บัญชีของผมคือ https://tangled.org/did:plc:rnpkyqnmsw4ipey6eotbdnnf
  ผมชอบที่ social graph จาก Bluesky ที่รู้จักกันอยู่แล้วต่อเนื่องมาถึงตรงนี้ ทำให้พอมองเห็นความเชื่อมโยงของคนที่อยู่เบื้องหลัง commit, PR และ issue ได้อย่างเป็นธรรมชาติ และการล็อกอินก็เหมือนกับบริการ atproto อื่น ๆ เลยใช้ง่าย
  ช่วงหลังยังเพิ่มการรองรับ static site ในตัว ทำให้สะดวกสำหรับโฮสต์เว็บไซต์แบบ client-side หรือ index.html ง่าย ๆ ตรงจาก repo
  Spindles ทำหน้าที่เป็นระบบ build/action ซึ่งแม้ผมจะไม่ใช่แฟน Nix แต่กับงานที่ต้องใช้มันก็เข้ากันได้ดีทีเดียว
  open API ก็ดีมาก เลยทำตัวเรนเดอร์ข้อมูลจากมาตรฐานบน atproto ได้ง่าย สร้างบอตได้ด้วย และยังเอาฟีเจอร์บางอย่างไปใส่ใน npmx.dev ได้อีก
  จะรัน knot (git server) กับ runner (Spindles) เองก็ได้ หรือจะใช้แบบโฮสต์ให้ก็ได้ แต่หัวใจสำคัญคือฟีเจอร์โซเชียลถูกแยกออกจากกัน ดังนั้นถึงจะใช้ git server คนละตัว บทสนทนาใน issue หรือ PR ก็ยังต่อเนื่องกันบน social layer กลางได้
  มันยังไม่สมบูรณ์ และป้าย alpha บน navbar ก็ไม่ได้มีไว้เฉย ๆ แต่สำหรับงานโอเพนซอร์ส ผมน่าจะยังใช้ต่อไปเรื่อย ๆ

  • ผมกังวลนิดหน่อยว่า atproto อาจถูกภาพลักษณ์ที่ยังไม่เด่นพอของ Bluesky ฉุดไปด้วย
    แต่ก็ยังไม่แน่ใจว่านั่นเป็นความกังวลที่สมเหตุสมผลแค่ไหน

• บรรยากาศในคอมเมนต์ค่อนข้างลบ แต่ถึงผมเองจะระวัง เงินทุน VC อยู่แล้ว ก็ยังคิดว่าควรสนับสนุนการแข่งขันในพื้นที่นี้
  ณ ตอนนี้การเริ่มอะไรแบบนี้ด้วยการ bootstrap ดูยากมากหรือแทบเป็นไปไม่ได้ และก็จริงที่มันจับจังหวะกับโพสต์วิจารณ์ GitHub ที่ขึ้นหน้าแรก HN เมื่อวานได้พอดี แต่ถึงอย่างนั้นผมก็ยังอยากเชียร์ความพยายามแบบนี้
  หวังว่ามันจะเติบโตจนมีขนาดที่มีความหมายได้

  • สำหรับผม นี่ไม่ใช่แค่ความคิดลบ แต่เป็น ความกังวลจริง
    ตอนเห็นแต่หัวข้อผมก็ตื่นเต้นนะ แต่พอรู้ว่ามีเงิน VC เข้าเกี่ยวก็หลุดจากตัวเลือกทันที
    ถ้าจะเอาโปรเจกต์งานรักที่ยังทำเงินไม่ได้ของผมไปไว้บนแพลตฟอร์มไหน ผมก็อยากเลือกที่ที่มีโอกาสต่ำกว่าจะโดน rug pull ในอีกสัก 5 ปี
    โปรเจกต์ที่มี VC ยังไงก็ต้องคืนผลตอบแทนให้นักลงทุน ดังนั้นผมมองว่าสุดท้ายมันต้องมี rug pull มาในรูปแบบใดรูปแบบหนึ่ง
    ตอนนี้เลยชอบใช้บริการแบบเป็นลูกค้าที่จ่ายเงินโดยตรง หรือไม่ก็บริการที่จ่ายค่าสมาชิกแบบสหกรณ์และมีสิทธิ์โหวตในการตัดสินใจมากกว่า
  • โปรเจกต์ที่มี VC ลงท้ายที่สุดก็มักไหลไปทาง rug pull, โฆษณา, การละเมิดความเป็นส่วนตัว หรือไม่ก็ยัดเยียดฟีเจอร์เสียเงิน
    เพราะงั้นในฐานะผู้ใช้ เราควรรู้ความเป็นไปได้นี้ล่วงหน้า
    เมื่อความจริงที่กำลังใกล้เข้ามาเป็นแบบนั้น ผมจึงไม่ชอบบริการที่ยังขายอุดมคติเกินจริง
    สู้เก็บค่าบริการไปตรง ๆ หรือถ้าจะยึดอุดมการณ์จริง ๆ ก็เริ่มแบบ non-profit ไปเลย หรืออย่างน้อยก็ควรประกาศแผนหารายได้ให้ชัด
  • ผมไม่ค่อยเข้าใจว่าทำไมถึงมองว่า bootstrap เป็นไปไม่ได้
    มันยากก็จริง แต่โดยเฉพาะถ้าตั้งใจทำ federation อยู่แล้ว มันก็น่าจะสร้างได้ด้วยโครงสร้างพื้นฐานที่ถูกกว่าเดิม ไม่ใช่แพงเท่ากันหรือแพงกว่าไม่ใช่หรือ

• ถ้าอยากรู้เรื่อง โมเดลข้อมูลของ atproto ผมเขียนบทความเกริ่นไว้ที่ https://overreacted.io/a-social-filesystem/
  มันค่อนข้างยาว แต่ช่วยให้เห็นภาพรวมได้ชัดมาก

  • นี่แทบจะเป็นการพูดน้อยไปด้วยซ้ำ
    เป็นบทความเกริ่น ATProto ที่ดีที่สุดเท่าที่ผมเคยอ่านมา
    สงสัยว่ามีแท็กหรือรายการที่รวมบทความพวกนี้ไว้ในที่เดียวไหม

• สำหรับผม สิ่งที่ต้องการไม่ใช่ forge federation แต่คือ git repo ที่สมบูรณ์ยิ่งกว่าเดิม
  Fossil ไปได้เกือบ 90% แล้ว เพราะรวม ticket, forum และ wiki เข้าเป็นส่วนหนึ่งของ repository ทำให้เวลาคลอนมาก็ได้ทุกอย่างลงมาด้วยและเปิดดูแบบออฟไลน์ได้
  คุณสามารถเขียนคำตอบไว้บนเครื่องบินได้ และถ้ามีสิทธิ์ ก็จะซิงก์ได้ทันทีหรือซิงก์ทีหลังเมื่อกลับมาออนไลน์
  แต่แทนที่จะฮาร์ดโค้ดชนิดของ artifact บางอย่างลงใน VCS ผมคิดว่าทิศทางที่ดีกว่าคือเก็บแอปไว้ใน repo แล้วให้แอปนั้นเป็นคนกำหนดว่าจะยอมรับ artifact แบบไหน มีกฎอะไรบ้าง และใครจะอัปโหลด/ดาวน์โหลดอะไรได้เมื่อไร
  ส่วน forge ก็มีหน้าที่แค่บังคับใช้นโยบายเหล่านั้นและเรนเดอร์ให้ผู้ใช้บนเว็บในรูปแบบที่ต้องการ
  ถ้าทำแบบนี้ การย้ายไป forge อื่นก็แทบจะจบแค่ push repo ไปเท่านั้น

  • ขอบคุณมากสำหรับไอเดียนี้จริง ๆ
    ช่วงนี้ผมกำลังทำพวก ticket system หรือ agent เป็น flat files ใน git repo อยู่พอดี ตอนนี้เลยเริ่มคิดว่าควรขยายแนวคิดนั้นไปถึงการจัดการ repo ทั้งหมดด้วย
    น่าจะดีมาก ๆ

• ปัญหาหลักของ federated solution สำหรับผมคือเรื่อง cold start
  ถ้าเข้าไปอยู่ในเซิร์ฟเวอร์ใหญ่ที่มีอยู่แล้ว คุณก็จะกลับไปเจอปัญหาความรวมศูนย์แบบเดียวกับที่พยายามหนี แต่ก็ได้เครือข่ายขนาดใหญ่มาตั้งแต่แรก
  ในทางกลับกัน ถ้าเปิดเซิร์ฟเวอร์เอง เครือข่ายก็เป็นศูนย์ discoverability ก็เป็นศูนย์ ฟีดก็ว่างเปล่า และยังต้องคอยหวังให้ไซต์อื่นยอม federate ด้วยหรืออย่างน้อยไม่บล็อกเพราะเป็นเซิร์ฟเวอร์คนเดียว
  ไม่แน่ใจว่ามีแค่ผมที่รู้สึกแบบนี้ หรือผมเข้าใจ federation ผิดไปเอง
  หรือบางทีมันอาจเป็นปัญหาเฉพาะของ Mastodon ก็ได้

  • เพราะแบบนี้ Tangled ถึงน่าจะเลือก ATproto แทน ActivityPub
    มันถูกออกแบบมาให้ AppView ส่วนกลางรวบรวมเซิร์ฟเวอร์แต่ละตัวเข้าด้วยกัน เพื่อมอบมุมมองเดียวที่สม่ำเสมอเหมือนเครือข่ายรวมศูนย์
    และใครก็โฮสต์ AppView ได้
  • อันนี้เป็นลักษณะของฝั่ง Mastodon มากกว่า
    atproto ไม่ได้ทำงานแบบที่แต่ละเซิร์ฟเวอร์เป็นพื้นที่กึ่งโดดเดี่ยวแยกจากกัน
    ถ้าอยากได้คำอธิบายในมุม distributed systems บทความ https://atproto.com/articles/atproto-for-distsys-engineers อธิบายไว้ดีมาก
  • ผมคิดว่าข้อดีมันอยู่ตรงกลาง
    ถ้าเซิร์ฟเวอร์ใหญ่เริ่มมีปัญหาเรื่อง moderation, policy, เนื้อหา หรือเทคนิคจนดูไม่น่าไว้ใจ ก็สามารถถอยออกมาได้ค่อนข้างง่าย แล้วไปสร้างหรือย้ายไปเซิร์ฟเวอร์ใหญ่อีกแห่งหนึ่งแทน
    หมายความว่าสามารถมีที่หลบภัยที่มีทั้งชื่อเสียงและขนาดในระดับหนึ่งได้ตั้งแต่ต้น
    ตอนนี้ก็มี forge ทางเลือกอย่าง GitLab, Codeberg, freedesktop, Fedora, Debian อยู่แล้ว ดังนั้นถ้ารักษาความมองเห็นและ discoverability ของโปรเจกต์ไว้ได้ มันก็น่าจะเป็นที่พักพิงที่ปลอดภัยพอ
  • ผมเองก็รู้สึกแบบนั้นมาตลอดจนพยายามหลีกเลี่ยงบริการแบบ federated
    แต่พอเห็นโปรเจกต์นี้เมื่อไม่กี่วันก่อน กลับคิดว่านี่อาจจะเวิร์กจริงก็ได้
    เพราะกลุ่มผู้ใช้เป้าหมายน่าจะทับซ้อนกับคนที่คุ้นกับ self-hosting อยู่มาก
    ไม่จำเป็นที่ทั้งเครือข่ายของผมจะย้ายมาตาม แค่กลุ่มย่อยที่มีแนวโน้มจะมาใช้ที่นี่จริง ๆ ก็มีประโยชน์มากพอแล้ว
  • สิ่งที่น่าสนใจตรงนี้คือมัน self-host ได้ และยัง migration ระหว่างผู้ให้บริการรายใหญ่ได้ด้วย
    ค่าใช้จ่ายของเซิร์ฟเวอร์ฝั่ง frontend น่าจะต่ำมาก จนดูมีโอกาสรันได้แทบถาวร และข้อมูลจริงก็ถูกป้อนมาจากโฮสต์อื่นอยู่แล้ว

• การที่ Tangled ได้รับเงิน VC ฟังดูเหมือนแรงกดดันให้ ต้องโตให้ได้ไม่ว่าอะไรจะเกิดขึ้น มากกว่าจะให้ความมั่นใจ
  เลยยังไม่ค่อยเห็นเสน่ห์ของมัน
  ต่อให้เป็น federated แต่ถ้าการพัฒนาหยุดลง แล้วใครจะมาดูแลแก้บั๊กและบำรุงรักษาต่อ

  • Tangled พัฒนากันแบบเปิดทั้งหมดที่ https://tangled.org/tangled.org/core และเป้าหมายคือ permanent software
    นั่นคือทำให้ทุกอย่างสามารถทำซ้ำได้อย่างสมบูรณ์ และ self-host ได้ทั้งหมดด้วยต้นทุนต่ำที่สุด
    เงิน VC เป็นเพียงเครื่องมือไม่ใช่เป้าหมาย และสำหรับผู้ก่อตั้งชาวอินเดียสองคนที่อยู่ในยุโรป เงินสนับสนุนแบบ grant ต้องรอ 4-12 เดือนขึ้นไปกว่าจะได้จริง จึงแทบไม่สมจริง
    เส้นทางที่เร็วที่สุดในการรวมทีม ตั้งโครงสร้างพื้นฐาน และเร่งการพัฒนาคือ VC และพวกเขาก็ใช้เวลากว่า 6 เดือนเพื่อหาพาร์ตเนอร์ที่มีเป้าหมายสอดคล้องกันอย่างมาก
  • ก็ให้คนที่ใช้งานมันดูแลต่อสิ
    Tangled มีตัวเลือกด้านสถาปัตยกรรมที่น่าสนใจหลายอย่าง แต่ตัวโค้ดเองค่อนข้างเรียบง่าย และจากที่ผมลองดูมาก็ไม่น่าดูแลยาก
    ส่วนใหญ่เป็น Go modules ที่เชื่อมกันแบบหลวม ๆ แล้วมี static HTML+CSS, TypeScript เล็กน้อย และ Nix สำหรับ orchestration เพิ่มเข้ามา
    ถ้าจำไม่ผิด ความต้องการฮาร์ดแวร์ก็ต่ำมาก ในขนาดตอนนี้คนคนเดียวก็น่าจะโฮสต์เองได้
    ภาระโครงสร้างพื้นฐานจริง ๆ ส่วนใหญ่ตกไปอยู่ที่ knots, spindles, PDS ของผู้ใช้ และตัว atproto ecosystem โดยรวม
  • คอมเมนต์นี้เองก็กำลังถูกเขียนอยู่บนเว็บรวมข่าวที่ได้รับ เงิน VC เหมือนกัน พอคิดแบบนั้นก็ไม่แน่ใจว่าจะฟันธงได้ขนาดนั้นไหม
  • VC พอรับได้ ตราบใดที่ไม่ใช่เงินจาก YC
  • พอมี VC เข้ามา ผมจะถามสองเรื่อง
    ทำไมต้องใช้ VC ด้วย และทำไมไม่ใช้การสนับสนุนจากองค์กรแบบ Ladybird
    อีกอย่าง นักลงทุนคาดหวัง ผลตอบแทน 10 เท่า แล้วสุดท้ายทำไมเราต้องเอาเวลาไปลงกับเครื่องมือสำหรับนักพัฒนาที่มีแนวโน้มจะ enshittification ในภายหลังด้วย

• มันทำให้นึกถึงมุกที่ว่าเมื่อมีมาตรฐานอยู่ 4 ตัวแล้วมีคนบอกให้รวมเป็นหนึ่งเดียวด้วยการสร้างมาตรฐานใหม่ สุดท้ายก็จะมี มาตรฐาน 5 ตัว
  ถึงจะเป็นมุกก็เถอะ แต่ผมคิดว่าควรมีเหตุผลที่หนักแน่นกว่านี้ว่าทำไม ActivityPub ถึงไม่พอ
  ก่อนจะกลับไปแก้ปัญหาการสื่อสารแบบกระจายศูนย์ด้วยวิธีใหม่อีกครั้ง

  • ActivityPub กับ atproto มีรูปร่างของระบบต่างกันตั้งแต่พื้นฐาน
    การเอามันมาเทียบกันคล้ายกับถามว่ามีอีเมลอยู่แล้วจะมีเว็บไปทำไม
    ActivityPub ทำงานเหมือนอีเมล คือเซิร์ฟเวอร์ทำหน้าที่เป็น inbox แล้วส่งข้อความหากัน
    แต่ atproto ทำงานเหมือนเว็บ คือที่เก็บข้อมูลของผู้ใช้เป็นคนโฮสต์ข้อมูล และแอปเป็นฝ่ายไปรวบรวมข้อมูลจาก storage เหล่านั้นมาแสดง
    topology ที่ต่างกันนี้ทำให้คุณสมบัติต่างกันด้วย เช่นใน atproto ต่อให้ผู้ใช้ย้ายโฮสต์ ประสบการณ์ในแอปก็ไม่สะดุด และใครก็สร้างแอปใหม่บนข้อมูลเดิมได้
    แต่ ActivityPub ทำแบบนั้นไม่ได้ และสุดท้ายจะใกล้เคียงกับบริการรวมศูนย์ขนาดเล็กหลายแห่งที่ผูกโฮสติ้งกับแอปไว้ด้วยกันแล้วส่งข้อความหากันมากกว่า
  • ผมคิดว่าควรดูด้วยว่าทำไม Tangled ถึงออกผลิตภัณฑ์บน ATProto ได้ตั้งแต่ก่อนระดมทุน แต่ ForgeFed กลับคืบหน้าช้ามาหลายปี
  • ในต้นฉบับก็มีลิงก์อยู่แล้ว แต่ถ้าอยากรู้ว่าทำไม ActivityPub ถึงไม่เหมาะกับปัญหานี้ ผู้เขียน ForgeFed เองก็อธิบายไว้ที่ https://forgefed.org/blog/actor-programming/

• ยังมี GitHub ทางเลือกบน Nostr ที่ค่อนข้างโตพอสมควรอย่าง https://gitworkshop.dev/ ด้วย
  ไอเดียหลักคือ repository สามารถอัปโหลดไปยัง nostr relay หลายตัวที่รองรับ GRASP ได้ และต่อให้เซิร์ฟเวอร์ตัวหนึ่งล่ม ก็ยังซิงก์แบบโปร่งใสผ่านที่อื่นได้
  ถ้าเลือกเซิร์ฟเวอร์ที่เชื่อถือได้ดี ก็แทบจะใกล้เคียงการทำงาน 100% และทั้ง repository, activity, issue ฯลฯ ก็มีการลงลายเซ็นทางคริปโตกราฟี

  • ดูยังไม่ค่อยโตขนาดนั้นนะ
    แค่ชื่อก็เหมือนจะละเมิดนโยบายเครื่องหมายการค้าของ git แล้ว
    https://git-scm.com/about/trademark
  • หวังว่าผมจะคิดผิด แต่โปรเจกต์นั้นดูเหมือน closed source
  • ผมเปิด repository ไหนในไซต์นั้นก็ไม่ได้สักอัน
    บางอันขึ้นว่าบราวเซอร์ไม่รองรับ URL แบบ ssh หรือ https บางอันก็ขึ้นแค่ Failed to load file tree แล้วหมุนไม่จบ
    เพราะงั้นคำว่า fairly mature เลยฟังไม่ค่อยน่าเชื่อเท่าไร

• ผมสนับสนุน federation มาก แต่ก็ไม่เคยเข้าใจประโยชน์ของ federation of forges เท่าไร
  forge ต่าง ๆ จะต้องแลกเปลี่ยนข้อมูลอะไรกันแน่
  ทำไม forge สำหรับ Blender ต้องเชื่อมกับ forge สำหรับ Ubuntu ด้วย
  คุณค่าหลักที่ผมได้จาก GitHub คือ single sign-on เวลาย้ายไปมาระหว่างโปรเจกต์ และผมคิดว่า forge อิสระต่าง ๆ ก็ลดปัญหานั้นได้มากเหมือนกัน แค่รองรับ social login โดยไม่ต้องมี forge federation ที่ซับซ้อน

  • เวลาคนจะหา software เขามักเริ่มจาก การค้นหาใน GitHub กันอยู่แล้ว
    ถ้าโฮสต์ forge เอง เว้นแต่จะเป็นชื่อใหญ่แบบ Blender ก็แทบไม่มีใครหา software ของคุณเจอ
    เพราะงั้นถ้าไม่อยากให้โค้ดหายไปในสุญญากาศ การมิเรอร์ไป GitHub ก็แทบจะกลายเป็นข้อบังคับ
    ถ้าอยากหลีกเลี่ยงจุดนั้นและทำให้ forge เล็ก ๆ แข่งกันได้ในฐานะกลุ่มเดียว ก็ต้องมีเครือข่ายเดียวที่ช่วยให้ค้นพบ software ได้ไม่ว่ามันจะอยู่บนโฮสต์ไหน และ ForgeFed ก็มีเป้าหมายตรงนั้น
    มันยังช่วยลดแรงเสียดทานของการต้องให้ผู้เริ่มต้นสร้างล็อกอินเฉพาะของแต่ละ forge ทุกครั้งด้วย ซึ่งเป็นประเด็นรองแต่ก็เกี่ยวข้องกัน
  • Git ถูกออกแบบมาให้กระจายศูนย์ตั้งแต่แรก
    GitHub แค่ทำ UI, issue และ PR ได้ดี จนผู้เริ่มต้นใช้งานผ่านหน้าจอได้ง่าย และจากตรงนั้นก็เกิดความรวมศูนย์
    federation สอดคล้องกับปรัชญาของ Git มากกว่า แต่ก็ไม่ได้จำเป็นต้องกระจายสุดโต่งจนโหนดใดโหนดหนึ่งดับแล้ว upstream หายไปหรือหาไม่เจอ
    Git เองแก้ปัญหาเรื่อง availability ไม่ได้ ส่วน federation สามารถช่วยเติมตรงนั้นได้โดยยังรักษาแนวคิดการกระจายศูนย์ไว้
  • ปัญหาใหญ่ที่สุดสุดท้ายก็ยังเป็น discoverability
    ต้องมีวิธีที่ทำให้หาโปรเจกต์โอเพนซอร์สบนเซิร์ฟเวอร์ที่กระจัดกระจายได้ง่าย
    การค้นหาโปรเจกต์บน GitHub ใช้ได้เฉพาะใน GitHub เท่านั้น
  • identity provider ที่ทำงานร่วมกันได้มีประโยชน์แน่
    และนอกจากนั้น มันยังช่วยให้ระบบ resilient มากขึ้นเวลาที่โฮสต์โปรเจกต์หายไป เปลี่ยนนโยบาย หรือถูกบล็อกโดยรัฐบาล
  • ข้อดีตรงนี้คือข้อมูลอยู่ในที่เดียวคือ PDS และถ้าต้องการก็ self-host ได้
    จากนั้น AppView จะรวบรวมข้อมูลจากหลาย PDS มาแสดงในหน้าจอเดียว
    ถ้า tangled.org เกิด enshittify ขึ้นมา ก็ยังใช้งานต่อจาก AppView อื่นได้เหมือนเดิม และ tangled.org เองก็ไม่ได้มีสถานะพิเศษเหนือใคร
    social login ของ forge อิสระก็ช่วยได้ แต่ส่วนตัวผมว่าการมีบัญชีเดียวสะดวกกว่า และด้วย AT protocol ต่อให้ forge รายใดรายหนึ่งหายไป ข้อมูลก็ยังเข้าถึงต่อได้ผ่าน AppView อื่น