BlueSky ทำงานอย่างไร

 (steveklabnik.com)
2 คะแนน โดย GN⁺ 2024-02-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • BlueSky เป็นแอปไมโครบล็อกกิงที่คล้ายกับ Twitter และ Mastodon แต่เป้าหมายที่ใหญ่กว่าคือการพิสูจน์ว่าสามารถสร้างแอปโซเชียลแบบกระจายศูนย์ขนาดใหญ่บน AT Protocol(atproto) ได้หรือไม่
  • atproto ไม่ใช่บล็อกเชน·DAO·NFT แต่เป็นโปรโตคอลแบบเฟเดอเรชันที่ใช้การเข้ารหัสและ Merkle tree เป็นต้น โดยให้บันทึกที่ผู้ใช้ลงลายเซ็นถูกประมวลผลแยกกันระหว่าง PDS, Relay และ App View
  • ความสามารถในการขยายระบบมาจากโครงสร้างที่ Personal Data Server(PDS) ของผู้ใช้ไม่ต้องส่งโพสต์ไปยังผู้ติดตามทุกคนโดยตรง แต่ให้ Relay รวบรวมข้อมูลเครือข่ายและให้บริการเป็น firehose แทน
  • การกลั่นกรองถูกแยกตามโมเดล “speech vs reach” โดยแยกการทำสำเนาคอนเทนต์ออกจากการควบคุมการมองเห็น ทำให้ labeler, feed generator และ App View สามารถใช้ตัวกรองและการบล็อกได้
  • DID ที่เสถียรและ handle ที่อิงโดเมนช่วยให้บัญชีย้ายได้ แต่บริการแปลความ did:plc ที่ BlueSky ดำเนินการอยู่ยังคงเป็นประเด็นเรื่องความเป็นศูนย์กลาง

ความสัมพันธ์ระหว่าง BlueSky กับ atproto

  • ปัจจุบัน BlueSky ทำงานเป็น แอปไมโครบล็อกกิง แต่ในภาพรวมทั้งหมด มันคือแอปแรกเริ่มที่ใช้พิสูจน์ความเป็นไปได้ของ Authenticated Transfer Protocol หรือ atproto
  • เว็บไซต์ของ BlueSky ระบุว่า “โซเชียลมีเดียสำคัญเกินกว่าจะถูกควบคุมโดยบริษัทเพียงไม่กี่แห่ง และเรากำลังสร้างรากฐานแบบเปิดของ social internet ที่ทุกคนสามารถร่วมสร้างอนาคตได้”
  • เนื่องจาก BlueSky เป็นบริษัท จึงอาจมีมุมมองเชิงกังขาว่า “ของที่ไม่ควรถูกควบคุมโดยบริษัทกลับถูกสร้างโดยบริษัท” แต่หัวใจของการออกแบบอยู่ที่ atproto มากกว่าตัวแอป
  • atproto คือ โปรโตคอลแบบเฟเดอเรชัน สำหรับแอปโซเชียลแบบกระจายศูนย์ขนาดใหญ่

โปรโตคอลแบบกระจายศูนย์ที่ไม่ใช่คริปโต

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

โครงสร้างพื้นฐานของ atproto

  • atproto ใช้ โครงสร้างแบบเฟเดอเรชัน ที่ให้หลายฝ่ายดูแลส่วนต่าง ๆ ของระบบและสื่อสารกัน
  • โดยคำนึงถึงฐานผู้ใช้ขนาดใหญ่ จึงออกแบบให้ฝ่ายที่รับภาระได้มากรับหน้าที่มากขึ้น และลดภาระของฝ่ายที่ไม่สามารถรองรับโหลดได้
  • ณ เวลาที่เขียน BlueSky มีผู้ใช้เกิน 5 ล้านคน ในสัปดาห์นั้น และถูกประเมินว่ามีเสถียรภาพมากกว่า Twitter ยุคแรกมาก
  • ปัจจุบัน atproto เป็นระบบแบบ เปิด 100% และยังไม่มีฟีเจอร์อย่างข้อความส่วนตัว
    • เพราะการทำฟีเจอร์แบบปิดให้ถูกต้องในระบบเฟเดอเรชันทำได้ยาก จึงเลือกที่จะยังไม่ปล่อยฟีเจอร์ที่มีข้อจำกัดร้ายแรง และรอให้ทำได้อย่างถูกต้องแทน
    • ตอนนี้จึงเหมาะกับการใช้งานเฉพาะเนื้อหาที่เปิดเผยได้

