การใช้ระบบคอมเมนต์ Bluesky กับบล็อกของฉัน

 (natalie.sh)
1 คะแนน โดย GN⁺ 2025-08-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ระบบคอมเมนต์เดิม (Disqus, โฮสต์เอง, GitHub Issues ฯลฯ) มีปัญหาเรื่องความเร็ว, การติดตาม, ภาระการบำรุงรักษา และข้อจำกัดของผู้ใช้ จึงไม่เลือกใช้
  • Bluesky เป็นตัวเลือกที่เหมาะกับคอมเมนต์ในบล็อก เพราะ ไม่ต้องดูแลโครงสร้างพื้นฐาน รองรับเนื้อหาหนาแน่น, บัญชีเชิงตัวตน, และ การสนทนาข้ามแพลตฟอร์ม
  • วิธีการทำงานคือ โพสต์บทความบนบล็อก → แชร์ไปยัง Bluesky → เพิ่ม AT URI ใน metadata ของโพสต์บล็อก → โหลด thread ความคิดเห็นของโพสต์นั้นและแสดงผล
  • แบ่งคอมโพเนนต์เป็น 3 ส่วน: แสดงคอมเมนต์ทั้งหมด, แสดงคอมเมนต์ + คอมเมนต์ย่อยรายตัว, และการประมวลผลการฝังเนื้อหา เช่น รูปภาพและลิงก์
  • ใช้การเรนเดอร์แบบ recursive เพื่อแสดงคอมเมนต์ย่อยสูงสุด 5 ระดับ รองรับกริดภาพและมอดัล, การ์ดลิงก์, และเมื่อเป็นการฝังที่ไม่รองรับจะแสดงข้อความแทน
  • ผสาน Astro + React และโหลดฝั่งไคลเอนต์ผ่าน client:load โดยเพิ่ม DID และ postCid ใน frontmatter เพื่อเปิดใช้งานคอมเมนต์
  • ใช้ TypeScript types ของ @atcute/client เพื่อความเสถียรของประเภท และยังคงแสดงเนื้อหาได้ตามปกติแม้ปิด JavaScript ในโครงสร้าง Progressive Enhancement
  • ใช้ Bluesky API และ CDN โดยไม่ต้องมีเซิร์ฟเวอร์หรือฐานข้อมูล ทำให้ได้ประสิทธิภาพดีขึ้น
  • แนวทางนี้หลีกเลี่ยงการสร้างฟังก์ชันโซเชียลใหม่ในแต่ละไซต์ โดยเชื่อมต่อผู้ใช้กับแพลตฟอร์มที่เขาใช้อยู่แล้ว ทำให้ยืดหยุ่นและเป็นอิสระมากขึ้น

เหตุผลที่เลือก Bluesky เป็นระบบคอมเมนต์

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

ทำความเข้าใจ AT Protocol

  • DID: ตัวระบุผู้ใช้แบบกระจายอำนาจ
  • CID: ตัวระบุเนื้อหา
  • AT URI: รูปแบบที่อยู่ at://did:.../app.bsky.feed.post/...
  • สามารถดึง thread คอมเมนต์ผ่านการเรียก API getPostThread โดยไม่ต้องยืนยันตัวตน

โครงสร้างคอมโพเนนต์

  • คอมโพเนนต์คอมเมนต์หลัก
  • คอมโพเนนต์แสดงคอมเมนต์และคอมเมนต์ย่อยรายชิ้น
  • คอมโพเนนต์จัดการเนื้อหาที่ฝังแบบรูปภาพ ลิงก์ ฯลฯ

การประมวลผลคอมเมนต์ซ้อน

  • เรนเดอร์แบบ recursive และจำกัดความลึกสูงสุดที่ 5 ระดับ
  • ใช้การเยื้องแบบสายตาเพื่อแสดงลำดับชั้น

การจัดการ rich content

  • รูปภาพ: ใช้ CDN, จัดแสดงหลายรูปแบบ grid และ modal view
  • ลิงก์ภายนอก: เรนเดอร์การ์ดพร้อม thumbnail และคำอธิบาย
  • การฝังประเภทอื่น: แสดงข้อความสำรองแทน

