atproto ไม่มีอินสแตนซ์

 (overreacted.io)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • คำถามที่ถามหา “อินสแตนซ์ของ Bluesky” คือการนำ โมเดลอินสแตนซ์ ของ Mastodon มาครอบ atproto ตรงๆ ทั้งที่ atproto ถูกออกแบบมาให้แยกส่วนระหว่างการโฮสต์กับการรวมข้อมูลของแอป
  • คล้ายกับ RSS และ Google Reader ข้อมูลไม่ได้ถูกขังอยู่ในแอป แต่เก็บอยู่ใน ที่เก็บข้อมูลที่โฮสต์ไว้ และหลายแอปสามารถดึงข้อมูลนั้นไปแสดงผลได้
  • อินสแตนซ์ของ Mastodon เป็นโครงสร้างที่รวมการโฮสต์ แอป อัตลักษณ์ และความสัมพันธ์แบบสหพันธ์ไว้ในกล่องเดียว ทำให้การตัดสินใจของแอดมินหรือปัญหาล่มของอินสแตนซ์ส่งผลต่อประสบการณ์ผู้ใช้โดยตรง
  • ใน atproto ผู้ใช้สามารถย้ายโฮสต์ ลองใช้หรือสร้างแอปใหม่ได้ และแอปอย่าง Tangled, Semble, Sidetrail ก็ทำงานแยกจาก Bluesky
  • ถ้าจะดูความกระจายศูนย์ของ atproto ควรมองที่ การย้ายไปใช้โฮสต์ทางเลือก และ ระบบนิเวศของแอปใหม่ ว่าทำงานได้จริงหรือไม่ มากกว่าจะดู “จำนวนอินสแตนซ์ของ Bluesky”

โมเดลที่ใกล้กับ RSS และ Google Reader

  • ในยุค RSS ผู้ใช้โพสต์บทความลงบล็อกของตัวเอง และแอปอย่าง Google Reader หรือ Feedly จะทำหน้าที่ รวบรวม บทความจากหลายบล็อก
  • บทความไม่ได้ “อยู่” ใน Google Reader แต่ยังคงอยู่บนบล็อกหรือที่โฮสต์ของแต่ละคน
  • หัวใจสำคัญคือ การแยกระหว่างการโฮสต์กับการรวมข้อมูล
    • การโฮสต์คือที่ที่คอนเทนต์จริงอยู่
    • แอปรวบรวมข้อมูลมีลักษณะใกล้เคียงกับการฉายภาพ (projection) ของคอนเทนต์จากหลายแหล่ง

โซเชียลมีเดียแบบรวมศูนย์และคำตอบของ Mastodon

  • โซเชียลมีเดียแบบดั้งเดิมทำงานโดยรวบผู้ใช้ทั้งหมดไว้ในแอปและพื้นที่เดียว
  • โครงสร้างแบบนี้ทำให้เกิดการรวมศูนย์และ network effect ที่รุนแรง และการถกเถียงเรื่องโซเชียลเน็ตเวิร์กแบบกระจายศูนย์ก็เริ่มจากคำถามว่าจะกระจายปัญหานี้อย่างไร
  • แนวทางแบบ Mastodon คือให้แต่ละชุมชนดูแล “Facebook ขนาดเล็ก” หรือ “Twitter ขนาดเล็ก” ของตัวเอง และกล่องนั้นก็คือ อินสแตนซ์

สิ่งที่อินสแตนซ์ของ Mastodon ผูกไว้ด้วยกัน

  • ผู้ใช้จะสังกัดอยู่ “ภายใน” อินสแตนซ์ใดอินสแตนซ์หนึ่ง
    • เหตุผลที่รูปแบบล็อกอินของ Mastodon เป็น [email protected] ก็เพราะอัตลักษณ์มีอินสแตนซ์เป็นส่วนหนึ่ง
    • ผู้ใช้ไม่ได้เป็น “Alice” แบบนามธรรม แต่เป็น “Alice ของ instance #1”
  • ถ้าผู้ใช้จากคนละอินสแตนซ์จะสื่อสารกัน อินสแตนซ์ต้องรับส่งข้อความถึงกัน
    • ถ้า Alice อยู่บน instance #1 และ Bree อยู่บน instance #2 เมื่อ Alice ติดตาม Bree โพสต์ของ Bree จะถูกส่งมายัง instance #1
    • ความสัมพันธ์ในการส่งต่อแบบนี้คือ สหพันธ์ (federation)
  • เพราะการโฮสต์กับแอปถูกมัดรวมกัน ผู้ใช้จึงพึ่งพาอินสแตนซ์อย่างมาก