record, repository, App View, Relay

  • ผู้ใช้สร้าง record ที่ลงลายเซ็นด้วยวิธีเข้ารหัส และใช้ลายเซ็นนี้ยืนยันผู้เขียน
  • record เป็นไปตามสคีมาที่เรียกว่า Lexicon
  • record ถูกเก็บใน repository ซึ่งทำงานเป็นบริการที่เปิดให้เข้าถึงผ่าน HTTP และ WebSocket
    • บริการประเภทนี้มักถูกเรียกว่า PDS(Personal Data Server)
    • ผู้ใช้สามารถรัน PDS เอง หรือใช้ PDS ที่ผู้อื่นโฮสต์ให้ก็ได้
  • แอปพลิเคชันจะอ่าน record ที่เก็บอยู่บนเครือข่ายแล้วสร้างฟังก์ชันการทำงานบนข้อมูลนั้น
    • เนื่องจากบริการประเภทนี้เปิดเผยมุมมองข้อมูลแบบเฉพาะ จึงเรียกว่า App View
    • การสร้างแอปหมายถึงการนิยาม Lexicon อ่าน record ที่ใช้ Lexicon นั้น และมองข้ามส่วนที่เหลือ
  • การให้ PDS แจ้งเตือนกันโดยตรงมีปัญหาเรื่องการขยายระบบอย่างมาก
    • หากทุกครั้งที่มีโพสต์ใหม่ต้องส่งตรงไปยัง repository ของผู้ติดตามทุกคน จะไม่มีประสิทธิภาพและทำให้ค่าใช้จ่ายของ repository ยอดนิยมสูงมาก
  • Relay ถูกใช้เพื่อลดปัญหานี้ โดยรวบรวมข้อมูลเครือข่ายแล้วเปิดให้ใช้งานเป็น firehose
    • App View จริงจะดู Relay แทนที่จะดู repository โดยตรง
    • เมื่อผู้เผยแพร่โพสต์ข้อความ repository จะไปแจ้ง Relay และผู้ติดตามจะเห็นผลลัพธ์ที่ App View กรองจากเอาต์พุตของ Relay
    • Relay อาจมีขนาดใหญ่และมีค่าใช้จ่ายสูง แต่ก็อาจจินตนาการถึง Relay ขนาดเล็กกว่าที่เผยแพร่เฉพาะกลุ่มย่อยของผู้ใช้บางส่วนได้เช่นกัน

โมเดลการกลั่นกรอง “speech vs reach”

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

Feed generator

  • ใน atproto ฟีดถูกแยกออกเป็นบริการต่างหากที่เรียกว่า feed generator
  • feed generator รับ firehose ที่ Relay สร้างขึ้น แล้วกรองและจัดเรียงคอนเทนต์ตามเกณฑ์ที่ต้องการเพื่อแสดงเป็นรายการ
  • ผู้ใช้สามารถแชร์ฟีดที่ตัวเองสร้างกับผู้ใช้อื่นได้
  • ตัวอย่างฟีด:
    • Quiet Posters: แสดงโพสต์จากคนที่ไม่ได้โพสต์บ่อย
    • the ‘Gram: แสดงเฉพาะโพสต์ที่มีรูปภาพแนบ
    • My Bangers: แสดงโพสต์ยอดนิยมของตัวเอง
  • จุดแข็งอย่างหนึ่งของ BlueSky คือผู้ใช้สามารถสร้าง อัลกอริทึมฟีด ของตัวเองและแชร์ได้อย่างง่ายดาย
  • ฟีดเป็นฟีเจอร์ที่ถูกเพิ่มเข้ามาใน atproto ค่อนข้างไม่นาน จึงอาจยังไม่สมบูรณ์และอาจเปลี่ยนแปลงได้ในอนาคต

