s@ : โซเชียลเน็ตเวิร์กแบบกระจายศูนย์บนพื้นฐานเว็บไซต์แบบสแตติก

 (satproto.org)
9 คะแนน โดย GN⁺ 2026-03-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นโปรโตคอลโซเชียลเน็ตเวิร์กแบบกระจายศูนย์ที่ใช้เว็บไซต์แบบสแตติก โดยผู้ใช้แต่ละคนเป็นเจ้าของและจัดการข้อมูลของตนเองโดยตรง
  • ข้อมูลทั้งหมดถูกเก็บไว้ในคลัง JSON ที่เข้ารหัส และไคลเอนต์บนเบราว์เซอร์จะทำหน้าที่รวมฟีดและเผยแพร่โพสต์
  • ทำงานผ่านการสื่อสารโดยตรงระหว่างเว็บไซต์และเบราว์เซอร์ของเพื่อน โดยไม่มีเซิร์ฟเวอร์หรือรีเลย์
  • ชื่อโดเมนของผู้ใช้คือตัวตน และยืนยันตัวตนผ่าน HTTPS/TLS
  • ด้วยโครงสร้างที่เรียบง่าย จึงสร้างโซเชียลเน็ตเวิร์กแบบอธิปไตยข้อมูลของตนเอง โดยเน้นการสื่อสารบนพื้นฐานความไว้วางใจระหว่างบุคคล

ภาพรวมของ SAT Protocol

  • s@ คือโปรโตคอลโซเชียลเน็ตเวิร์กแบบกระจายศูนย์บนพื้นฐานเว็บไซต์แบบสแตติก ที่ผู้ใช้แต่ละคนเก็บข้อมูลไว้บนเว็บไซต์ของตนเอง
    • ข้อมูลทั้งหมดถูกเก็บในรูปแบบไฟล์ JSON ที่เข้ารหัส และไคลเอนต์บนเบราว์เซอร์จะอ่านไฟล์เหล่านี้เพื่อเผยแพร่โพสต์และรวมฟีด
    • ทำงานได้โดยไม่มีเซิร์ฟเวอร์กลางหรือรีเลย์ และข้อมูลจะเคลื่อนจากเว็บไซต์ของผู้ใช้ไปยังเบราว์เซอร์ของเพื่อนโดยตรง
  • ต้องมีความสัมพันธ์แบบติดตามกันทั้งสองฝ่าย จึงจะแลกเปลี่ยนโพสต์กันได้ และตัดโครงสร้างที่ยึดผู้มีอิทธิพลเป็นศูนย์กลางออกไป
  • โปรโตคอลนี้ไม่ได้ผูกติดกับบริการโฮสติ้งเฉพาะอย่าง GitHub Pages

ตัวตน (Identity)

  • ชื่อโดเมนของผู้ใช้ทำหน้าที่เป็นตัวตน
  • ใช้ HTTPS/TLS เพื่อยืนยันว่าเจ้าของโดเมนเป็นผู้เผยแพร่เนื้อหานั้นจริง

การค้นพบ (Discovery)

  • ให้ข้อมูลเวอร์ชันของโปรโตคอลและกุญแจสาธารณะที่เส้นทาง https://{domain}/satellite/profile.json 
    {
  "satproto_version": "0.1.0",
  "public_key": "<base64-encoded X25519 public key>"
}
  • หากใช้เส้นทางอื่นนอกเหนือจากค่าเริ่มต้น /satellite/ สามารถระบุตำแหน่งคลังข้อมูลจริงได้ผ่านไฟล์ .well-known/satproto.json

โมเดลการเข้ารหัส (Encryption Model)

  • ข้อมูลผู้ใช้ทั้งหมดถูกเก็บในคลัง JSON ที่เข้ารหัส และมีเพียงผู้ใช้กับผู้ติดตามเท่านั้นที่ถอดรหัสได้
  • ใช้คู่กุญแจ X25519 โดยเผยแพร่กุญแจสาธารณะใน profile.json และเก็บกุญแจส่วนตัวไว้ใน localStorage ของเบราว์เซอร์
  • ข้อมูลโพสต์ถูกเข้ารหัสด้วยXChaCha20-Poly1305 และคีย์เนื้อหาจะถูกเข้ารหัสแยกสำหรับผู้ติดตามแต่ละคนด้วย libsodium crypto_box_seal
  • ไฟล์ keys/_self.json มีคีย์เนื้อหาของผู้ใช้และข้อมูลลับสำหรับการเผยแพร่ ซึ่งมีเพียงเจ้าตัวเท่านั้นที่ถอดรหัสได้

การหมุนเวียนกุญแจและการเลิกติดตาม

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

