จงระวัง Bluesky

 (kevinak.se)
1 คะแนน โดย GN⁺ 2026-02-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Bluesky ที่ใช้ ATProto เป็นฐาน สัญญาเรื่องการกระจายศูนย์ แต่ในความเป็นจริง ข้อมูลผู้ใช้ส่วนใหญ่กลับ กระจุกตัวอยู่บนเซิร์ฟเวอร์ของ Bluesky
  • ผู้ใช้สามารถรัน personal data server (PDS) ของตนเองได้ แต่เพราะ ความสะดวกและความเข้ากันได้ เกือบทั้งหมดจึงใช้เซิร์ฟเวอร์ค่าเริ่มต้นของ Bluesky
  • ยิ่งมีแอป ATProto ใหม่ออกมามากขึ้น ข้อมูลก็ยิ่งสะสมบนโครงสร้างพื้นฐานของ Bluesky มากขึ้น ทำให้เป็น โครงสร้างที่เสริมการรวมศูนย์
  • Bluesky ควบคุมชั้นแกนหลักโดยตรง เช่น โปรโตคอล, relay, AppView และ DID directory ทำให้หากมีการเข้าซื้อกิจการหรือเปลี่ยนนโยบาย ผู้ใช้จะควบคุมได้ยาก
  • ในทางเทคนิค ผู้ใช้สามารถย้ายออกและโฮสต์เองได้ แต่ในความเป็นจริง “ค่าเริ่มต้นมักชนะเสมอ” และด้วยโครงสร้างการลงทุน แรงกดดันด้านรายได้ยิ่งเสริมแรงจูงใจให้รวมศูนย์

คำสัญญาและความเป็นจริงของ Bluesky

  • Bluesky สร้างอยู่บน โปรโตคอลเปิดชื่อ ATProto และอ้างว่าผู้ใช้สามารถเป็นเจ้าของข้อมูลและตัวตนของตนเองได้
    • แอปหลากหลายอย่างเช่น Tangled, Grain, Leaflet สามารถเชื่อมต่อด้วยบัญชีเดียวกันได้
    • ชูประเด็นว่า “ถ้าต้องการก็ย้ายออกได้ทุกเมื่อ” เป็นคุณค่าหลัก
  • แต่ในทางปฏิบัติ ข้อมูลส่วนใหญ่กลับถูกเก็บไว้ใน PDS ที่ Bluesky เป็นผู้ดำเนินการ
    • แม้จะโฮสต์เองได้ แต่การตั้งค่าและดูแลรักษาซับซ้อน และแทบไม่มีประโยชน์เชิงปฏิบัติ
    • PDS ค่าเริ่มต้นของ Bluesky ใช้งานได้ทันทีและเข้ากันได้กับทุกแอป ทำให้ผู้ใช้ส่วนใหญ่เลือกใช้สิ่งนี้

โครงสร้างของการกระจุกตัวของข้อมูล

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

กลไกที่เร่งการรวมศูนย์

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

จุดคอขวด (Chokepoints)

  • Relay: ชั้นสำคัญที่ข้อมูลทุกอย่างต้องไหลผ่าน โดย Bluesky เป็นผู้ดำเนินการ relay หลัก
    • บุคคลที่สามสามารถรัน relay ได้ แต่ถ้าไม่มีฐานผู้ใช้ก็แทบไม่มีความหมาย
  • AppView: ชั้นที่ประกอบไทม์ไลน์ เธรด และการแจ้งเตือน ซึ่งพึ่งพา AppView หลักของ Bluesky
    • หากชั้นนี้หยุดทำงานหรือกลายเป็นปฏิปักษ์ ไคลเอนต์ทั้งหมดจะได้รับผลกระทบ
  • DID Directory: ทำหน้าที่ตีความตัวตนใน ATProto และ Bluesky เป็นผู้จัดการแบบรวมศูนย์
    • ตั้งแต่ปี 2023 มีการพูดถึงการกระจายศูนย์ แต่ ยังไม่มีกรอบเวลาที่ชัดเจน
  • แม้แต่ละชั้นจะบอกว่า “ใคร ๆ ก็รันเองได้” แต่ ในความเป็นจริงแทบไม่มีใครทำเช่นนั้น

