Nostr

 (nostr.com)
1 คะแนน โดย GN⁺ 2025-09-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Nostr คือ โปรโตคอลการสื่อสาร แบบเปิดที่ตัดการควบคุมจากศูนย์กลางออกไป เป็นสถาปัตยกรรมที่ออกแบบมาเพื่อให้ข้อมูลไหลเวียนได้อย่างอิสระผ่านการผสมผสานระหว่างไคลเอนต์และรีเลย์ที่หลากหลาย
  • ผู้ใช้ยืนยันตัวตนและความถูกต้องของข้อความด้วย คีย์ส่วนตัวและลายเซ็น โดยไคลเอนต์สามารถเชื่อมต่อกับหลายรีเลย์พร้อมกันเพื่อกระจายและดึงข้อมูลแบบกระจายศูนย์
  • โปรโตคอลนี้ไม่มีเจ้าของ แต่ ผู้ให้บริการรีเลย์ แต่ละรายสามารถกำหนดเกณฑ์การกลั่นกรองและการบล็อกตามนโยบายของตนเอง และผู้ใช้ก็เลือกได้ว่าจะอ่านจากรีเลย์ใด
  • นอกเหนือจากไมโครบล็อกกิงแบบ Twitter แล้ว ระบบนิเวศและซับโปรโตคอลยังขยายไปสู่ กลุ่มปิด (NIP-29), มาร์เก็ตเพลส, วิกิแบบกระจายศูนย์, การทำงานร่วมกันด้านโค้ด/ทอร์เรนต์/ไลฟ์สตรีมมิง และอื่น ๆ
  • ตอนนี้ยังเป็นช่วงที่ต้องอาศัย การมีส่วนร่วมของนักพัฒนาและผู้ใช้กลุ่ม early adopter มากกว่าจะเป็นผลิตภัณฑ์ที่เสร็จสมบูรณ์ โดยกำลังแก้โจทย์อย่างสแปม การสเกล และการค้นพบเนื้อหาด้วย กลยุทธ์การผสมผสานไคลเอนต์และรีเลย์

An open protocol with a chance of working

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

Many clients, many servers

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

A new paradigm for communication

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

The protocol is ownerless, relays are not

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

Freedom of association

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

Your own piece of Nostr

  • โปรแกรมเมอร์สามารถรัน รีเลย์ของตนเอง ได้ง่าย ๆ และใช้ กฎของตนเอง ได้
  • มีการลิงก์ไปยังรีโพซิทอรีของรีเลย์เพื่อส่งเสริม การมีส่วนร่วมและการทดลอง

New Ideas — Exploring the commons

  • นอกเหนือจาก ไมโครบล็อกกิง แบบ Twitter แล้ว ยังรองรับข้อมูลหลายประเภท เช่น วิดีโอ/บทความยาว/รูปภาพ/วอยซ์โน้ต
  • มีการทดลองซับโปรโตคอลอย่างคึกคักในรูปแบบ กลุ่มปิด, Wikipedia แบบกระจายศูนย์, Couchsurfing, มาร์เก็ตเพลส, เว็บ annotation และอื่น ๆ
  • มีความพยายามใช้ Nostr เป็น ชั้นสำหรับการค้นพบและการประสานงาน ในงานอย่าง การทำงานร่วมกันด้านโค้ดแบบกระจายศูนย์บน git, การโฮสต์ไฟล์, การแชร์ทอร์เรนต์, วิดีโอไลฟ์ และอื่น ๆ
  • มีการผลักดันการขยายความสามารถและการทำงานร่วมกันผ่านชุดข้อเสนอมาตรฐาน NIP

Ecosystem — Still under construction

  • แม้จะมีซอฟต์แวร์โอเพนซอร์สและฐานผู้ใช้ขนาดใหญ่ แต่ก็ยังไม่ใช่ผลิตภัณฑ์สำเร็จรูปที่ ขัดเกลาจนสมบูรณ์
  • การมีส่วนร่วมของ ผู้ใช้ยุคแรกและนักพัฒนา มีความสำคัญต่อการปรับปรุง flow ของโปรโตคอลและ UX