ขั้นตอนการถอดรหัส

  • เมื่อผู้เยี่ยมชมเข้าไปยังเว็บไซต์ของเพื่อน จะใช้กุญแจส่วนตัวของตนถอดรหัส keys/{follower-domain}.json เพื่อรับคีย์เนื้อหา
  • หลังจากนั้นจึงดึง posts/index.json และโพสต์แต่ละรายการ (posts/{id}.json.enc) มาเพื่อถอดรหัส

โครงสร้างข้อมูล (Data Schema)

  • แต่ละโพสต์ถูกเก็บเป็นไฟล์ที่เข้ารหัสแยกกัน และ posts/index.json จะแสดงรายการ ID ของโพสต์จากใหม่ไปเก่า
  • ตัวอย่างอ็อบเจ็กต์โพสต์: 
    {
  "id": "20260309T141500Z-a1b2",
  "author": "alice.com",
  "created_at": "2026-03-09T14:15:00Z",
  "text": "Hello, decentralized world!",
  "reply_to": null,
  "reply_to_author": null
}
  • ID ของโพสต์ประกอบด้วยไทม์สแตมป์ ISO8601 UTC และแฮชสุ่ม 4 หลัก

รายการติดตาม (Follow List)

  • เก็บเป็น JSON แบบข้อความล้วนที่เส้นทาง https://{domain}/satellite/follows/index.json 
    { "follows": ["bob.example.com", "carol.example.com"] }
  • ไม่มีการเข้ารหัส เพราะความสัมพันธ์การติดตามถูกเปิดเผยอยู่แล้วผ่านซองคีย์

การรวมฟีด (Feed Aggregation)

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

ความเห็นตอบกลับ (Reply)

  • ความเห็นตอบกลับคือโพสต์ที่ตั้งค่าฟิลด์ reply_to และ reply_to_author
  • ไม่รองรับความเห็นแบบซ้อน และสามารถตอบกลับได้โดยตรงเฉพาะโพสต์ระดับบนสุดเท่านั้น
  • หากไม่สามารถเห็นโพสต์ต้นฉบับได้ (เช่น ไม่ได้ติดตามกัน) ความเห็นตอบกลับนั้นจะไม่ถูกแสดง

การเผยแพร่ (Publishing)

  • สร้างโพสต์ใหม่ → เข้ารหัสด้วยคีย์เนื้อหา → อัปโหลดไปยังเว็บไซต์แบบสแตติก → อัปเดต posts/index.json
  • การอัปโหลดสามารถใช้ GitHub Contents API เป็นต้น
  • ข้อมูลลับสำหรับการเผยแพร่จะถูกเข้ารหัสและเก็บไว้ใน keys/_self.json

ตัวอย่างโครงสร้างเว็บไซต์แบบสแตติก

{domain}/satellite/
  profile.json              # กุญแจสาธารณะและโปรไฟล์
  posts/
    index.json              # รายการ ID ของโพสต์
    {id}.json.enc           # โพสต์ที่เข้ารหัส
  follows/
    index.json              # รายการติดตาม
  keys/
    _self.json              # คีย์เนื้อหาและข้อมูลรับรอง
    {domain}.json           # คีย์เนื้อหาสำหรับผู้ติดตามแต่ละราย