Labeler และการกลั่นกรองระดับเครือข่าย

  • Labeler คือบริการที่ติด label ให้กับคอนเทนต์หรือบัญชี
  • ผู้ใช้สามารถติดตาม labeler บางตัวและทำให้ประสบการณ์การใช้งานเปลี่ยนไปตาม label ของโพสต์ได้
  • labeler สามารถทำงานได้ตามที่ผู้ดูแลต้องการ
    • รันอัลกอริทึมอัตโนมัติกับโพสต์ได้
    • ให้มนุษย์อนุมัติหรือปฏิเสธโดยตรงได้
    • ใช้เป็น blocklist หรือฟิลเตอร์ NSFW ได้
  • แม้จะมีฟังก์ชัน label อยู่แล้ว แต่ ณ เวลาที่เขียนยังไม่ชัดเจนว่าผู้ใช้จะรัน labeler เองได้หรือไม่
    • BlueSky รัน labeler ของตัวเอง
    • ยังไม่ทราบการปล่อยใช้งานภายนอก
  • เมื่อผสาน feed, App View และ labeler เข้าด้วยกัน ผู้ใช้จะสามารถเลือก ประสบการณ์การกลั่นกรอง ได้ทั้งในและนอกแอป
    • ในฟีดหนึ่งอาจดูเฉพาะ SFW และอีกที่หนึ่งอาจอนุญาตคอนเทนต์ NSFW
    • สามารถสร้างและแชร์ blocklist ได้
  • เนื่องจากเครื่องมือกลั่นกรองทำงานในระดับ โปรโตคอล ไม่ใช่ระดับแอป จึงสามารถใช้ labeler เดียวกันกับแอปอื่นบน atproto ได้ด้วย
    • หากมีการสร้าง Instagram clone บน atproto ก็สามารถใช้ labeler แบบ blocklist เดียวกันได้
    • หากต้องการบล็อกผู้ใช้ที่ถูกบล็อกในที่หนึ่งให้ถูกบล็อกทุกที่ก็ทำได้

ความต่างจากโมเดลอินสแตนซ์แบบ Mastodon

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

DID, handle และการย้ายบัญชี

  • แกนกลางของตัวตนใน atproto คือ DID(Decentralized Identifier)
    • ตัวอย่าง DID มีรูปแบบ did:plc:3danwc67lo7obz2fmdg6jxcr
  • ตัวตนที่ผู้ใช้เห็นจริงจะใช้ handle ร่วมด้วย โดย handle คือชื่อโดเมน
    • เช่น @steveklabnik.com
    • ผู้สมัครใช้ BlueSky สามารถรับ handle ในรูปแบบ @username.bsky.social ได้
  • เนื่องจาก DID มีความเสถียร แม้จะเปลี่ยน handle จาก @steveklabnik.bsky.social เป็น @steveklabnik.com ก็ไม่กระทบผู้ติดตาม และใน UI จะเปลี่ยนแค่ handle เท่านั้น
  • หากต้องการใช้โดเมนเป็น handle จะต้องนำ DID ที่ PDS สร้างขึ้นไปเพิ่มเป็น TXT record ใน DNS ของโดเมนนั้น
  • แม้ผู้ใช้ที่ไม่รู้จัก DNS ก็ยังสามารถจดโดเมนและตั้งเป็น handle ได้โดยไม่ต้องมีความรู้เชิงเทคนิค ผ่านความร่วมมือของ BlueSky กับ NameCheap
  • ความสามารถในการย้ายบัญชีอิงกับ DID และลายเซ็นเข้ารหัส
    • คอนเทนต์ที่สร้างโดยผู้ใช้ DID ใด DID หนึ่งจะถูกลงลายเซ็นและทำสำเนาไปทั่วเครือข่าย
    • หากจะ “ปิดบัญชี” จำเป็นต้องบังคับไม่ให้ผู้ใช้ใช้กุญแจที่ตนถืออยู่ ซึ่งตามการออกแบบเครือข่าย ฝ่ายอื่นไม่สามารถเข้าถึงกุญแจนั้นได้
    • แม้ PDS จะล่ม ก็ยังสามารถ backfill เนื้อหาจากเครือข่ายและแจ้งว่ามีการย้ายไปยัง PDS ใหม่ได้