Microblogging — The outbox model

  • outbox model ถูกแนะนำว่าเป็นแนวทางมาตรฐานของการสร้างไคลเอนต์ที่ทนทานต่อการเซ็นเซอร์ แต่ พารามิเตอร์ยังยืดหยุ่นได้
  • คู่มือการพัฒนาอธิบายวิธี ปฏิบัติต่อรีเลย์เสมือนเป็นสตอเรจ และ กลยุทธ์การ subscribe/publish

Relay-based groups — NIP-29

  • NIP-29 เสนอวิธีสร้าง กลุ่มปิด แบบฟอรัม/แชตบนพื้นฐานของรีเลย์อย่างมีประสิทธิภาพ
  • อธิบายโครงสร้างที่ยังคง ความทนทานต่อการเซ็นเซอร์ ไว้ได้ ขณะเดียวกันก็ลดการพึ่งพารีเลย์เดี่ยว

How Nostr works

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

FAQ — คำถามและคำตอบสำคัญ

  • “โปรโตคอล” คืออะไร

    • คือ ภาษากลาง ที่ซอฟต์แวร์หลายตัวใช้สื่อสารถึงกัน สื่อถึง การทำงานร่วมกันได้ แบบเดียวกับ e-mail/HTML/HTTP ที่ไม่ผูกติดกับแอปใดแอปหนึ่ง
    • หลายแอป ที่ใช้ภาษาร่วมกันสามารถแทนกันได้ และแต่ละแอปก็มี การแสดงผลและ UI ต่างกัน

  • รับมือกับสแปมและคอนเทนต์ที่ไม่ต้องการอย่างไร

    • ฟีดพื้นฐานจะดึงเฉพาะข้อมูลจาก คนที่ฉันติดตาม จึงทำให้ push spam เกิดได้ยาก
    • การดูแบบเปิด เช่น การดูคอมเมนต์ อาจเจอสแปมได้ จึงใช้ กลยุทธ์ลดพื้นผิวการปะทะ เช่น จำกัดไว้ที่เพื่อนบ้านลำดับสอง, whitelist รีเลย์ที่เชื่อถือได้, รีเลย์แบบจ่ายเงิน/ยืนยันตัวตน
    • แม้จะไม่มีวิธีแก้ที่สมบูรณ์แบบ แต่ Nostr ถูกออกแบบโดยตั้งอยู่บนแนวคิดเรื่อง resilience

  • ถ้ามีการใช้งานในวงกว้าง จะสเกลได้หรือไม่

    • พื้นฐานคือ สถาปัตยกรรมไคลเอนต์-เซิร์ฟเวอร์ และเนื่องจากผู้ใช้จะ กระจายตัวตามธรรมชาติ ไปยังรีเลย์นับร้อย จึงมี การกระจายโหลด อยู่ในตัว
    • แม้อาจกังวลเรื่องการเชื่อมต่อรีเลย์จำนวนมาก แต่ผู้คนมักติดตาม กลุ่มบัญชีที่มีความสนใจคล้ายกัน ทำให้รีเลย์เกิดตัวหารร่วมตามธรรมชาติ
    • แอปแบบ native สามารถรองรับ WebSocket หลายร้อยรายการได้ และใช้ ฐานข้อมูลภายในเครื่อง กับคำขอแบบ batch เพื่อรักษาประสิทธิภาพ

  • รับมือกับการคุกคามทางออนไลน์อย่างไร

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

  • ทำไมไม่ใช้ Mastodon/Fediverse

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

  • ทำไมไม่ใช้ Bluesky/ATProto

    • เพราะมี การรวมศูนย์ของตัวตนบนฐาน PLC และมีลำดับการไหลแบบแหล่งความจริงเดียวของ Relay-AppView-Client จึงเสี่ยงต่อ การเซ็นเซอร์ การจัดเรียงใหม่ และ shadowban สูง
    • แม้จะปรับปรุงได้ด้วยการทำหลายแหล่งข้อมูล แต่ถ้าทำเช่นนั้น สุดท้ายก็แทบจะ ลู่เข้าหาโครงสร้างแบบ Nostr

  • แรงจูงใจของผู้ให้บริการรีเลย์สอดคล้องกันหรือไม่

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

  • จะมองเห็นคอนเทนต์ทั้งหมดที่กระจัดกระจายอยู่บนหลายรีเลย์ได้หรือไม่

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

  • ระบบค้นหาทำงานอย่างไร

    • โดยพื้นฐานแล้ว ต้องเคยเห็นมาก่อนจึงจะค้นหาได้ ดังนั้นหากต้องการการค้นหาแบบสาธารณะ ก็ต้องมี crawler/indexer ที่คอยเก็บข้อมูลจากเครือข่ายแบบเลือกสรร
    • ไคลเอนต์สามารถใช้ การเก็บข้อมูลในเครื่อง เพื่อค้นหาแบบ local search กับคอนเทนต์ที่ตนเคยเห็นหรือมีปฏิสัมพันธ์ด้วยได้อย่างรวดเร็ว
    • รีเลย์ตามหัวข้อ สามารถใช้การทำดัชนีของตนเองเพื่อให้บริการ การค้นหาในขอบเขตที่มีประโยชน์

  • ถ้าไม่มีอัลกอริทึม จะค้นพบคอนเทนต์ใหม่ได้อย่างไร

    • พื้นฐานคือการสำรวจ interaction graph ของคนที่ติดตาม และ Nostr เองก็สามารถมี อัลกอริทึมแบบ local/relay/AI-based ได้
    • สามารถใช้ กลไกการค้นพบเนื้อหา ได้หลากหลาย เช่น การไฮไลต์/การดันสิ่งที่ควรกลับมาดูอีกครั้ง ในฝั่งไคลเอนต์ หรือ การคิวเรต ทางฝั่งรีเลย์

  • ความสัมพันธ์กับ Bitcoin คืออะไร

    • มี หลักการคริปโตกราฟี ร่วมกันและเริ่มต้นจากคอมมูนิตี้ Bitcoin แต่ ไม่ได้มีการพึ่งพากัน
    • Zaps คือ มาตรฐานการให้ทิปด้วย Bitcoin ที่ไคลเอนต์บางตัวรองรับ และเป็น ทางเลือกทั้งหมด

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

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

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

  • ควรตระหนักว่าเทคโนโลยีเข้ารหัสของ Nostr มีความหละหลวมอย่างร้ายแรง
    ช่องโหว่สำคัญที่นำเสนอในงานวิจัยนี้มีดังนี้

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

    • ไคลเอนต์หลักสองตัวอย่าง Damus และ Iris ไม่ได้ตรวจสอบลายเซ็นด้วยซ้ำ

    • DM ในระบบใช้การเข้ารหัสแบบ CBC ที่ไม่มีการยืนยันตัวตน ผู้โจมตีจึงสามารถแก้เนื้อหาด้วยการ bit-flip ข้อความได้

    • แอปทำลิงก์พรีวิวอัตโนมัติ ทำให้การโจมตีแบบ EFAIL เก่ากลับมาทำได้อีก

    • ระบบไม่มีการแยกประเภทกุญแจ จึงอาจหลอกผู้ใช้ให้ใช้ session key ผิดประเภทได้

    • โดยรวมแล้วเป็นความผิดพลาดพื้นฐานระดับกลางยุค 2000

    • Nostr อาจมีข้อดีด้านอื่น แต่ถ้าต้องการความปลอดภัยแบบ end-to-end ก็ไม่ใช่แพลตฟอร์มที่เหมาะ

    • ผมอยู่ในชุมชน Nostr มานานและเคยทำส่วนขยายสำหรับ Safari ด้วย
      แม้ยังไม่ได้อ่านงานวิจัยนั้น แต่ผมคิดว่าประเด็นที่ยกมามีความเข้าใจผิดหรือสับสนเกี่ยวกับตัวโปรโตคอล Nostr เอง
      ใน Nostr กุญแจสาธารณะทำหน้าที่เป็นตัวตนโดยตรง
      ในเชิงคริปโตแล้ว ตัวตนที่อิงกุญแจสาธารณะปลอมแปลงไม่ได้อยู่แล้ว(ไม่นับบั๊กในการติดตั้งใช้งาน)
      ในเชิง UX อาจยากที่จะตรวจสอบว่า 'ตัวตนจริงของเจ้าของกุญแจสาธารณะ' คือใคร แต่เป็นคนละประเด็นกับความปลอดภัยเชิงการเข้ารหัส

    • ข้อกล่าวหาว่า 'โปรโตคอลอีเวนต์ไม่ยืนยันกุญแจสาธารณะ' นั้นไม่สมเหตุสมผลเลย
      ไคลเอนต์และรีเลย์ส่วนใหญ่ตรวจลายเซ็นจริง
      ในฐานะผู้เขียน Damus ขอชี้แจงว่านั่นเป็นเรื่องของเวอร์ชันเก่า — ปัญหานั้นถูกแก้แล้ว
      ช่วงแรกเราเชื่อมต่อเฉพาะรีเลย์ที่เชื่อถือได้ และรีเลย์เหล่านั้นก็ตรวจสอบลายเซ็น
      ถึงขั้นสร้าง embedded DB ชื่อ nostrdb ขึ้นมาเพื่อเร่งการตรวจลายเซ็นโดยเฉพาะ
      ข้อกล่าวหาว่า DMs เสี่ยงเพราะใช้ CBC ที่ไม่ยืนยันตัวตนก็ไม่ถูกต้อง
      เนื้อหาโน้ตทั้งหมดถูกครอบด้วยลายเซ็น secp256k1 อยู่แล้ว
      พวกพรีวิวลิงก์อัตโนมัติ รูปภาพ ฯลฯ ปิดเปิดได้ และถ้ากังวลก็แนะนำให้ใช้ VPN

    • ผมพยายามหาว่า Nostr ใช้อัลกอริทึมกุญแจแบบไหน แต่ในเอกสารไม่มีที่ไหนระบุไว้ตรง ๆ
      พอค้นหาก็เจอแต่เรื่อง Blech32 (การเข้ารหัสคีย์ของ Bitcoin)
      ดูจากเอกสารแนะนำของ hellonostr.dev จะเห็นว่าตัว encoding เองมีข้อมูลเวอร์ชันฝังอยู่
      ในรูปแบบ npub1abcxyz... นั้น npub คือ header, 1 คือเวอร์ชัน และส่วนที่เหลือคือคีย์
      ลองดูเอกสารที่เกี่ยวข้อง

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

    • ไม่เข้าใจว่าทำไมเพิ่งได้ยินเรื่องพวกนี้เป็นครั้งแรกตอนนี้
      ควรมีการถกเถียงกันอย่างรวดเร็ว
      ในมุมมองของโปรโตคอล ผมสงสัยว่าแพลตฟอร์มแบบสหพันธรัฐที่ปลอดภัยกว่าจะเป็น bluesky(at protocol) หรือ fediverse

  • หลายคนเข้าใจผิดว่ารีเลย์ของ Nostr ทำงานแบบ federate และแชร์ข้อความกัน
    แต่จริง ๆ ไม่ใช่แบบนั้น
    ถ้าจะสร้าง Twitter clone ไคลเอนต์ต้องค้นหาและโพสต์ไปยังหลายรีเลย์ด้วยตัวเอง
    และถ้าไม่ได้ใช้รีเลย์ร่วมกันก็จะมองไม่เห็นข้อความของกันและกัน
    ถ้าใช้รีเลย์เดียวก็จะรวมศูนย์เต็มรูปแบบ
    แต่ถ้าใช้หลายรีเลย์ก็ช้าและยุ่งยาก ผู้ใช้ต้องรู้เองว่าจะเชื่อมต่อรีเลย์ไหน
    เอกสาร NIP ก็ปะปนสับสนจนทำให้ดูแลรักษายากด้วย

    • รีเลย์ก็ทำ federation ได้เหมือนกัน
      โปรโตคอล Nostr ไม่ได้ระบุอะไรเกี่ยวกับการทำ federation เลย
      ผมกำลังรัน indexer (relay) อยู่ และมันเชื่อมกับรีเลย์อื่น
      เหมือน ActivityPub relay คือไคลเอนต์ไหนก็เชื่อมกับ indexer เพื่อ bootstrap และค้นหา metadata ของอีเวนต์ได้
      ต่อให้ไม่ได้เชื่อมรีเลย์เดียวกัน ไคลเอนต์ก็ยังแลกเปลี่ยนข้อมูลกันได้หลายวิธี

    • ผมคิดว่านี่เป็นโจทย์ยากที่น่าสนใจมาก
      ถ้าระบุรีเลย์สำหรับอ่านและเขียนไว้ใน metadata ของโปรไฟล์แบบ NIP65
      ไคลเอนต์ก็จะค้นหาคอนเทนต์ที่เกี่ยวข้องทั้งหมดได้ง่าย
      นอกจากนี้ยังมีอีกหลายแนวคิดที่กำลังทดลองกันอยู่
      ผมมองว่าเป็นปัญหาที่แก้ได้

    • รีเลย์ไม่ได้เป็นเจ้าของคอนเทนต์ที่ผู้ใช้สร้าง จึงไม่จำเป็นต้องทำ federation
      ปกติไคลเอนต์จะพึ่งพาชุดรีเลย์ที่ผู้ใช้เลือกเอง
      ถึงอย่างนั้นรีเลย์หลักจำนวนมากก็ทำงานแบบเก็บอีเวนต์จากรีเลย์อื่นด้วย(คล้าย ๆ federation)
      เช่น Primal, TheForrest, nostr.land
      nostr.land เป็นรีเลย์แบบเสียเงิน โดยเน้นกรองสแปมและรวมโน้ตจากหลาย public relay
      ถ้าไม่ชอบก็เลือกรีเลย์อื่นได้
      ผู้ใช้ส่วนใหญ่ในตอนนี้น่าจะเห็นโน้ตได้เกิน 99% ภายใต้ federation ของรีเลย์แบบปัจจุบัน แต่ตัวเลขจริงตรวจสอบไม่ได้
      ไคลเอนต์และตัวเซ็นบางตัวเก็บโน้ตแบบไม่เผยแพร่สาธารณะ
      และถ้ารีเลย์เซ็นเซอร์โน้ต ก็สามารถตอบโต้ด้วยการรีโพสต์ไปยังรีเลย์อื่นได้ทุกเมื่อ
      ในทางปฏิบัติ ถ้าใช้รีเลย์เสียเงินยอดนิยม คุณจะเจอคำเตือนว่า “ลงทะเบียนกับรีเลย์อื่นแล้ว” อย่างรวดเร็วใน 3/4 ของอีเวนต์เขียน
      สุดท้าย รีเลย์ยังทำหน้าที่เป็นไคลเอนต์ได้เองด้วย ซึ่งมีประโยชน์เป็นแคชเวลามือถือหรือเครือข่ายช้า
      วิธีแบบ outbox มีข้อเสียอยู่บ้าง แต่เพราะนักพัฒนาไคลเอนต์สามารถให้ผู้ใช้เลือกได้
      จึงขยายได้อย่างยืดหยุ่นตั้งแต่แบบ federated ไปจนถึง P2P

    • ไคลเอนต์ส่วนใหญ่รองรับ outbox อยู่แล้ว จึงไม่จำเป็นต้องใช้รีเลย์เดียวกัน
      ผู้ใช้แต่ละคนสามารถมี inbox และ outbox relay แยกกันได้

    • เอกสาร NIP ก็เคยมีส่วนที่แปลก ๆ อยู่บ้าง
      แต่ NIP ส่วนใหญ่กำลังได้รับการปรับปรุงอย่างดี
      และถ้ามี regular release อย่างเป็นทางการ ก็เป็นปัญหาเล็กน้อยที่แก้ได้
      นักพัฒนาหลายคนก็ตอบสนองกันเร็วมาก

  • อยากให้โปรเจกต์แบบนี้อธิบายให้ชัดเจนว่าอะไรคือ use case ปรัชญา และ implementation
    ตอนเห็นครั้งแรกแยกไม่ออกเลยว่านี่คือ social network หรือโปรโตคอล
    “มันมุ่งต้านการเซ็นเซอร์เหรอ? ต้องไปอ่านบทความในบล็อกไหม?”
    Scuttlebutt, Mastodon, ActivityPub, Diaspora ก็เหมือนกันหมด
    สรุปแล้ว “ต่างจากอีเมลตรงไหน?”, “ดีกว่า Twitter ยังไง?”
    ก่อนจะเข้าใจ ก็สับสนไปหมดว่า “นี่คือ implementation ทางเทคนิค ผลิตภัณฑ์ เว็บไซต์ หรือแอปกันแน่”
    แม้แต่ Urbit ก็คงมีไม่กี่คนที่อธิบายได้อย่างแม่นยำ
    แต่ก็ยังคิดว่าดีกว่า “Web3”
    ส่วน Bluesky กับ Gemini ถือว่าชัดเจนในจุดนี้

    • Nostr เป็นทางออกแบบประนีประนอมระหว่างโครงสร้าง P2P กับสถาปัตยกรรมเว็บ
      มันใช้เว็บเซิร์ฟเวอร์ให้สอดคล้องกับการไหลของอินเทอร์เน็ต
      ขณะเดียวกันก็ลดการพึ่งพาเซิร์ฟเวอร์และเสริมการยืนยันตัวตนกับข้อมูลด้วยกุญแจสาธารณะ/ลายเซ็น
      ผลที่ได้คือผู้ใช้มีการโอนอำนาจแบบ “credible exit”
      เพราะฉะนั้นจึงไม่ใช่ use case ใหม่เสียทีเดียว แต่ถูกเรียกว่า “อินเทอร์เน็ตแบบใหม่” มากกว่า
      มี trade-off ที่ยึดผู้ใช้เป็นศูนย์กลางแทนแพลตฟอร์ม(รวมถึงรูปแบบ UX ที่ต่างออกไปด้วย)
      จึงให้คุณค่าคล้ายกับการต้านการเซ็นเซอร์ใน social network แบบเดิม
      ทำให้ดูเหมือนมี use case ทางสังคมจำนวนมาก

    • น่าจะลองทำเว็บไซต์แบบนั้นขึ้นมาเองเลย

  • การใช้คำว่า “apolitical” ตั้งแต่บรรทัดแรกของคำอธิบายผลิตภัณฑ์มันแปลกมาก
    แถมยังมีคำว่า “open” อยู่ด้วย ซึ่งในบริบทนี้มีความหมายทางการเมืองโดยเนื้อแท้
    จำไม่ได้ว่า Nostr มีความเกี่ยวโยงกับคริปโตหรือเปล่า แต่เหมือนเคยทำให้ผมสับสน

    • Nostr ไม่มี “nostr coin” และไม่มี action on-chain
      ผมชอบจุดนี้มาก
      โดยเฉพาะเพราะมันเคยดูเหมือนทับซ้อนกับชุมชนคริปโตแบบเต็ม ๆ

    • มีผู้ใช้จำนวนมากที่ใช้ Bitcoin เป็นหลัก

    • ฝ่ายขวามีประวัติยาวนานในการเรียกตัวเองว่า “apolitical”

  • บริการแบบ federated/distributed อย่าง Nostr, Mastodon, Discord
    ถ้าจะให้เป็น SNS กระจายศูนย์อย่างแท้จริง ตัวไคลเอนต์แอปเองควรฝังรีเลย์ของตัวเองไว้ เพื่อให้ผู้ใช้ทุกคนทำหน้าที่เป็นเซิร์ฟเวอร์ด้วย
    ซอฟต์แวร์ P2P แบบคลาสสิกก็ทำกันแบบนั้นมานานและใช้งานได้จริง
    แต่หากผู้ใช้โฮสต์ข้อมูลที่ตัวเองไม่ได้รับมาโดยตรงแบบสุ่ม ๆ
    ก็จะมีปัญหาโดนลงโทษเพราะคอนเทนต์ผิดกฎหมาย คล้ายกรณีถูกจับได้ว่าครอบครองยาเสพติดผิดกฎหมายที่สนามบิน
    เพราะความเสี่ยงนี้ โครงสร้าง P2P รุ่นถัดไปจึงต้องมี “ตัวกรองคอนเทนต์ผิดกฎหมาย” ด้วย AI (เช่น CP, หนัง)
    หรือไม่ก็ต้องทำให้เป็นชุมชนปิดโดยสมบูรณ์
    เพื่อให้ถ้ามีปัญหาก็รับผิดชอบกันอยู่ภายในชุมชนเอง
    สุดท้ายแล้วโมเดลที่ไคลเอนต์ทุกตัวเป็นเซิร์ฟเวอร์ได้ด้วยคือโมเดล social แบบกระจายศูนย์ที่ดีที่สุด

    • โปรเจกต์ชื่อ iroh ทำงานแบบนี้
      “รีเลย์” มีหน้าที่แค่ช่วยส่งต่อการเชื่อมต่อระหว่างไคลเอนต์สองฝั่ง
      ดูลิงก์แนวคิดของ iroh

    • ฟังดูดี แต่ P2P จริง ๆ มักไปได้ไม่สวย
      แม้แต่ iroh เองก็ยังพึ่งรีเลย์ภายใน
      Nostr มอบอำนาจการบังคับใช้นโยบายให้รีเลย์โดยตรงอยู่แล้ว(มีคุณสมบัตินี้โดยไม่ต้องแฮ็กเพิ่ม)

  • ดีใจที่ Nostr ขึ้นหน้า HN อันดับต้น ๆ
    แม้ยังอยู่ช่วงต้น แต่ Nostr ก็รองรับ “zapps” (ไมโครเพย์เมนต์ทันทีผ่าน Bitcoin-Lightning) ได้แล้ว
    เป็นโมเดล SNS ไร้โฆษณาแบบกระจายศูนย์ ที่ให้รางวัลเล็ก ๆ แก่ครีเอเตอร์ได้โดยตรง
    โดยไม่มีปัญหาเรื่องโฆษณาหรืออัลกอริทึม

    • งาน PR ของไคลเอนต์ Nostr ก็สามารถให้รางวัลด้วย zaps ได้เช่นกัน
      ดูตัวอย่าง bounty นี้

    • Bitcoin เองก็ถูกกำกับดูแลหนักอยู่แล้ว

    • อ่านคอมเมนต์แบบนี้แล้วเกือบอยากสมัคร แต่พอไปดูหน้า explore จริง ๆ
      กลับประทับใจที่คนกำลังซื้อขายสินค้าจริง(ธง, Kakao, การศึกษาทางเลือก ฯลฯ)กันอยู่
      ไม่ใช่แค่ “เปิดไดอารีแล้วขอเงิน”
      มันดูเป็นแพลตฟอร์มสำหรับสินค้า บริการ และครีเอเตอร์จริง ๆ

    • Nostr มีอยู่มาอย่างน้อย 5 ปีแล้ว
      ตอนช่วงโรคระบาดก็มีคนจำนวนมากย้ายจาก Twitter ไป Nostr
      เลยไม่ค่อยเห็นด้วยกับคำว่ามันเพิ่งอยู่ช่วงต้น

  • แนะนำแอป Nostr หลากหลายตัว
    openux.app - บริการทางเลือกแทน Mobbin
    kinostr.com - แชตหนังแบบเรียลไทม์
    zap.stream - ไลฟ์สตรีมมิงสไตล์ Twitch
    dtan.xyz - ทอร์เรนต์
    zapstore.dev - app store ที่ไม่ต้องขออนุญาต
    nostrnests.com - แชตห้องเสียง
    zapmeacoffee.com - คล้าย Buy Me A Coffee

    • กำลังพัฒนาบริการทางเลือกแทน Quora/StackOverflow บน Nostr อยู่ด้วย
      asknostr.site
      โปรโตคอล social แบบกระจายศูนย์ลักษณะนี้เปิดทางให้เกิด use case หลากหลาย
      และข้อดีในฝั่งผู้ใช้คือ
      • ป้องกันไม่ให้บริษัท VC “ยึดข้อมูลไป”
      • เวลามีส่วนร่วมก็รับรางวัลได้(zaps/เงิน)
      • ทุกคนเข้าถึงข้อมูลได้อย่างเสรี(แต่มีแค่ผู้เขียนเท่านั้นที่เซ็นได้)

  • Nostr ไม่ได้มีไว้ใช้เป็นแค่บริการ microblogging เท่านั้น แต่ยังใช้เป็นเลเยอร์ล่างได้อีกหลายแบบ
    เช่น Trystero
    ใช้ Nostr เพื่อสร้างการเชื่อมต่อ P2P WebRTC โดยไม่ต้องมีเซิร์ฟเวอร์กลาง
    (สัญญาอนุญาต MIT)

    • ผมเองก็เคยคิดเรื่องการกระจายสัญญาณหลายช่องทางแบบต้านการเซ็นเซอร์ โดยใช้ Nostr, Bittorrent DHT, Mastodon ฯลฯ
      เป้าหมายคือจะเกิดการตัดขาดเครือข่ายได้ก็ต่อเมื่อทุกวิธีล้มเหลวพร้อมกันเท่านั้น

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

    • ไอเดียเจ๋งจริง ๆ
      ผมก็อยากลองทำอะไรคล้าย ๆ กัน แต่พอมีคนทำให้แล้วก็ประหยัดเวลาไปมาก

  • ไม่เข้าใจว่าทำไม social network เชิงเทคนิคแบบนี้
    ถึงไม่ใช้โครงสร้างเชื่อมต่อกันของหน้าเว็บส่วนตัวแต่ละคนแบบเว็บยุคดั้งเดิม
    แล้วกลับไปเป็นแพลตฟอร์มแยกที่อิงบัญชีผู้ใช้
    นอกจาก RSS แล้ว ก็สงสัยว่าไม่เคยมีความพยายามสร้างเครือข่ายที่ส่งเสริมการมีเว็บไซต์ส่วนตัว
    แล้วค่อยซ้อน social media แบบรวมศูนย์(แชต, ฟีด ฯลฯ)เข้าไปหรืออย่างไร

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

    • ลองดู RSDS(Really Simple Decentralized Syndication)

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

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

    • โดยเนื้อแท้แล้ว ตอนนี้ก็เอาเทคโนโลยีหลายอย่างมาประกอบกัน
      เพื่อสร้างหน้าเว็บส่วนตัว/แชต/ระบบฟีดของตัวเองได้อยู่แล้ว
      แต่ปัญหาเชิงปฏิบัติของโมเดลผสมแบบนี้คือ

      • อุปสรรคในการเริ่มต้น: ทำให้คนที่ไม่ใช่สายเทคนิคเข้าถึงได้ดีขึ้น
      • การค้นพบ: ปัญหาเรื่องการหาและเชื่อมโยงข้อมูลถึงกัน
      • ความยั่งยืน: การแบ่งภาระค่าใช้จ่ายในการดำเนินงาน
      • ธรรมาภิบาล: กลไกการปกครองกันเองภายในชุมชน
        เมื่อพยายามแก้ทั้งหมดพร้อมกัน ก็ย่อมต้องมีการประนีประนอม
        การกระจายศูนย์อย่างสมบูรณ์ต้องแลกกับปัญหาเรื่องการค้นพบและการเข้าถึง
        คำกล่าวที่ว่า “ไม่จำเป็นต้องมีบัญชีอีกต่อไป” ก็ยังพัวพันกับปัญหาหลายตัวตนทั้งออนไลน์และออฟไลน์
        สุดท้ายแล้วนี่คือเรื่องของการเลือกคุณค่า และบริการกระจายศูนย์เชิงทดลองหลายตัวที่หมู่นักเทคนิคชอบกัน(เช่น Mastodon, Nostr, Smolweb)
        ล้วนรับอิทธิพลจาก mindset ของอินเทอร์เน็ตยุคแรก(วัฒนธรรมโต้กระแส, ความเปิดกว้าง, มาตรฐาน, ความประกอบต่อกันได้)
        ไม่มีทางออกที่ทำให้ทุกคนพอใจได้ทั้งหมด
        เพราะฉะนั้นผมคิดว่าคุณค่าพื้นฐานของอินเทอร์เน็ตคือความหลากหลาย มาตรฐาน และความเปิดกว้าง

  • “apolitical communication commons”
    บางคนชี้ว่าป้ายคำว่า ‘ไม่การเมือง’ เอง
    ก็เป็นถ้อยแถลงทางการเมืองและเป็นจุดยืนเชิงอำนาจอยู่แล้ว

    • สงสัยว่าทำไมหลายคนถึงกลัว “การเมือง” มากนัก
      พร้อมยกหลักพื้นฐานของกรีกโบราณที่มองว่าการมีส่วนร่วมทางการเมืองเป็นหน้าที่ตามธรรมชาติของพลเมือง
      และคำว่า ‘idiot’ ก็มีรากศัพท์จากคนที่ไม่สนใจการเมืองจริง ๆ

    • แนวคิด “apolitical”
      ในความเป็นจริงภายใต้ระบอบอำนาจนิยม มักถูกมองว่าเป็นการนิ่งเฉยและสนับสนุนระบอบเดิมโดยปริยาย
      ในประเทศเผด็จการอย่างรัสเซีย นี่คือทางลัดสู่การกดเสรีภาพและการปราบปราม
      บริการอย่าง Nostr ก็เคยถูกขัดขวางด้วยวิธีที่รัฐบาลประกาศให้ “การรันรีเลย์เป็นเรื่องผิดกฎหมาย/เป็นอาชญากรรม”

    • “ถ้าทุกอย่างเป็นการเมือง การเมืองก็จะไม่เหลือความหมายอะไร”
      ผู้เขียนน่าจะแค่อยากหลีกเลี่ยงการถกเถียงที่ไม่ใช่เรื่องเทคนิค

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

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