ข้อจำกัดที่เกิดจากการผูกกับอินสแตนซ์

  • หากแอดมินของอินสแตนซ์มีความขัดแย้งกัน พวกเขาอาจ หยุดสหพันธ์ ระหว่างกันได้
    • เมื่อเป็นแบบนั้น ผู้ใช้อาจไม่สามารถเห็นโพสต์ของเพื่อนได้อีก
  • ถ้าอินสแตนซ์ของผู้ใช้ล่ม อัตลักษณ์ที่ผูกกับอินสแตนซ์นั้นก็หายไปด้วย
    • เพราะผู้ติดตามกำลังติดตาม “ผู้ใช้ของอินสแตนซ์นั้น”
  • ลูกศรการเชื่อมต่อระหว่างอินสแตนซ์เพิ่มขึ้นแบบ O(n²)
    • ตอนนี้อาจยังไม่ใช่ปัญหาใหญ่ แต่หากโซเชียลเน็ตเวิร์กแนวนี้ได้รับความนิยม ก็อาจกลายเป็นประเด็นสำคัญ

ความแตกต่างหลักของ atproto

  • atproto ไม่ได้ตั้งอยู่บนแนวคิดอินสแตนซ์แบบ Mastodon แต่ย้อนกลับไปสู่โมเดลแบบ RSS และ Google Reader
  • ในระดับเครือข่าย มันแยก การโฮสต์กับการรวมข้อมูล ออกจากกัน
    • ข้อมูลอยู่ที่โฮสต์
    • แอปทำหน้าที่รวบรวมข้อมูลจากโฮสต์ของผู้คนจำนวนมาก
  • ดังนั้น atproto จึงไม่มีอินสแตนซ์
    • โฮสต์สามารถเปลี่ยนได้
    • แอปสามารถรวมข้อมูลจากหลายโฮสต์ได้
  • โครงสร้างนี้ให้ภาพของความกระจายศูนย์ที่หลากหลายกว่าการ “รันแอปเดียวกันหลายสำเนา”

การกระจายศูนย์ที่ผู้ใช้ทำได้เอง

  • ผู้ใช้สามารถ เปลี่ยนโฮสต์ ได้
    • ผู้เขียนระบุว่าได้ย้ายข้อมูล atproto ของตัวเองไปที่ Eurosky และกระบวนการเป็นอัตโนมัติโดยมาก ยกเว้นปัญหา UX บางส่วน
    • หากต้องการลงมือมากกว่านั้น ก็สามารถ โฮสต์เองฟรีบน Cloudflare ได้
  • ยังสามารถลองใช้แอปใหม่หรือสร้างเองได้ด้วย

ทำไม “จำนวนอินสแตนซ์ของ Bluesky” ถึงชี้ผิดจุด

  • ใน Mastodon การวัดความกระจายศูนย์ด้วยจำนวนอินสแตนซ์เป็นเรื่องธรรมชาติ
    • เพราะวิธีกระจายศูนย์หลักของ Mastodon คือการรันกล่องที่รวมทั้งโฮสต์และแอปให้มากขึ้น และทำให้กล่องเหล่านั้นคุยกันได้
  • แต่ใน atproto ทุกแอปมีลักษณะใกล้เคียงกับ การฉายภาพ ของ Atmosphere ทั้งหมด
    • โครงสร้างนี้คล้ายกับที่ Feedly และ Google Reader แสดงภาพของ Blogosphere ทั้งหมด
  • การรันสำเนาเต็มของเซิร์ฟเวอร์ฐานข้อมูล Bluesky หลายชุดนั้นทำได้ แต่โดยทั่วไปก็ไม่ได้มีประโยชน์ไปกว่าการรันสำเนา Google Reader หลายชุด
  • สำเนาบางชุดมีไว้เพื่อตอบโจทย์เฉพาะทาง
    • Blacksky เป็นตัวอย่างสำหรับความต้องการเฉพาะ เช่น ปรัชญาการกลั่นกรองที่ต่างออกไป
    • ไคลเอนต์ reddwarf.app ใช้ constellation ซึ่งเป็นแคชฟรีที่ชุมชนดูแล โดยไม่มีฐานข้อมูลเฉพาะของตัวเอง
  • มีการระบุว่าโครงสร้างพื้นฐานเครือข่ายแบบใช้ร่วมกันอย่าง Relay ถูก รันด้วยต้นทุนต่ำ มาตลอด 1 ปี