ประเด็นของ did:web และ did:plc

  • BlueSky รองรับ DID สองแบบ
    • did:web: วิธีที่อิงชื่อโดเมน
    • did:plc: วิธีเฉพาะที่ BlueSky พัฒนาขึ้นเอง
  • did:plc ในที่นี้ plc หมายถึง “placeholder” และ BlueSky มีแผนจะรองรับมันต่อไป
  • did:plc มีจุดอ่อนตรงที่ต้องอาศัยบริการที่ BlueSky เป็นผู้ดำเนินการเพื่อแปลความข้อมูลให้ถูกต้อง
    • ตัวอย่างการค้นหาดูได้ที่ plc.directory
    • ด้วยโครงสร้างนี้จึงมีเสียงวิจารณ์ว่า BlueSky อาจแบนผู้ใช้ได้เข้มข้นกว่าที่การออกแบบเครือข่ายเปิดโอกาสไว้แต่เดิม
  • อย่างไรก็ดี ก็มีเหตุผลที่มองว่าปัญหานี้ยังไม่ถึงขั้นร้ายแรง
    • หากไม่ต้องการก็ใช้ did:web ได้
    • ระบบถูกออกแบบให้ย้ายได้หากมีระบบที่ดีกว่าเกิดขึ้น
    • ในอนาคตอาจย้าย governance ของ did:plc ไปสู่โมเดลฉันทามติ
    • องค์กรอื่นอาจเปิดบริการ did:plc ของตนเองและให้ผู้ใช้เลือกใช้ได้

วิธีที่ BlueSky อยู่บน atproto

  • BlueSky คือแอปพลิเคชันที่สร้างอยู่บนเครือข่าย atproto
  • BlueSky รัน App View และ เว็บแอปพลิเคชัน ที่ใช้งาน App View นี้
  • นอกจากนี้ยังรัน PDS สำหรับผู้ใช้ที่สมัครผ่านเว็บแอป รวมถึงรัน Relay ที่ให้ PDS เหล่านั้นสื่อสารกัน
  • BlueSky ออก Lexicon อยู่สองประเภท
    • com.atproto.*: งานระดับล่างที่จำเป็นต่อแอปใด ๆ บนเครือข่าย
    • app.bsky.*: งานที่เฉพาะเจาะจงกับ BlueSky
  • เป้าหมายของผลิตภัณฑ์ BlueSky คือทำให้ผู้ใช้ใช้งานได้โดยไม่ต้องรู้รายละเอียดทางเทคนิคเหล่านี้
    • เพราะไม่มีอินสแตนซ์ จึงไม่มีขั้นตอนให้เลือกอินสแตนซ์เพื่อสร้างบัญชี
    • แม้โฮสต์จะล่มก็ย้ายได้ และผู้ติดตามไม่จำเป็นต้องรับรู้เรื่องนี้

การสร้างแอปใหม่บน atproto

  • แอปบน atproto เริ่มต้นจากการสร้าง Lexicon
  • หลังจากนั้นจึงรัน App View ที่ประมวลผลข้อมูลในเครือข่ายซึ่งเกี่ยวข้องกับ Lexicon นั้น
  • แอปจะต้องเปิดทางให้ผู้ใช้สามารถเขียนข้อมูลลงใน PDS ของตัวเองโดยใช้ Lexicon ดังกล่าวได้