การเปรียบเทียบกับอีเมล

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

ปัญหาที่อาจเกิดขึ้นเมื่อถูกเข้าซื้อกิจการ

  • หาก Bluesky ถูกเข้าซื้อกิจการ ผู้ซื้อจะสามารถควบคุมสิ่งต่อไปนี้
    • PDS ของผู้ใช้แทบทั้งหมด
    • relay หลัก
    • AppView หลัก
    • DID directory ที่ใช้ตีความตัวตนทั้งหมด
  • ผู้ซื้อสามารถ ปิดกั้นการส่งออกข้อมูล, บล็อกแอป third-party, หยุดความสามารถด้าน federation, แทรกโฆษณา, เซ็นเซอร์เนื้อหา และอื่น ๆ ได้
  • ขอบเขตความเสียหายจะไม่จำกัดแค่โซเชียลเน็ตเวิร์ก Bluesky แต่จะลามไปทั้งระบบนิเวศ เช่น Tangled, Leaflet, Grain
  • แม้ในระดับโปรโตคอลจะบอกว่าย้ายออกได้ แต่ บริษัทที่เข้าซื้อไม่มีแรงจูงใจที่จะยอมให้เกิดขึ้น

โครงสร้างการลงทุนและแรงจูงใจ

  • Bluesky เป็นบริษัทที่ มีมูลค่าประเมิน 700 ล้านดอลลาร์ และได้รับเงินลงทุน 120 ล้านดอลลาร์
    • นักลงทุนต้องการผลตอบแทน และสิ่งนี้อาจนำไปสู่ การเพิ่มการควบคุมผู้ใช้หรือแรงกดดันให้รวมศูนย์
  • โครงสร้าง PBC (บริษัทเพื่อประโยชน์สาธารณะ) ถูกเสนอว่าเป็นกลไกป้องกัน แต่ ผลทางกฎหมายและอำนาจผูกพันยังไม่ชัดเจน
  • บทสรุปคือ “โปรโตคอลไม่อาจช่วยคุณให้พ้นจากแรงจูงใจได้ (The protocol can't save you from incentives)”
    ซึ่งหมายความว่า แรงจูงใจทางเศรษฐกิจเป็นปัจจัยควบคุมที่ทรงพลังยิ่งกว่าการกระจายศูนย์ทางเทคนิค

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

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

 
GN⁺ 2026-02-22
ความเห็นจาก Hacker News

  • คำตอบที่ถูกต้องในทุกชั้นคือ “ใครก็รันเองได้” แต่ในความเป็นจริงแทบไม่มีใครทำแบบนั้น
    ยกเว้น PLC directory แล้ว โครงสร้างนี้เป็นแบบที่ ไม่มีใครห้ามได้ ดังนั้นในทางทฤษฎีใครก็เข้าร่วมได้
    ด้วยความยืดหยุ่นนี้ ATproto จึงมีจุดเริ่มต้นที่ได้เปรียบกว่าระบบแบบ federated อื่น ๆ มาก

    • ต้นตอของปัญหาคือ ความสะดวกของขั้นตอนสมัครแบบรวมศูนย์ ที่ดำเนินการด้วยเงินทุน VC
      Bluesky เปิดทางเข้าสู่การกระจายศูนย์ แต่ผู้ใช้ส่วนใหญ่ไม่ยอมรับต้นทุนและความฝืดของมัน
      Mastodon กระจายศูนย์เต็มรูปแบบจึงมีความฝืดตั้งแต่ขั้นสมัคร และเพราะแบบนั้นจึงขยายสู่มวลชนได้ยาก
      ฉันยังคงสงสัยอยู่ แต่คิดว่าถ้าจะ เผยแพร่การกระจายศูนย์สู่คนทั่วไป โมเดลแบบ Bluesky น่าจะดีที่สุด
    • การบอกว่า “ไม่มีใครห้าม” ในทางปฏิบัติหมายความว่า มีบางอย่างกำลังขวางอยู่
      มันอาจไม่ใช่ข้อจำกัดทางเทคนิค แต่เป็น แรงเฉื่อยหรือความเคยชิน
      การมีทางแก้ ไม่ได้แปลว่าปัญหาจะถูกแก้โดยอัตโนมัติ เป็นความคิดที่ไร้เดียงสา
      ทุกวิธีแก้มี ต้นทุนและความเป็นไปได้ในการลงมือทำ ที่ต่างกัน
    • การจะแก้ปัญหาต้องใช้ทั้ง ความรู้และเงินทุน
      ต้องมีทักษะทางเทคนิคและงบประมาณพอจึงจะรัน PDS เองได้อย่างปลอดภัย
      ต่อให้เป็นผู้ใช้ HN เองก็ยังยากที่จะโฮสต์สินทรัพย์ดิจิทัลทั้งหมดด้วยตัวเอง
      สุดท้ายก็ต้องไปใช้ บริการฟรี ที่รันด้วยเงินทุน VC อยู่ดี
    • ปัญหาที่แท้จริงคือ ค่าเริ่มต้น (defaults)
      แม้จะบอกว่าใครก็เปลี่ยนได้ แต่ในความเป็นจริงหลายครั้งการเปลี่ยนค่าเริ่มต้นแทบเป็นไปไม่ได้
    • คำถามที่ยังคงเหลือคือ “จะแก้มันอย่างไร?”

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

    • ถ้ากังวลกับ Bluesky ก็แนะนำให้ไปดูโปรเจ็กต์เก่า Secure-Scuttlebot(SSB)
      มันเคยแก้ปัญหาส่วนใหญ่ของ Bluesky ได้ด้วย content addressing และ การเข้ารหัส signed key
      โค้ด SSB ต้นฉบับพังไปแล้วหลังปี 2020 แต่ฉันมีเวอร์ชันฟอร์กที่ยังดูแลอยู่
      ถ้าอยากลองทดลองด้วยกัน ฉันก็เชิญได้
    • เพราะการรันอินสแตนซ์ Bluesky เองยังยากอยู่ สุดท้ายจึง ลงเอยที่การรวมศูนย์
      ถ้าผู้ใช้ 97% ไปรวมอยู่ในอินสแตนซ์เดียว ก็ยากจะเรียกมันว่าแพลตฟอร์มกระจายตัว
      ก็เหมือนกับการมองว่าเป็นปัญหาถ้า Mastodon.social มีสัดส่วนเกิน 40% ของทั้งหมด
    • การย้าย PLC ไปยังองค์กรอิสระไม่ได้หมายความว่า การกระจายศูนย์จะเกิดขึ้นจริง

  • เวลาพูดถึงโครงสร้างของ Bluesky ต้องพูดถึง Blacksky ด้วยเสมอ
    ถ้าไม่พูด ก็มีโอกาสสูงว่าบทความนั้นเข้าใจระบบนิเวศของ AT protocol ไม่พอ
    Blacksky เป็นโครงการที่พยายามทำ implementation ทดแทน สำหรับแต่ละชั้นของ ATproto

    • ฉันรู้จัก Blacksky ดี แต่ใน ภาพใหญ่ก็ไม่ได้เปลี่ยนอะไร
      อยากให้มันเปลี่ยน แต่ในความเป็นจริงผลกระทบยังน้อยมาก
    • แม้จะอ้างว่ากระจายศูนย์ แต่สุดท้ายก็เท่ากับกลับไปทำ บริการแบบรวมศูนย์ ใหม่อีกครั้ง
      ถ้าเป็นแบบนี้ ฉันคิดว่าใช้บริการบน XMPP อย่าง Movim ยังดีกว่า
    • ในทางปฏิบัติมันเป็นแค่รีโพซิทอรีที่มีผู้มีส่วนร่วมที่ยังแอ็กทีฟเพียง 1 คน
      เลยอาจเป็นเหตุผลที่ไม่ได้ถูกพูดถึงในบทความ
    • ถ้าต้องเปลี่ยนค่าเริ่มต้น ผู้ใช้ 99% จะไม่พยายามทำ
      สุดท้ายระบบจะยึด เส้นทางการใช้งานที่ง่ายที่สุด เป็นมาตรฐาน
      คุณค่าที่เป็นเพียง สมมติฐาน เช่นการป้องกันความเสี่ยงในอนาคต ไม่พอจะทำให้ผู้ใช้ขยับตัวได้

  • ฉันเคยได้ยินคำพูดว่า “ถ้า Twitter พัง เดี๋ยวก็ย้ายออก” มาตั้งแต่ก่อนหน้านี้แล้ว
    แต่ในความเป็นจริงคนส่วนใหญ่ไม่ได้ย้าย
    ถ้า Bluesky เป็นทางเลือกแทน Twitter ประเด็นสำคัญคือผู้คน จะย้ายจริงหรือไม่
    UI ก็แทบเหมือนเดิม และสมมติฐานตั้งต้นก็คือ “ถ้า Twitter แย่ลงก็จะย้ายออก”

    • ดูเหมือนความหมายของคำพูดนี้คือ ผู้คนย้ายจาก X ไป Bluesky เพื่อการกระจายศูนย์ แต่สุดท้ายก็เจอ lock-in แบบคล้ายกัน

  • คนรอบตัวฉันย้ายออกจาก Twitter ไปจริง ๆ
    ตอนนี้เพื่อน ๆ สื่อสารกันด้วยการแชร์ ลิงก์ Bluesky

    • ฉันไม่รู้จักใครเลยบน Bluesky
      ฉันยังใช้งานกับเพื่อน ๆ บน X อยู่ และยังชอบประสบการณ์แบบสมัย Twitter

  • ใน ATproto คุณสามารถ export ข้อมูลออกได้ตลอดเวลา
    เพราะเวลาแอปโต้ตอบกับ PDS มันก็ต้องอ่านข้อมูลอยู่แล้ว
    ถ้าปิดกั้นสิ่งนี้ ก็เท่ากับปิดกั้นความสามารถของ ATproto เอง

    • แต่ Twitter ก็เคยปิด API และ Google ก็ยุติ XMPP federation
      ต่อให้ Bluesky ตัดโปรโตคอลทิ้ง ผู้ใช้ส่วนใหญ่ก็ คงไม่ต่อต้านมากนัก
      อ้างอิง: ประกาศยุติการรองรับ XMPP ของ Google
    • ถ้าใช้บริการแบ็กอัปก็สามารถหลีกเลี่ยง การถูกปิดกั้นการเข้าถึงข้อมูล ได้

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

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

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

    • แต่ใจความของบทความคือคำเตือนว่า “ถ้าเกิดปัญหาขึ้นมา ก็สายเกินไปแล้ว”

  • การกระจายศูนย์อย่างแท้จริง สุดท้ายแล้วหมายถึง ทุกคนต้องรันเซิร์ฟเวอร์ของตัวเอง
    แม้จะมีภาระด้านค่าใช้จ่ายและการบำรุงรักษา แต่นั่นคือราคาที่ต้องจ่าย
    อย่างน้อย ATproto ก็รับประกัน การพกพาข้อมูล (data portability)
    ซึ่งเป็นสิ่งที่ Twitter หรือ Instagram ทำไม่ได้

    • ความพกพา (portability) นี้เป็นความพยายามเพื่อชดเชยข้อจำกัดของ ActivityPub
      ฝั่ง AP เองก็กำลังพยายามนำข้อดีบางส่วนของ ATproto มาใช้
      ส่วนฝั่ง Nostr บรรยากาศค่อนข้างต่างออกไป ฉันไม่แน่ใจว่าการถกเถียงครั้งนี้เป็นตัวแทนของทั้งคอมมูนิตี้นั้นหรือไม่

  • ฉันพูดว่า “ถ้า Twitter พังฉันจะย้าย” และฉันก็ ย้ายจริง
    ตอนนี้ฉันระวังโซเชียลมีเดียทุกแพลตฟอร์ม

    • สุดท้ายฉัน สูญเสียทั้งข้อมูลและความเชื่อมโยงทางสังคม และประสบการณ์นั้นทำให้ฉันระมัดระวังมากขึ้น