การผสานกับ Astro

  • ใช้ React components + client:load
  • เพิ่ม Bluesky DID และ postCid ใน frontmatter เพื่อเปิดคอมเมนต์

ประสบการณ์ในการพัฒนา

  • ใช้ TypeScript type เพิ่มเสถียรภาพ
  • ด้วย Progressive Enhancement บทความยังคงแสดงได้ปกติแม้ API ล่ม
  • ใช้โครงสร้างพื้นฐานของ Bluesky โดยไม่ก่อภาระให้เซิร์ฟเวอร์/ฐานข้อมูล

บทสรุป

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

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

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

 
GN⁺ 2025-08-08
ความคิดเห็นจาก Hacker News

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

  • บทความนี้น่าสนใจมาก ผมชอบอ่านขั้นตอนที่คนอื่นๆ สร้างและดูแลเว็บไซต์ของตัวเองแบบอิสระ ในบทความพูดถึงปัญหาระบบคอมเมนต์และทางเลือกสี่ทาง แต่ผมอยากเสริมว่า วิธีที่ห้าก็ใช้ได้ผลด้วย หลังจากลองใช้ระบบคอมเมนต์ของ third-party หลายตัว ผมจึงสร้างระบบคอมเมนต์แบบง่ายๆ ของตัวเอง (form.lisp) มาใช้ แต่ละคอมเมนต์เก็บเป็นไฟล์ข้อความ ทำให้ไม่ต้องกังวลเรื่องสแปม XSS หรือคอมเมนต์ไร้ความหมาย และผมก็คอยตรวจเช็กด้วยตัวเองทุกสุดสัปดาห์ก่อนเพิ่มเข้าโพสต์ ความคิดเห็นเก็บเป็นไฟล์ HTML ธรรมดา และ static site generator (site.lisp) ก็สร้างหน้าคอมเมนต์ (ตัวอย่างความคิดเห็น) ให้พร้อมกับเนื้อหาบทความ กล่าวคือโดยหลักการเป็นระบบสร้างคอมเมนต์แบบสถิตย์ ข้อสมบัติห้าข้อที่บทความกล่าวถึง (ไม่ต้องมี infrastructure เพิ่มเติม, rich content, ชื่อจริง ฯลฯ) แม้ไม่ตรงกับทุกข้อของผม แต่ใช้ได้ดีและพอใจกับการใช้งานมากว่า 4 ปีแล้ว

    • วิธีรับคอมเมนต์ผ่านฟอร์มอีเมลแล้วให้ผู้ดูแลเพิ่มเองที่ท้ายโพสต์ก็ถือว่าโอเค

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

    • ให้ความรู้สึกคล้ายกับการรับ ‘บทความจากผู้อ่าน’ แบบในหนังสือพิมพ์

  • คำแนะนำของผมคือ cactus.chat ซึ่งเป็น Matrix-based และรองรับ guest ได้ จึงไม่ต้องมีบัญชี Matrix ก็เขียนคอมเมนต์ได้ หากใช้บัญชีตัวเองก็เข้าร่วม Matrix room ของแต่ละโพสต์

  • Bluesky ใช้ประโยชน์ด้านการเก็บข้อมูลบนบัญชีผู้ใช้เดิมได้ดีมาก ตอนนี้มีการพัฒนารีวิวย่อยของเว็บแมปโอเพ่นซอร์สบน cartes.app ที่อิง Bluesky ไม่ง่ายนัก ต้องสร้าง lexicon และคอยดูแล DB ต่อเนื่องตาม Bluesky stream

    • จริงๆ แล้วบางช่วงสามารถไปได้โดยไม่พึ่ง DB เลย ที่ scrapboard.org ที่ผมเคยทำ ใช้ได้ด้วย getRecord API เท่านั้น (เอกสาร) ก็สามารถอ่านข้อมูลฝั่งไคลเอนต์ได้เยอะพอสมควร

    • มีข้อเสนอให้ใช้ mangrove.reviews แทน โดยบริการนี้ใช้ CC-BY-SA ชัดเจน และ MapComplete.org ก็ใช้เช่นกัน Bluesky ก็มีโอกาสเจอปัญหาได้เหมือนกัน

  • ผมยังไม่แน่ใจในความยั่งยืนของโมเดลรายได้ Bluesky ตอนนี้ที่ใช้งานฟรีได้เกือบทั้งหมดก็เพราะเงินจาก VC (venture capital) จึงระวังมาก และกังวลว่าจะมีโอกาสในไม่กี่ปีข้างหน้า API ปิดหรือระบบคอมเมนต์พัง

    • Bluesky ทำงานตามสถาปัตยกรรมใต้ Personal Data Server (PDS) ของผู้ใช้ ทุกคนสามารถสลับ PDS ได้ และเซิร์ฟเวอร์แอปทางการของ Bluesky เป็นแค่ตัวรวบรวมข้อมูล app server, app view ที่ทำโดยบุคคลที่สามก็เข้าถึงข้อมูลชุดเดียวกันได้เหมือนกัน ไม่จำเป็นต้องพึ่ง API อย่างเดียว ความเปิดกว้างจึงสูงมาก

    • ผมเชื่อแนวคิด POSSE ค่อนข้างมาก ด้านบวกของ “วัฏจักร enshittification” คือได้เข้าใช้ชุมชนออนไลน์ที่น่ารื่นรมย์สักระยะ แล้วจึงย้ายไปที่ใหม่ได้อีกที เหมือนสโมสรดีๆ ในอดีตที่หายไป เหมือนกันก็คิดว่าไม่ควรยึดติด โดยมีลิงก์สรุปความคิดผมใน Mastodon ด้วย คำอธิบายทฤษฎี

    • Bluesky คงจะต้องหันมาหาโมเดลรายได้เมื่อไหร่สักวัน แต่ AI และบริการอื่นๆ ก็ดำเนินตามโครงสร้าง VC เช่นกัน เช่น Twitter, Uber, Doordash อย่างอื่นก็เป็นแบบนั้นเหมือนกัน ตอนที่ VC ทุ่มเงินตามความฝันความร่ำรวยใหม่ๆ ก็ยังสนุกที่ได้ใช้ช่วงความอุดมสมบูรณ์นั้นไปก่อน แม้สุดท้ายบรรยากาศอาจเสื่อมลง

  • ผมมองว่า ecosystem ของ Bluesky สุดเจ๋งนะ เคยเห็นเคสแบบนี้มาแล้ว ข้อจำกัดหนึ่งคือ ต้องโพสต์แยกบน Bluesky ต่อหน้าเว็บแต่ละหน้าเพื่อให้ระบบคอมเมนต์ทำงานได้ ถ้ามี webcomponent ก็คงดีกว่า

  • ในบทความมีประโยคว่า “ตั้งใจติดคอมเมนต์ในบล็อกมานานแต่ทำไม่ได้” แต่ในบล็อกทั้งหมดของผมเห็นโพสต์ปี 2025 แค่สองโพสต์เท่านั้น (หนึ่งในนั้นคือโพสต์นี้)

    • เดิมเคยมีบล็อกอื่นๆ และพบหลักฐานผ่าน archive.org

  • รูปแบบที่ไม่ต้องเผชิญหน้า social media feed โดยตรง แต่ยังโต้ตอบกับโซเชียลได้แบบนี้น่าสนใจ ผมอยากติดฟีเจอร์นี้ที่บล็อก เพื่อให้ผู้คนคอมเมนต์ได้ตรงนั้น และผมอาจใช้เฉพาะอินเทอร์เฟซนี้ในการคุยกับ Bluesky หรือโซเชียลอื่นๆ ก็พอ เปิดฟีดแล้วมักจบที่ doomscrolling หรือเสียเวลาแบบน่าหดหู่แบบเดิมๆ วิธีนี้ทำให้เลี่ยงวงจรนั้นได้ และยังคงเชื่อมกับโซเชียลได้แบบใหม่

    • เห็นด้วยกับความคิดที่ว่า “เปิดฟีดแล้วเจอแต่ข้อมูลไร้ความหมาย” แต่ก็นึกว่ามันอาจไม่ใช่จุดประสงค์การออกแบบดั้งเดิม

  • Bluesky ทำให้รู้สึกว่ามีพื้นที่ให้แนวคิดใหม่ๆ โผล่บนอินเทอร์เน็ตได้อีกครั้ง

    • ในทางปฏิบัติอาจเป็นเหมือนเพิ่มตัวเลือก integration สำหรับ Threads มากกว่า และคำว่า “open innovation” น่าจะเหมาะกับ ATProto กว่า

    • ผมไม่ได้อยากยกย่ององค์กรเดียวหรือนิยามกลุ่มเดียวมากเกินไป แต่ตอนนี้คอมมูนิตี้ Bluesky ยังสนุก ชอบพวกเดิมจาก Twitter อยู่เยอะ และฐานผู้ใช้หลักก็ดูจะเป็นคนกลุ่มเดียวกันมาก บวกลูกค้าข้างหน้าไว้รอดู

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

    • ถ้าคนดูแล Bluesky หรือบางกลุ่มผู้ใช้ถูกยั่วยุจนมีคน report บัญชี อาจถูกแบนทันที หรือเข้ารายชื่อดำล่วงหน้า ก็หายไปก่อนพูดอะไรได้ เหมือนความพยายามสร้างสภาพแวดล้อมที่เข้มงวดกว่า Twitter เก่าๆ และคล้ายเกมอำนาจในโรงอาหารมัธยม

  • การโฮสต์นอกบล็อกตัวเองแล้วพึ่ง Bluesky อยู่ก็คือสุดท้ายให้ Bluesky ดูแลอยู่แล้ว พูดว่าปลอด lock-in ของแพลตฟอร์ม แต่ถ้าพรุ่งนี้ Bluesky แบนบัญชีผมหรือบริษัทล้ม จะทำอย่างไรต่อ อาจย้ายไปใช้ AT-compatible product ได้ แต่ก็ยังมีความกังวลเรื่องข้อมูลหาย

    • ถ้าสนใจประเด็นนี้ ลองดูข้อมูล/เครื่องมือจริงๆ ที่รวบรวมบน Bluesky และ AT Proto เรื่องเครือข่ายรีเลย์, การย้ายข้อมูล, ความเป็น portable และเครือข่ายรีเลย์สำรองได้ที่ https://whtwnd.com/bnewbold.net มีความก้าวหน้าและ ลิงก์ที่เกี่ยวข้อง ให้ตามต่อได้อีก (ผู้เขียนบล็อกนั้นเป็นพนักงาน Bluesky ส่วนผมไม่เกี่ยว)

    • ข้อมูลส่วนตัวแบ็คอัปบน IPFS ได้เป็นไฟล์ CAR (แบบ tarball) และภายหลังก็ restore ผ่านเอกสาร did:plc ของบัญชีหรือ DNS เพื่อกลับสู่ PDS ใดก็ได้ ถ้า PDS ปัจจุบันล่มหรือถูกบล็อก ก็ย้ายเซิร์ฟเวอร์ได้ทันที มี relay (gossip node), PDS, client, app view (backend ของเว็บแอป Bluesky) และผู้ให้บริการโฮสต์แบบโอเพ่นซอร์สต่างๆ อยู่แล้ว ถ้า Bluesky พังพรุ่งนี้ เราก็ยัง self-host เองได้ หรือใช้ผู้ให้บริการอื่นอย่าง zeppelin.social เพื่อคง App เดิมไว้ได้ PLC directory ยังอยู่ในความดูแลของ Bluesky แต่มันกำลังย้ายไปยังมูลนิธิอิสระ และสามารถทำสำเนาได้ง่าย หากใช้ did:web ก็พึ่งระบบ DNS เท่านั้น ความเป็นอิสระจึงสูงขึ้น

    • Bluesky กำลังผลักดันให้ผู้ใช้แนว libertarian หรือขวาจัดออกไปชัดเจน แต่ผู้ใช้ซ้ายหรือผู้ที่ไม่ใส่ใจการเมืองกลับดูโอเคมากกว่า