การแยกส่วนสำคัญในเชิงออกแบบ

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

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

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

 
GN⁺ 2024-02-26
ความคิดเห็นจาก Hacker News

  • ดูเหมือนออกแบบมาได้ดีมาก และน่าจะช่วยแก้ ปัญหาใหญ่ ๆ ของ ActivityPub ได้บางส่วน
    เมื่อก่อนผมไม่ได้สนใจ Bluesky เท่าไร แต่ตอนนี้เริ่มคิดว่าจะลองสร้างบัญชีดู

    • ปัญหาหลักของ Bluesky และ AT Protocol อยู่ที่ท่าทีแบบ NIH (Not invented here) ที่แรง มากกว่าข้อดีทางเทคนิค
      แทนที่จะใช้โปรโตคอลเดิมที่ทุกคนใช้กันอยู่แล้วอย่าง user@host และ WebFinger กลับเลือก “ใช้โดเมนเป็นตัวตน” และไม่ได้อ้างอิงวิธีที่ ACME จัดการไว้แล้วในเรื่องใบรับรอง จนเกิดกรณีมีคนเอาโดเมน s3.amazon.com ไปใช้บน Bluesky https://www.reddit.com/r/programming/comments/138hlf2/s3_dom...
      นอกจากนี้ยังสร้างโปรโตคอลเรียกใช้งานระยะไกลใหม่ชื่อ XRPC และใช้สคีมาข้อมูลแบบสร้างโค้ดชื่อ Lexicon ซึ่งข้อดีเมื่อเทียบกับ protobuf หรือ jsonld ก็ยังไม่ชัด นอกจากความใหม่
      เป็นเรื่องยากที่จะเชื่อถือ “เครือข่ายเปิด” ที่ดูเหมือนไม่ยอมเคารพหรือพูดคุยกับระบบนิเวศอื่น ๆ อยู่เรื่อย ๆ และก็น่าสงสัยด้วยว่าการปฏิเสธองค์ความรู้ร่วมกันแบบนี้ทำให้มีข้อผิดพลาดพื้น ๆ ในการออกแบบแทรกเข้ามาอีกมากแค่ไหน
    • AT Protocol ดูดีกว่าในเชิงเทคนิค แต่ในเชิงสังคมดูเหมือนเป็นโครงสร้างที่ล้มเหลวได้ง่าย
      ไม่มีแรงจูงใจทางสังคมให้ใครมาติดตั้งและดูแลรีเลย์กับบริการม็อดเดอเรชันที่แยกออกจากคอมมูนิตี้จริง สิ่งที่เหลืออยู่จึงมีแต่แรงจูงใจทางการเงิน เช่น บริการแบบเสียเงิน การแทรกโฆษณา การขุดข้อมูล และการบิดเบือนข้อมูล
      เมื่อการกระจายข้อมูลและการม็อดเดอเรชันถูกรวมศูนย์ ทั้งต้นทุนโฮสติ้งและต้นทุนบุคลากรก็จะกลายเป็นธุรกิจขนาดใหญ่ และในทางปฏิบัติจะมุ่งไปในทางที่ขัดขวางไม่ให้คนอื่นนอกจาก Bluesky ดำเนินรีเลย์หรือบริการม็อดเดอเรชันของตัวเอง
      แม้ ActivityPub จะมีข้อเสีย แต่แนวทางอย่าง “คอมมูนิตี้ที่มีประตู” ทำให้ผู้ใช้รู้สึกผูกพันกับเซิร์ฟเวอร์ และทำให้ผู้ดูแลระบบกับม็อดเดอเรเตอร์ภูมิใจที่ได้ให้บริการแก่ผู้ใช้
      AT Protocol อนุญาตให้มีรีเลย์และบริการม็อดเดอเรชันหลายรายในเชิงเทคนิค แต่ในโลกจริงจะเกิดขึ้นมากแค่ไหนยังน่าสงสัย
      ผมคิดว่าเป็นความผิดพลาดที่จะตัดสินโปรโตคอลโซเชียลเน็ตเวิร์กจากมุมมองเชิงเทคนิคและเชิงปรปักษ์ล้วน ๆ การไม่ผูกติดกับเซิร์ฟเวอร์แลกมากับการถูกแยกออกจากคอมมูนิตี้ที่แน่นแฟ้นด้วย และไม่มีอะไรที่ทำให้รู้สึกมีส่วนได้ส่วนเสียอีกต่อไป
      การไม่มีอะไรให้เสียในแง่ข้อมูล ตัวตน และคอมมูนิตี้เป็น ดาบสองคม

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

    • เมื่อก่อน Bluesky ทำให้ผมสับสนพอสมควร แต่ไม่นานมานี้ผมเพิ่งรู้ว่าส่วนใหญ่สับสนเพราะ คำศัพท์
      ถ้าเรียกระบบว่า [ไมโครบล็อก] -> [อินเด็กเซอร์] -> [ไคลเอนต์] จะเข้าใจง่ายกว่า
      ในความเป็นจริงมีองค์ประกอบมากกว่านี้ แต่กลไกพื้นฐานของ Bluesky คร่าว ๆ เป็นแบบนี้ และดูเหมือนแค่ตั้งชื่อไม่ตรงกับที่คาดไว้
      เหตุผลที่ต้องมีอินเด็กเซอร์คือ ID ผู้ใช้ไม่ได้คงที่อยู่ในระบบ DID:PLC เริ่มต้นด้วยสตริงย่อยของแฮช แล้วเพราะ “การหมุนเวียนคีย์” จึงเกิดการจัดวางใหม่เชิงเข้ารหัสแบบแปลก ๆ ที่ทำให้ ID ผู้ใช้เปลี่ยนไปตามเวลาโดยที่แม้แต่เจ้าตัวก็ไม่รู้ตัว
      ลองนึกถึงระบบแบบ LiveJournal แต่ handle เปลี่ยนไปเรื่อย ๆ และต้องมีผู้มีอำนาจในการติดตามการเปลี่ยนแปลงนั้น แน่นอนว่าสามารถโพสต์ได้แค่ข้อความสั้น ๆ โดยไม่มีหัวข้อหรือการรองรับ Markdown
      โดยส่วนตัวผมกำลังรอ DID:PLC แบบใหม่ที่รับ public key แบบคงที่และให้เซ็นข้อความด้วย private key สิ่งที่ต้องติดตามจะลดลงมาก และการโฮสต์เองกับการพัฒนาแบบ local-first ก็น่าจะง่ายขึ้นมาก
    • ถ้าจำเป็น ผมคิดว่าไคลเอนต์อย่าง App View น่าจะใช้รีเลย์หลายตัวพร้อมกันแบบขนานได้
      เป็นโครงสร้างคล้าย UI GitHub แบบโลคัลที่ดึงข้อมูลจากอินสแตนซ์ GitHub หลายตัว ซึ่งโฮสต์ชุด repository ที่ต่างกันแต่ก็อาจซ้อนทับกัน
      คล้ายกับไคลเอนต์ Usenet ที่รวบรวม newsgroup จากเซิร์ฟเวอร์ NNTP หลายตัวมาแสดงด้วย
    • ผมคาดว่ารีเลย์ทั้งหมดน่าจะเป็นโครงสร้างที่มี ข้อมูลครบทั้งหมด ยกเว้นความเห็นต่างเรื่องการตัดสินเนื้อหาผิดกฎหมาย
      เลยสงสัยว่าทำไมถึงคิดว่าแต่ละรีเลย์จะมองเห็นเครือข่ายต่างกัน

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

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

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

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

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

    • คนที่โฮสต์เนื้อหาต้องจัดการ ผลทางกฎหมาย ของเนื้อหาที่ตัวเองโฮสต์ และสุดท้ายก็เลี่ยงไม่ได้
      แต่ไม่ว่าจะใช้โปรโตคอลไหน เรื่องนี้ก็เหมือนกัน
    • ไม่ได้เข้าใจผิดหรอก ผมมองว่าการกระจายศูนย์ของ Bluesky แทบจะเป็นของปลอม
      PDS ใช้แค่เครื่อง Ubuntu พอประมาณก็ได้ แต่แม้แต่บทความนี้ก็ยังยอมรับว่า relay มีราคาแพงและเป็น จุดควบคุมแบบรวมศูนย์ ขนาดใหญ่
      แผนรับมือสแปมของ Bluesky คืออะไร? ก็คงเป็นการบล็อกที่ relay
      เซิร์ฟเวอร์ DID ก็เป็นจุดควบคุมแบบรวมศูนย์อีกจุดหนึ่ง
      ถึงอย่างนั้น PDS ก็ยังรันได้ตามใจชอบ

  • เกร็ดน่าสนใจเกี่ยวกับ Bluesky ถ้าเชื่อมโยงกับบทความเมื่อไม่นานมานี้ นี่ก็ถือว่าตั้งชื่อตามชื่อคนได้เหมือนกัน
    ชื่อของ CEO ในภาษาจีนแปลตรงตัวว่า blue sky

    • ที่น่าสนใจคือ Twitter ตั้งชื่อโปรเจกต์ว่า bluesky ไว้แล้วก่อนที่ผมจะเข้าร่วม
      เป็นเรื่องบังเอิญ แต่ชื่อกลางของผมในภาษาจีนมีความหมายว่า bluesky

  • การ์ตูนสั้นเรื่องนี้ก็ดี: https://bsky.social/about/welcome-to-bluesky-comic

  • ถ้า Bluesky เลิกสนับสนุน did:plc แล้ว ตัวตน PLC เดิมทั้งหมดจะพังหมดหรือเปล่า?
    สงสัยเพราะ PLC มีโครงสร้างที่ ping ไปยังบริการฝั่งนั้น

    • https://plc.directory สามารถทำ mirror ได้ และถ้าเกิดเรื่องแบบนั้น mirror ใหม่ก็สามารถกลายเป็น เซิร์ฟเวอร์ที่มีอำนาจอ้างอิง ได้

  • ผมยังไม่ค่อยเชื่อเรื่อง labeler จากบุคคลที่สาม
    จะป้องกันการนำไปใช้ในทางที่ผิดได้อย่างไร?

    • ผู้ใช้เลือกเองว่าจะสมัครรับ labeler บุคคลที่สาม รายใด
      ถ้าบริการ labeler เริ่มใช้อำนาจในทางที่ผิด ผู้ใช้ก็ตัดการใช้งานได้
      มีคำอธิบายละเอียดว่า Bluesky ตั้งใจจะทำให้ labeler เข้ากับระบบนิเวศอย่างไรที่ https://github.com/bluesky-social/proposals/tree/main/0002-l...
    • คำตอบขึ้นอยู่กับว่าหมายถึงการใช้ในทางที่ผิดแบบไหน
      ผมแสดงความเห็นได้ แต่คำถามกว้างเกินไปจนไม่รู้ว่าจะเริ่มตอบจากตรงไหน
    • เร็ว ๆ นี้จะเปิดเผยเรื่องมอดเดอเรชันมากกว่านี้อีกมาก แต่พื้นฐานของ labeler เป็นแบบนี้
      ใครก็ตามในเครือข่ายสามารถติด label ให้กับอะไรก็ได้ รวมถึง labeler อื่น ๆ
      แอปสามารถแสดง labeler ให้ผู้ใช้สมัครรับได้ เหมือนฟีดแบบปรับแต่งเองของ Bluesky ในตอนนี้
      แอปยังสามารถคัดสรรและจัดอันดับวิธีที่ labeler ถูกแสดงและถูกจัดอันดับได้ เช่นเดียวกับที่ตอนนี้แสดงและจัดอันดับฟีดแบบปรับแต่งเองตามความนิยมที่แสดงผ่านการกดไลก์และการบันทึก

  • แนวทางที่ว่า “เครื่องมือมอดरेशनอยู่ในชั้นของการเข้าถึง (reach) คือรับคำพูดทั้งหมดเข้ามา แต่ให้วิธีจำกัดการเข้าถึงของสิ่งที่ฉันไม่อยากเห็น” สุดท้ายก็ดูเหมือนการมอดरेशनแบบ “ถ้าไม่อยากเห็นก็หลับตาไป”
    ผมรู้ว่านี่เป็นปรัชญาที่ Silicon Valley ชอบ แต่โดยพื้นฐานแล้วผมมองว่ามีข้อบกพร่อง
    มีสถานการณ์ที่ชอบธรรมซึ่งจำเป็นต้องป้องกันไม่ให้คนอื่นที่ไม่เกี่ยวข้องพูดถึงประเด็นบางอย่าง หรือไม่ให้เข้าถึงคอนเทนต์บางประเภท
    ตัวอย่างคลาสสิกคือ การกลั่นแกล้งทางไซเบอร์, การขุดข้อมูลส่วนตัวมาเปิดเผย และรีเวนจ์พอร์น เช่น คนตั้งแต่สองคนขึ้นไปคุยกันถึงวิธีทำร้ายบุคคลที่สาม หรือเปิดเผยข้อมูลที่เป็นส่วนตัว น่าอับอาย หรือเป็นเท็จ
    การลบข้อมูลนี้ออกจากฟีดของเหยื่อไม่มีประโยชน์เลย และตั้งแต่แรกมันก็มีแนวโน้มว่าจะไม่ปรากฏในฟีดของเหยื่ออยู่แล้ว ความเสียหายเกิดจากการที่คนอื่นเห็นคอนเทนต์นั้นหรือเข้าร่วมการสนทนา แต่ความเสียหายนั้นเป็นเรื่องจริง
    ในระบบมอดरेशनแบบดั้งเดิม ผู้ดูแลสามารถลบโพสต์ออกจากทุกคนหรือบล็อกผู้กระทำผิดเพื่อหยุดพฤติกรรมแบบนี้ได้ ในระบบที่ “แค่ซ่อนคอนเทนต์” ทำแบบนี้ไม่ได้
    รายการบล็อกที่แชร์กันหรือ “ป้ายกำกับ” ก็ใช้ไม่ได้เช่นกัน ผู้บริโภคคอนเทนต์ไม่มีแรงจูงใจที่จะบล็อกสิ่งนั้น และอาจอยากดูรีเวนจ์พอร์นด้วยซ้ำ
    คนที่อยากบล็อกคือเหยื่อ แต่เหยื่อไม่มีอำนาจบังคับให้ทุกคนใช้รายการบล็อกเฉพาะได้ เพราะแก่นของระบบนี้คือไม่มีใครสามารถบังคับรายการบล็อกให้คนอื่นใช้ได้

    • ในพื้นที่นี้ยังมีเรื่องที่จะตามมาอีก บทความนี้เน้นกรณีปกติ และไม่ได้กล่าวถึงกรณีเลวร้าย
      ทีมได้พิจารณาปัญหาเหล่านี้และ “ปรึกษาผู้เชี่ยวชาญ” แล้ว แต่ยังเป็นงานที่กำลังดำเนินอยู่ ผมจึงไม่รู้สึกว่าตัวเองมีคุณสมบัติพอจะพูดแทนได้
      ประเด็นที่ว่า “ป้ายกำกับใช้ไม่ได้ เพราะผู้คนอยากดูมันมากกว่าจะป้องกันมัน” เป็นส่วนหนึ่งของพื้นที่ปัญหาที่ทีมยอมรับไว้อย่างชัดเจน
      ดูเพิ่มเติมได้ที่นี่: https://lobste.rs/s/shseqz/how_does_bluesky_work#c_vjvmei