เกณฑ์ที่ควรใช้ดูใน atproto

  • หากจะวัดความกระจายศูนย์ของ atproto ไม่ควรดูที่ “จำนวนอินสแตนซ์ของ Bluesky” แต่ควรดูว่า
    • ผู้คนกำลังย้ายไปใช้ โฮสต์ทางเลือก หรือไม่
    • ผู้คนกำลังสร้างและใช้งาน แอปใหม่ หรือไม่
  • การแยกโฮสต์ออกจากแอปช่วยแก้แรงจูงใจที่บิดเบี้ยวได้ทั้งในโซเชียลแบบปิดและโซเชียลแบบสหพันธ์
  • หัวใจของ atproto คือการเก็บข้อมูลของผู้ใช้นอกตัวแอป และให้แอปมารวบรวมข้อมูลบนชั้นนั้น

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

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

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News

  • ดูเหมือนจงใจตีความคำถามว่า “Bluesky instance อยู่ที่ไหน” แบบผิดๆ เพื่อยก ATProto ขึ้นและกด ActivityPub ลง
    แบบนี้ทำให้ข้อเท็จจริงทางเทคนิคที่น่าสนใจ เช่น relay ของ ATProto กับข้อดีข้อเสียของมัน หรือการย้ายบัญชีของ ActivityPub กับข้อดีข้อเสียของมัน ถูกละเลยหรือบิดเบือน และสร้างความขัดแย้งที่ไม่จำเป็นระหว่างสองแพลตฟอร์มที่กำลังแก้ปัญหาคล้ายกัน
    คนจำนวนหนึ่งอาจใช้คำว่า “instance” ในความหมายทั่วไปอย่างเซิร์ฟเวอร์ ซอฟต์แวร์ที่กำลังรันอยู่ virtual machine หรือ container ก็ได้ เลยไม่เข้าใจว่าทำไมต้องตีความแบบแนวคิดของ Mastodon เท่านั้น
    ไดอะแกรมกับคำอธิบายทำได้ดี แต่การเหน็บ ActivityPub แบบแผ่วๆ ทำให้น่าเสียดาย เพราะให้ความรู้สึกว่ามาจากความเป็นปฏิปักษ์มากกว่าการสื่อข้อมูล

    • โทนของบทความตั้งใจให้ขี้เล่นเล็กน้อย แต่ผมคิดว่าคำถาม “Bluesky instance อยู่ที่ไหน” มักเกิดจากความเข้าใจผิดด้านสถาปัตยกรรมที่ใช้ จำนวน app instance เป็นตัวชี้วัดความกระจายศูนย์
      พอเทียบกับคำถามว่า “Google Reader instance อยู่ที่ไหน” ก็จะเห็นชัดว่าคำถามนั้นฟังดูแปลกแค่ไหน และผมคิดว่าภาพสองภาพท้ายบทความอธิบายประเด็นที่มักตกหล่นในการคุยเรื่อง atproto/ActivityPub ช่วงแรกๆ ได้ค่อนข้างดี
      เหตุผลที่ไม่ได้ใส่ relay ไว้เขียนไว้ที่นี่: https://news.ycombinator.com/item?id=48600963
      relay ไม่ได้เป็นแก่นหลักของโมเดลเท่าไรนัก แต่ใกล้เคียงกับการปรับแต่งประสิทธิภาพมากกว่า ดังนั้นในบทความจึงอยากโฟกัสที่ตัวโมเดลเอง
    • มันขึ้นอยู่กับบริบท แต่ในการถกเถียงรอบๆ ATProto, ActivityPub และ Mastodon คำว่า “instance” มักหมายถึง โหนด ActivityPub ที่โฮสต์ข้อมูลผู้ใช้และ URL โปรไฟล์ และบทความก็ดูเหมือนเล็งไปที่บริบทนั้น
      เมื่อคำคำหนึ่งเริ่มผูกกับแนวคิดและโครงสร้างเฉพาะ พอเห็นคำว่า “โซเชียลมีเดียแบบกระจายศูนย์” คนจำนวนมากก็จะนึกถึงโครงสร้าง federation แบบ ActivityPub และเมื่อเห็น ATProto ก็จะถามว่า “ทำไมถึงมี Bluesky instance ที่คนสมัครเข้าใช้อยู่แค่ที่เดียว?”
      ถึงจะไม่ใช่มุมมองใหม่ทั้งหมด แต่สำหรับคนที่มีภาพจำเดิมฝังอยู่แล้ว มันก็ดูเป็นบทความที่มีประโยชน์พอจะกลับมาแปะลิงก์ให้อ่านกันภายหลังได้
    • ATProto ปะทะ ActivityPub อาจดูเหมือน มหาศาสนเภทตะวันออก-ตะวันตก ของ Fediverse
      แทนที่จะเถียงกันเรื่องกฤษฎีกา “filioque” ก็กลายเป็นมีบล็อกโพสต์จากสองฝ่ายที่พูดกันคนละเรื่องเรื่องนิยามของ “federation”
    • ผมคิดว่าการแยกความต่างและเปรียบเทียบ Mastodon กับ ATProto เป็นเรื่องจำเป็น
      โมเดล Fediverse เข้าใจได้ง่ายจากมุมมองของโซเชียลเน็ตเวิร์กแบบเดิม แต่ ATProto เป็นแนวคิดใหม่ที่พยายามให้ อธิปไตยข้อมูล แก่ผู้ใช้ ขณะเดียวกันก็ได้ความสามารถในการขยายระบบแบบโซเชียลเน็ตเวิร์กศูนย์กลาง

  • สำหรับผม อุปมาที่ใช้นี่มันพัง
    RSS ไม่ได้พึ่ง Google Reader เลย และแม้ในยุครุ่งเรืองก็ยังพึ่งพาน้อยกว่าที่อีเมลทุกวันนี้พึ่ง Gmail เสียอีก
    ใน ATProto นั้น AppView ต้องพึ่ง relay มากพอสมควรถึงจะมีประโยชน์ขึ้นมาได้ และต้นทุนในการรัน relay ก็ไม่น้อยเหมือนกัน
    อีกอย่าง วงกลมสีเหลืองในภาพ RSS หมายถึงบล็อก แต่วงกลมที่หมายถึงโพสต์บน Facebook เป็นคนละลักษณะกัน บล็อกนั้นเป็นอิสระได้ด้วยตัวเอง
    ไม่ได้หมายความว่า ATProto แย่ แต่บทความนี้ให้ความรู้สึกว่าทำให้สับสนมากกว่าทำให้ชัดเจน

    • ทุกวันนี้ relay ถูกลงมากแล้วจริงๆ
      เมื่อก่อนมันแพงกว่าเล็กน้อยเพราะต้องเก็บทราฟฟิกทั้งหมดไว้ แต่ใน sync 1.1 ส่วนนั้นถูกเอาออกไปแล้ว และตอนนี้ก็รันได้ค่อนข้างสบายบน virtual machine ราคา 20 ดอลลาร์ต่อเดือน
    • relay เป็นส่วนที่ค่อนข้างหนักเมื่อเทียบกับองค์ประกอบอื่นของโครงสร้างพื้นฐาน AT Protocol แต่ค่าใช้จ่ายในการรันตอนนี้อยู่ราวๆ 30 ดอลลาร์ต่อเดือน ซึ่งคนส่วนใหญ่น่าจะรับไหว
      สิ่งที่แพงและยากจริงๆ ไม่ว่าจะรวมศูนย์หรือกระจายศูนย์ก็คือ moderation
      ผู้เขียนบทความนี้เคยพูดถึงความเข้าใจผิดที่พบบ่อยเกี่ยวกับ relay ไว้เมื่อ 9 เดือนก่อน: https://news.ycombinator.com/item?id=45077291#45078223

  • ในมุมผม relay คือกาวที่ทำให้ ATProto ทำงานได้ดีในแง่ประสิทธิภาพ
    มันขนส่งข้อมูลโดยไม่สนใจตัวเนื้อหา และดูเหมือนทำหน้าที่ลดจำนวนบริการที่แต่ละ AppView จำเป็นต้องรู้จัก
    อย่างที่บทความบอกไว้ จุดปรับปรุงใหญ่เมื่อเทียบกับ Mastodon คือ relay, AppView และ PDS เป็นบริการแยกกันที่มีความต้องการด้านการขยายระบบต่างกัน และนี่เป็นวิธีแก้ปัญหาเชิงออกแบบระบบที่ค่อนข้างงดงาม
    [1] https://atproto.com/guides/glossary

    • ใช่ relay เป็นหนึ่งในวิธีที่ทำแบบนั้นได้
      แต่มันเป็นการปรับแต่งที่มองไม่เห็น และยังมีกลยุทธ์อื่นอีก ดังนั้นในบทความจึงละไว้เกือบทั้งหมด
      ตัวอย่างเช่น ปัจจุบันแอปเล็กๆ หลายตัวไม่ได้สร้างดัชนีฐานข้อมูลของตัวเอง แต่พึ่งพา Constellation(https://constellation.microcosm.blue/) จึงไม่ได้ใช้ relay เลย
    • มีการลบคอนเทนต์ออกจาก relay โดยตรงด้วย
      เขาอ้างว่าจะลบเฉพาะคอนเทนต์ที่การโฮสต์จะผิดกฎหมาย แต่ผมไม่แน่ใจว่าจริงแค่ไหน และก็มีความเสี่ยงเสมอว่ามันจะเปลี่ยนไปในอนาคต
      https://docs.bsky.app/blog/blueskys-moderation-architecture#...

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

    • ถ้ากำลังถามเรื่อง moderation มันก็ทำงานคล้ายกับสิ่งที่คาดได้ในโลกที่ทุกอย่างเป็น RSS
      ในระดับโฮสติ้ง ผู้ให้บริการโฮสต์อาจระงับบัญชีได้เพราะเนื้อหาที่ผิดกฎหมายอย่างชัดเจน เหมือนที่ blogspot.com หรือ Cloudflare บล็อกบางกรณี
      ในระดับแอป ผู้ดูแลแอปและโมเดอเรเตอร์จะจัดการคอนเทนต์ที่ผู้ใช้สร้างขึ้นเหมือนเว็บเซอร์วิสอื่น ๆ
      เป็นเรื่องที่นักพัฒนาแอปเลือกเอง จะมีองค์ประกอบพื้นฐานสำหรับ moderation ในพื้นที่ของผู้ใช้แบบ Reddit หรือจะเสียบบริการ moderation แยกต่างหากแบบ Bluesky ก็ได้
      เพราะไม่มีสิ่งที่เทียบได้กับ “community instance” ที่จะมาทะเลาะกันเอง จึงไม่มี defederation ด้วย มีแค่โฮสติ้ง แอป และ moderation ระดับแอปตามทางเลือกของนักพัฒนาแอปเท่านั้น
    • ผมคิดว่าคำถามที่ดีกว่าคือ “ActivityPub แก้ปัญหาที่เกิดจาก defederation อย่างไร”
      โดยเนื้อแท้แล้วมันคล้ายกับสิ่งที่ Microsoft ทำกับอีเมลมาก กล่าวคือทิ้งข้อความจากผู้ให้บริการที่ไม่ใช่รายใหญ่ และทำให้การจะส่งข้อความถึงกันได้ในระบบที่ federate กันนั้น ผู้ใช้ต้องพึ่ง Microsoft หรือผู้เล่นรายใหญ่เดิมรายอื่น
      ผลคืออินสแตนซ์ใหม่ส่งข้อความไม่ได้และหาผู้ใช้ไม่ได้ ผู้เล่นรายใหญ่เดิมจึงมีแรงจูงใจที่บิดเบี้ยวในการไม่ federate กับอินสแตนซ์ใหม่
      การเลือกสถาปัตยกรรมแบบนี้มีผลทำให้ การกระจุกตัวแบบผู้เล่นน้อยราย แข็งตัวขึ้นในระยะยาว
      แม้จะอ้างว่าจำเป็นต่อการกันสแปม แต่ก็มีผู้ให้บริการที่ไม่ทำแบบนั้น ทั้งที่ถ้าตั้งค่า DKIM, reverse DNS ฯลฯ ให้ถูกต้อง ก็มักส่งถึง Gmail ได้ตามปกติ และพวกเขาก็ไม่ได้เจอปัญหาสแปมมากกว่า
      ทางเลือกที่ชัดเจนคือให้ไคลเอนต์เป็นฝ่ายกรอง ผู้ให้รายการตัวกรองที่มีลักษณะคล้าย uBlock จะเป็นผู้ส่งมอบตัวกรอง แทนที่จะเป็นผู้ดำเนินการแบบ Microsoft และเพราะพวกเขาไม่ได้รันอินสแตนซ์ใดโดยเฉพาะ จึงไม่มีแรงจูงใจจะต้อนทุกคนเข้าไปอยู่ในอินสแตนซ์ของตัวเอง
    • มันแก้ปัญหาแบบนั้นไม่ได้
      เว้นแต่จะมีจักรวาลทางเลือกที่มี AppView จำนวนมากพอซึ่งบริโภค firehose ทั้งหมดได้ เลือกใช้สลับกันได้อย่างอิสระ และรันเองได้ในต้นทุนต่ำ
      ATProto ใกล้เคียงกับ RSS ในโลกที่คุณอ่าน RSS ได้ผ่าน Google Reader หรือบริการโคลนขนาดใกล้เคียงเท่านั้น โดยไม่มี RSS reader บนเดสก์ท็อปหรือมือถือ

  • ถ้ามันร้องก๊าบเหมือนเป็ด มันก็คือเป็ด
    บัญชีหนึ่งมี PDS เดียว และ DID จะชี้ไปยัง PDS ซึ่งเป็นทั้งฟีดข้อมูลอย่างเป็นทางการของผู้ใช้และปลายทางสำหรับการเขียนข้อมูล
    ข้อมูลอาจถูกทำสำเนาได้ แต่ PDS ถูกถือเป็นต้นฉบับ
    สิ่งนี้ใกล้กับสถาปัตยกรรมแบบไคลเอนต์/เซิร์ฟเวอร์มากกว่าสถาปัตยกรรมแบบกระจายอย่างชัดเจน
    ไม่มีฐานข้อมูลแบบ P2P และไม่ได้เขียนลง DHT หรือเพียร์ด้วย เขียนลง PDS แล้วการเขียนนั้นจึงค่อยถูกมิเรอร์แบบเลือกได้
    การค้นพบก็ทำผ่าน DNS จึงไม่ได้ถามข้อมูลจากเพียร์
    การเชื่อมต่อกับ relay ก็ไม่ใช่เชื่อมต่อหาเพียร์ แต่เป็นไคลเอนต์ที่ขอสำเนาข้อมูลซึ่งถูกโฮสต์เป็นต้นฉบับอยู่บน PDS
    ผมไม่คิดว่าการเรียก PDS ว่าอินสแตนซ์ และเรียก relay ว่ามิเรอร์ จะเป็นการฝืนเกินไป

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

  • ผมเข้าใจว่า ATproto ยอมสละความกระจายศูนย์ที่แท้จริงเพื่อความสม่ำเสมอ ส่วน Mastodon และ ActivityPub ยอมสละความสม่ำเสมอที่แท้จริงเพื่อความกระจายศูนย์ที่เข้าถึงได้มากกว่า
    เพราะการรันโหนด ActivityPub เข้าถึงได้ง่ายกว่ามากสำหรับผู้ใช้โฮสต์เองทั่วไป เมื่อเทียบกับการรัน content relay ของ AT
    สิ่งที่ "กระจายศูนย์" ได้ใน AT ท้ายที่สุดก็คือข้อมูลของตัวเองเท่านั้น และมันใกล้เคียงกับการ เป็นเจ้าของข้อมูลของตัวเอง มากกว่าการเป็นเจ้าของส่วนหนึ่งของเครือข่ายร่วมกัน
    นี่ก็เป็นประเด็นที่พูดซ้ำกันมาหลายรอบแล้วใน HN

    • เป็นมุมมองที่น่าสนใจ แต่จากความเข้าใจปัจจุบันของผม AtProto กลับให้ความรู้สึกว่าเข้าถึงง่ายกว่าและกระจายศูนย์มากกว่า
      ใน ActivityPub การรันอินสแตนซ์หมายถึงต้องรับผิดชอบทั้งข้อมูล แอปพลิเคชัน และปัญหาการขยายตัวต่อจากนั้นทั้งหมด ดังนั้นคุณต้องเลือกระหว่างรับภาระการดูแลเอง หรือผูกติดกับอินสแตนซ์ของคนอื่น
      ต่อให้คุณไม่ชอบอินสแตนซ์ที่เลือกและอยากย้าย ถ้ายังไม่มีการเปลี่ยนแปลงนั้น คุณก็แทบต้องเริ่มใหม่เกือบทั้งหมด
      ใน AtProto การย้ายไปยังแพลตฟอร์มแอปพลิเคชันอื่นโดยยังคงตัวตนเดิมไว้ทำได้ง่ายกว่า และการ export ข้อมูลออกจากแพลตฟอร์มมาโฮสต์เองก็อย่างน้อยยังพอเป็นไปได้ แม้ประสบการณ์ผู้ใช้จะยากอยู่บ้าง
      ตัวอย่างเช่น ผมเพิ่งลองใช้ Tangled ครั้งแรกเมื่อไม่นานนี้ และสามารถล็อกอินด้วยโดเมนที่อิง bsky เดิม (h14h.com) ได้เลย ไม่ต้องสร้างบัญชีใหม่หรือชื่อผู้ใช้ใหม่ เหมือนผมอยู่ที่นั่นอยู่แล้ว
      การตั้งค่า self-hosted git repository บน VPS ก็ใช้เวลาอย่างมากแค่ครึ่งวัน และมันทำงานเป็นบริการเบื้องหลังที่แทบไม่ต้องดูแล
      ในกรณีแย่ที่สุดก็อาจมีแบนเนอร์บน tangled.org ว่า "repository ของคุณเก่าเกินไปและอาจไม่เข้ากันกับ Tangled เวอร์ชันล่าสุด" และแก้ได้ด้วยการ build image Docker ใหม่แล้ว deploy เวอร์ชันล่าสุด
      ในเชิงสถาปัตยกรรม AtProto เข้าใจยากกว่ามากแน่นอน แต่ในแง่การทำให้ผู้ใช้จริงเข้าถึงได้ ผมมองว่ามันง่ายกว่ามาก
    • ผมไม่แน่ใจว่ามีสิ่งที่เรียกว่า ความกระจายศูนย์แบบ "แท้จริง" หรือเปล่า
      ในหัวผมมันไม่ใช่สไลเดอร์อันเดียว แต่ใกล้เคียงกับ บุฟเฟต์ของ trade-off มากกว่า
      อนึ่ง ในโลก AP ก็มีทั้งบุคคลและทีมเล็ก ๆ ที่รัน relay, mirror, cache, AppView อยู่เหมือนกัน เพียงแต่ก็จริงที่ว่าพอขนาดใหญ่ขึ้นมันอาจมีค่าใช้จ่ายสูงขึ้น
    • นั่นอธิบายได้บางส่วน แต่ไม่ได้อธิบายทั้งหมด
      AT ไม่ได้ให้แค่ความสม่ำเสมอเท่านั้น แต่ยังให้ โมเดลข้อมูลที่ใช้ร่วมกัน ครอบคลุมทั้งแอปด้วย
      เพราะแบบนั้นแอปต่าง ๆ จึงสามารถอ้างอิงและเรนเดอร์คอนเทนต์ของแอปอื่นได้ มันคล้ายเว็บของ JSON แบบมีชนิดข้อมูล และแอปที่ต่างกันก็เป็นเลนส์ที่ใช้มองเครือข่ายเดียวกัน
      ใครก็สามารถสร้างประสบการณ์ใหม่บนข้อมูลเดิมที่มีอยู่ได้ และใน AP แทบไม่มีสิ่งที่เทียบเคียงได้
      AP ผูกข้อมูลเข้ากับแอป แต่ใน AT มันใกล้เคียงกับการที่ทุกแอป query ฐานข้อมูลกลางระดับโลกหนึ่งเดียวที่มีข้อมูลทั้งโลกมากกว่า
      ผมไม่เข้าใจว่าทำไมการถกเถียงถึงติดอยู่ที่ relay ตลอด ทุกวันนี้ถ้าต้องการ คุณรัน relay ได้ราว 30 ดอลลาร์ต่อเดือน และจะใช้ relay ของ Bluesky หรือ community relay ฟรีก็ได้
      หลายแอปไม่ได้ใช้ relay เลย และพึ่งพา community index อย่าง Constellation(https://constellation.microcosm.blue/) แอปบางตัวไม่รันแม้แต่เซิร์ฟเวอร์หรือฐานข้อมูลของตัวเอง
    • Mastodon ก็มี content relay เหมือนกัน
      แต่จริง ๆ แล้วผมอยากโต้แย้งกลับว่า ATproto กระจายศูนย์มากกว่า หรืออย่างน้อยก็พยายามจะเป็นแบบนั้น
      ในโลก ActivityPub ตัวตน แอปพลิเคชัน และการโฮสต์ ถูกเชื่อมติดกันโดยเนื้อแท้
      ถ้าจะใช้ Lemmy คุณต้องสร้างบัญชี ActivityPub ถาวรที่แยกออกจากกันอีกอันบนอินสแตนซ์ Lemmy นั้น หรือไม่ก็ใช้ Lemmy ได้แค่เท่าที่อินสแตนซ์ Mastodon ของคุณส่งข้อความที่ Lemmy เข้าใจได้
      ทุกแอป ActivityPub ใหม่สร้างปัญหา interoperability ชุดใหม่ เพราะแต่ละแอปเป็นเจ้าของตัวตนและการโฮสต์ของตัวเอง
      ไม่มีทางที่อินสแตนซ์ Mastodon ที่ผมโฮสต์เองจะมอบตัวตนให้เซิร์ฟเวอร์ Lemmy และให้เซิร์ฟเวอร์ Lemmy สั่งให้อินสแตนซ์ของผมโฮสต์คอนเทนต์แทนผมได้
      ถ้าจะให้ถึงระดับที่ ATProto พูดถึง อย่างน้อยก็ต้องทำได้ระดับนั้น เพียงแต่ผมก็ไม่แน่ใจว่ามันตรงกับ ATProto ที่มีอยู่จริงมากแค่ไหน และ ActivityPub ที่มีอยู่จริงก็ไม่ได้ interoperable มากอย่างที่ผู้สนับสนุนพูดเหมือนกัน

  • บล็อกนี้อธิบายสถาปัตยกรรมได้ดี
    แต่ในทางปฏิบัติ ผมคิดว่า "ปัญหา" คือ บริษัท Bluesky เป็นผู้รันแอปหลักและโฮสต์ข้อมูลผู้ใช้ส่วนใหญ่
    ในระดับโปรโตคอลมันกระจายศูนย์ก็จริง แต่ระบบที่ใช้งานจริงยังคงรวมศูนย์อย่างมากในแง่ของผู้มีอำนาจควบคุม
    ไม่ได้หมายความว่านี่เป็นความผิดของ Bluesky เสมอไป แต่ผมรู้สึกว่าที่ผ่านมาแนวโน้มมันก็เป็นแบบนั้นไม่ใช่หรือ

    • "ปัญหา" อยู่ที่ผู้คนพยายามมองหาปัญหา
      ปัญหานี้ไม่ได้เป็นเรื่องเฉพาะของ Bluesky หรือ ATProto ไม่ว่าจะเป็นองค์กรแสวงหากำไร องค์กรไม่แสวงหากำไร หรือกลุ่มอาสาสมัคร ก็จะมีคนหาเรื่องมองว่าเป็นปัญหาอยู่เสมอ
      ผมไม่ได้มีผลประโยชน์ทับซ้อนกับ Bluesky นอกเหนือจากการเป็นผู้ใช้ยุคแรก ไม่ใช่นักลงทุน และก็เข้าใจทั้งโปรโตคอล บริษัท และเว็บไซต์ในขอบเขตที่ตัวเองทำได้
      ตัวเว็บและแอปทำงานได้ดี ผู้คนมัวแต่จดจ่อกับการหาปัญหามากเกินไป แทนที่จะสร้างทางออกที่ใหญ่กว่าและดีกว่า
      คนส่วนใหญ่ไม่ได้ต้องการทางแก้ P2P แบบชั่วคราวอย่าง Lemmy หรือ Mastodon พวกเขาต้องการให้คอนเทนต์อยู่ที่เดียว และต้องการให้มีผู้รับผิดชอบที่เรียกร้องได้
      เพราะงั้นผมคิดว่า โซเชียลเน็ตเวิร์กแบบ P2P จะไม่มีวันเป็นกระแสหลัก ดราม่ารอบ ๆ Lemmy กับ Mastodon มีมากกว่า Twitter, Reddit, Facebook ฯลฯ รวมกันเสียอีก
      นี่เป็นความเห็นส่วนตัวของผม และดูเหมือนคู่สมรสกับเพื่อน ๆ ของผมก็คิดคล้ายกัน
    • มีทั้งแอปอื่น การโฮสต์ข้อมูลผู้ใช้แบบอื่น การโฮสต์ส่วนบุคคล และบริการแบ็กเอนด์แบบอื่น
      มันกระจายศูนย์ทั้งในทางทฤษฎีและในทางปฏิบัติ
      เพียงแต่เพราะ Bluesky ดูแลสัดส่วนที่ใหญ่ที่สุด จึงอาจพูดได้ว่าในระดับชุมชนหรือ mindshare มันยังไม่กระจายศูนย์ แต่จุดนั้นก็กำลังเปลี่ยนไป
    • อธิบายได้ดีจริงหรือ?
      มันแค่บอกว่า "ไม่มีอินสแตนซ์" แต่ไม่ได้อธิบายเลยว่าสถาปัตยกรรมนั้นหลบเลี่ยงปัญหาอย่างการยืนยันตัวตน การซิงก์ และการค้นพบได้อย่างไร

  • การยก Google Reader มาเป็นอุปมาให้ความรู้สึกเป็นลางร้าย
    RSS ยังอยู่รอดหลังจาก Google Reader ปิดตัวลงก็จริง แต่ไม่ได้หมายความว่าทุกคอมมูนิตี้ที่ใช้ RSS จะรอดทั้งหมด และหลายแห่งในนั้นทุกวันนี้ก็ไม่รู้ด้วยซ้ำว่า RSS คืออะไร
    การอ้างว่าเป็นสิ่งกระจายศูนย์ แต่ยังชี้ไปที่ การรวมศูนย์ทางสังคม ขนาดใหญ่ของระบบนิเวศกระจายศูนย์เหมือนเป็นตัวอย่างที่ดี มันให้ความรู้สึกเกือบจะเป็นแบบฟรอยด์
    โดยเฉพาะเมื่อเรารู้ตอนจบของเรื่องนี้อยู่แล้ว
    Google Reader รวบรวมบ้าน RSS จำนวนมากไว้ที่เดียว และเพิ่มคุณค่าอย่างกราฟสังคมกับคอมเมนต์เข้าไป แต่สุดท้ายก็พังลงเพราะความเปลี่ยนใจของผู้บริหาร Google จนเกือบฆ่า RSS และทำลายกราฟสังคมที่น่าประทับใจนั้น
    ถ้าใช้อุปมาแบบนั้น ก็ยิ่งไม่ทำให้เชื่อมั่นใน ATProto เท่าไร

    • หัวใจสำคัญของ atproto คือแม้แต่ กราฟสังคม ก็อยู่ฝั่ง “บล็อก/RSS”
      แอปมีหน้าที่แค่อินเด็กซ์มันเท่านั้น
      เพราะงั้นในอุปมานี้ ใครก็สามารถใช้กราฟเดียวกันนั้นชุบชีวิต Google Reader หรือทำบริการแข่งได้
      ถ้าอยากเห็น ตอนนี้ http://leaflet.pub ก็ทำงานในลักษณะนั้นจริง ๆ
    • ฟังดูเป็นลางร้าย แต่ก็แม่นยำ
      ลองนึกภาพว่าคุณใช้ RSS reader บนเดสก์ท็อปหรือมือถือไม่ได้ และอ่าน RSS ได้ผ่าน Google Reader หรือบริการโคลนที่มีขนาดใกล้เคียงเท่านั้น
    • แต่ตอนนี้มี RSS reader ดี ๆ มากมาย
      ไม่นานมานี้ก็ยังมีคนพูดถึง NetNewsWire อยู่

  • ความต่างสำคัญคือบล็อกมีเว็บไซต์ของตัวเอง และไม่จำเป็นต้องใส่บทความเต็มไว้ใน RSS feed
    แต่ปกติ Bluesky ไม่ได้ทำงานแบบนั้น ทุกอย่างใน PDS จะถูกทำสำเนา
    แถมยังสนับสนุนให้ใส่บทความบล็อกเต็ม ๆ ลงใน PDS เพื่อให้ทำสำเนาได้ง่าย
    แบบนั้นใครก็ตามที่อยากอินเด็กซ์ก็หยิบสำเนาไปได้ และคุณควบคุมไม่ได้เลยว่าเขาจะเอาไปทำอะไร
    มันไม่จำเป็นต้องเป็นแบบนั้นเสมอไป คุณสามารถโพสต์บล็อกบนเว็บไซต์ของตัวเอง แล้วลงแค่ลิงก์บน Bluesky ก็ได้

    • แล้วมันต่างจาก scraper ที่คอยดูดข้อมูลจากบล็อกโดยตรงยังไง?
    • พูดตามตรง นั่นก็เป็นเพราะ atproto เป็น โปรโตคอลข้อมูลดิบ ด้วย
      การวาง HTTP frontend ครอบบนบัญชี atproto เป็นแนวทางที่แนะนำ และในทางปฏิบัติก็มีคนทำกันมาก
      ผมเองก็ทำแบบนั้นบน pfrazee.com และโพสต์บล็อก leaflet ของผมที่มีต้นฉบับอยู่บน atproto ก็ถูกเรนเดอร์บนบล็อกของผมเช่นกัน

  • การเปรียบเทียบกับ RSS ทำให้เข้าใจผิด
    แอป Atproto ไม่เหมือน RSS reader ที่รันบนคอมพิวเตอร์ของผู้ใช้และเชื่อมตรงไปยังแหล่งเนื้อหา
    แอป Atproto คือ เซิร์ฟเวอร์ ที่ควบคุม คัดกรอง และจัดรูปแบบเนื้อหาที่จะส่งให้ผู้อ่าน
    แอป Atproto สามารถทำการเซ็นเซอร์ shadowban แทรกโฆษณา หรือทำฟีดแบบอัลกอริทึมได้ตามใจ
    ผู้ใช้ไร้อำนาจ และครีเอเตอร์ก็เป็นเหยื่อที่ทำได้แค่โวยวาย
    การที่ใครก็ได้จะโฮสต์ข้อมูลไว้ที่ไหนก็ได้ ไม่มีความหมายอะไรเลยถ้าไม่มีวิธีกระจายข้อมูลนั้น

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