FAQ

  • “มันคือ RSS + การเข้ารหัสหรือเปล่า?” → ใช่
  • “มันคือเวอร์ชันของ AT Protocol ที่ไม่มี firehose ใช่ไหม?” → ใช่
  • “มันขยายขนาดได้ไหม?” → ไม่ (“แม้แต่มิตรภาพก็ขยายขนาดไม่ได้”)
  • “s ย่อมาจาก slow/shitty ใช่ไหม?” → ใช่
  • “โฮสต์เองได้ไหม?” → ได้ แต่ต้องเปิดใช้ CORS

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

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

 
GN⁺ 2026-03-13
ความคิดเห็นจาก Hacker News

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

    • ฉันก็คิดคล้ายกัน แต่ถ้าต้องการ โลกที่ไม่มีตัวกลาง ในท้ายที่สุดก็ต้องมีการเปลี่ยนแปลงทางวัฒนธรรมที่ทำให้ผู้ใช้ที่ไม่ใช่สายเทคนิคจัดการอะไรด้วยตัวเองได้บ้าง
    • หลังตั้งค่าเริ่มต้นแล้วก็แค่ export private key ไปเก็บไว้ในตัวจัดการรหัสผ่านหรือที่คล้ายกันได้ ถ้าไม่ได้จะลงมือ implement protocol เอง มันก็ไม่ได้ซับซ้อนอะไร
      เพียงแต่กับครอบครัวหรือเพื่อน ฉันอาจต้องเป็นคนช่วยตั้งค่าให้แทน แต่ถึงอย่างนั้นพอพวกเขามีเว็บไซต์เป็นของตัวเอง ก็น่าจะชอบมากทีเดียว
    • ตาม FAQ ด้านล่างบทความ มันใกล้เคียงกับการเป็นการทดลองเชิงแนวคิดที่ตัดบางส่วนของ AT Protocol (BlueSky) ออกไป
      ในทางปฏิบัติอาจมองได้ว่าเป็นไอเดียสำหรับผสานบล็อกแบบ static เข้ากับ BlueSky
      น่าจะพัฒนาต่อได้ด้วยการใช้ตัวตนของ BlueSky หรือใช้ปลั๊กอินของ static site generator เพื่อดึงข้อมูลยืนยันตัวตนมาให้อัตโนมัติ
    • ก่อนหน้านี้เคยลองแนวคิดที่ใช้อีเมลเป็น transport layer ของโซเชียลเน็ตเวิร์ก แต่ล้มเหลว
      ดู บทความที่เกี่ยวข้อง
    • ไม่แน่ใจว่าเป้าหมายคือจะมาแทนบิ๊กเทคหรือเปล่า ถ้าแค่ ชุมชนเล็กๆ ใช้งานแล้วเกิดประโยชน์ได้ สำหรับฉันก็ถือว่าประสบความสำเร็จแล้ว

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

    • เห็นด้วย การใช้คำอย่าง “คีย์คู่ X25519” แบบไม่รู้สึกรู้สาอะไร ทำให้รู้สึกว่าโปรเจ็กต์นี้ใกล้เคียงกับการเป็น การทดลองเชิงแนวคิด มากกว่าจะมุ่งแพร่หลายสู่คนทั่วไป
    • คิดว่าแก้ได้ด้วยปุ่มเดียวอย่าง “export key ไปยังตำแหน่งที่ปลอดภัย” โดยใช้โค้ดง่ายๆ อย่าง URL.createObjectURL(localStorage.getItem(...)) เพื่อชวนให้ผู้ใช้บันทึกเป็นไฟล์
    • อย่ามัวแต่ไล่ตามความสมบูรณ์แบบจนพลาดวิธีแก้ที่ ดีพอใช้งานได้ แค่เพิ่มฟีเจอร์ดาวน์โหลด/อัปโหลดคีย์ก็แก้ปัญหาส่วนใหญ่ได้แล้ว
      แน่นอนว่าถ้าคีย์หายก็เข้าไม่ถึงอีก แต่ผู้ใช้ 2FA หรือกระเป๋าคริปโตก็ยอมรับความรับผิดชอบลักษณะนี้กันอยู่แล้ว ดังนั้นไม่ใช่เรื่องที่เป็นไปไม่ได้เลย

  • มีคนเสนอว่าควรใช้ /.well-known/ แทนพาธ /satellite/
    อ้างอิงมาตรฐาน Well-known URI

    • มีคนตอบติดตลกว่า “.poorly-known”
    • มีคนกังวลเพราะนึกถึงช่วงแรกของ AT Proto ที่ใช้พาธรากแล้วเกิด ช่องโหว่ด้านความปลอดภัย
    • มีคนแย้งว่า .well-known ใช้สำหรับทั้งโฮสต์ จึงไม่เหมาะกับระดับสตรีม และมองว่าการแยกหลายไดเรกทอรีออกจากกันน่าจะดีกว่า

  • คิดว่าข้อเสนอให้ใช้ .well-known/ นั้นน่าพิจารณาอย่างจริงจัง
    มันถูกใช้แพร่หลายอยู่แล้วในฐานะ มาตรฐานที่ขึ้นทะเบียนกับ IANA และไฟล์สำหรับความปลอดภัยกับการค้นพบก็มักวางไว้ตรงนี้
    ถ้าใช้ /.well-known/satproto.json แทน /satellite/satproto.json ก็จะเลี่ยงการชนกันได้ และทำให้ชัดเจนด้วยว่าเป็น protocol endpoint

    • แต่ก็มีคนโต้ว่า .well-known เป็นระดับโฮสต์ ดังนั้นถ้าอยากมีหลายไดเรกทอรีแยกตามบัญชี ก็อาจไม่เหมาะ

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

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

  • ถ้าจะสร้าง โซเชียลแบบกระจายศูนย์และเมสเซนเจอร์ E2EE อย่างแท้จริง ก็ต้องมีโครงสร้างที่แต่ละเซิร์ฟเวอร์โฮสต์อย่างอิสระจริงๆ แบบ Discord
    บัญชีควรถูกจัดการด้วยโปรโตคอลอย่าง Nostr และทำงานบน Yggdrasil Network เพื่อลดการพึ่งพา IPv4/6 และ DNS
    ถ้าห่อทราฟฟิกด้วย HTTPS และทำ NAT traversal ให้อัตโนมัติ ใครๆ ก็เปิดเซิร์ฟเวอร์เองได้
    โครงสร้างแบบนี้เท่านั้นที่จะทำให้หลุดพ้นจากการควบคุมของบิ๊กเทคและรัฐบาลได้

    • แต่ก็มีคนมองว่าแค่เทคโนโลยีอย่างเดียวไม่พอ เพราะ มวลชนสุดท้ายก็จะไหลไปหาแพลตฟอร์มที่มีทุนการตลาดสูงกว่า
    • ฉันมองว่าแนวทางแบบ เครือข่ายกระจายข้อมูลที่อิงแคช อย่าง BitTorrent หรือ IPFS ดีกว่า
      ต่อให้เซิร์ฟเวอร์หาย ข้อมูลก็ยังอยู่ที่ edge และเบราว์เซอร์ของผู้ใช้เองก็อาจทำหน้าที่เป็นโฮสต์ได้
      ดู ephemeral-p2p-project
    • โครงสร้างลักษณะนี้กำลังถูกทดลองอยู่แล้วใน geogram.radio
      แต่ละอุปกรณ์ทำงานเป็นเซิร์ฟเวอร์ และใช้ WebRTC เพื่อทำ messaging แบบ P2P เต็มรูปแบบ
      ต่อให้อินเทอร์เน็ตล่ม ก็ยังแลกเปลี่ยนข้อมูลกันผ่าน การเชื่อมต่อวิทยุ ได้
    • ฉันก็กำลังทำของคล้ายกันอยู่ที่ Mikoto Platforms โดย “Spaces” สามารถอยู่บน physical node ไหนก็ได้ และ DM จะถูกส่งต่อแบบ E2EE routing ผ่านหลายโหนด

  • เมื่อก่อนก็เคยมีความพยายามทำโซเชียลแบบกระจายศูนย์เต็มรูปแบบอย่าง FOAF หรือ Pingback

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

  • พออ่านคำอธิบายที่ว่า “sAT Protocol คือเครือข่ายสังคมแบบกระจายศูนย์ที่อิงกับ static site” ก็อยากวาด กราฟที่คิ้วค่อยๆ เลิกสูงขึ้น

    • ถึงอย่างนั้นก็ยังมองว่าเป็นระบบที่สมเหตุสมผล เพราะขอบเขตเป้าหมายค่อนข้างแคบ
      เพียงแต่ ciphertext สามารถถูกไล่ enumerated ได้อย่างเปิดเผย จึงอาจมีความเสี่ยงในยุคคอมพิวเตอร์ควอนตัม
    • มันคล้ายการจับคู่ PGP + RSS คือเข้ารหัสแต่ละฟีดให้เฉพาะคนที่เกี่ยวข้องถอดรหัสได้
      เหมาะกับเครือข่ายขนาดเล็ก แต่ขยายไปใหญ่ๆ ได้ยากเพราะติดปัญหาการแจกจ่ายและหมุนเวียนคีย์
    • ฉันเข้าใจมันว่าเป็นแนวคิดแบบ “ส่งฐานข้อมูลแล้วให้ไคลเอนต์ build เว็บไซต์แบบ static เอง”
    • ส่วน “Key Rotation (Unfollow)” ก็ถูกเขียนเป็นมุกด้วย ASCII art

  • ในมุมผู้ใช้ รู้สึกว่าควรเริ่มจากอธิบายก่อนเลยว่ามันเป็นบริการที่ ทำอะไรได้บ้าง
    มีแต่ศัพท์เทคนิคอย่าง fork, path, JSON, การเข้ารหัส เต็มไปหมด จนมองไม่เห็น use case ตอนใช้งานจริง

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

  • พอเห็น การทดลองเครือข่ายแบบกระจายศูนย์ แบบนี้ก็รู้สึกน่าสนใจมากจริงๆ
    ถึงจะมีปัญหาเชิงโครงสร้างเยอะ แต่การได้เรียนรู้การผสมแนวคิดใหม่ๆ ก็สนุกดี
    เพียงแต่การต้องเข้ารหัสและ build เว็บไซต์ใหม่ทั้งก้อนทุกครั้งที่ follow/unfollow นั้นยุ่งยากเกินไป
    อีกทั้งโครงสร้างที่มองไม่เห็นคอมเมนต์ถ้าไม่ได้ follow ก็จำกัด ความสามารถในการขยายระบบ อย่างมาก
    ถึงอย่างนั้นจุดที่ผสม RSS, ActivityPub และ static site เข้าด้วยกันก็น่าสนใจ
    ความพยายามทำ การควบคุมสิทธิ์เข้าถึงรายชื่อเพื่อนแบบไดนามิก บน static site นั้นดูขัดแย้งในตัวเอง แต่ก็น่าสนใจ
    สรุปแล้วเป็นโครงสร้างที่ทำให้รู้สึกทั้งรักทั้งเกลียดพร้อมกัน แต่ก็ยังดีใจและขอบคุณที่มีคนลองทำอะไรแบบนี้