at:// อยู่ที่ไหน

 (overreacted.io)
2 คะแนน โดย GN⁺ 2025-10-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โปรโตคอล AT เป็นโปรโตคอลที่เป็นรากฐานของโซเชียลเน็ตเวิร์กแบบกระจายศูนย์ โดยข้อมูลทั้งหมดจะถูกระบุด้วย at:// URI
  • at:// URI ใช้ ผู้สร้างข้อมูล (ผู้ใช้) เป็น authority และต้องค้นหาแยกต่างหากว่า โฮสต์อยู่ที่ไหนจริง
  • ขั้นตอนการ resolve URI ประกอบด้วยการ แปลง handle เป็นตัวตน (DID), การตรวจสอบ เซิร์ฟเวอร์โฮสต์ผ่าน DID Document, และการ ร้องขอข้อมูล JSON จากเซิร์ฟเวอร์นั้นตามลำดับ
  • รองรับ DID สองรูปแบบ (did:web, did:plc) ซึ่งมี ข้อดีข้อเสียและวิธีการคงอยู่ของข้อมูล ต่างกัน
  • แนวทางนี้เน้นว่า ความเป็นเจ้าของข้อมูลอยู่ที่ผู้ใช้ และรับประกัน ความคงทนของการเชื่อมโยง แม้ handle และโฮสต์จะเปลี่ยนไปก็ตาม

โปรโตคอล AT, at:// URI และกระบวนการ resolve ตัวตนของข้อมูลโซเชียล

# โครงสร้างพื้นฐานของโปรโตคอล AT และ at:// URI

  • โปรโตคอล AT ทำให้เซิร์ฟเวอร์แบบกระจายหลายแห่งสื่อสารกันได้ตามมาตรฐานที่กำหนด และเรียกระบบรวมนี้ว่า 'atmosphere'
  • ข้อมูลแต่ละชิ้นใน atmosphere จะได้รับ URI เฉพาะที่ขึ้นต้นด้วย at:// ซึ่งทำหน้าที่เสมือนลิงก์ไปยังข้อมูล JSON
  • ต่างจากโครงสร้าง URI แบบดั้งเดิม ในโปรโตคอล AT จะกำหนดให้ ผู้สร้างข้อมูล (ผู้ใช้) เป็น authority ของ URI
    • ตัวอย่างเช่น ในรูปแบบ at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z, ruuuuu.de ระบุว่าเป็นเจ้าของข้อมูลนั้น
  • เซิร์ฟเวอร์จริงที่โฮสต์ข้อมูลทางกายภาพไม่ได้ถูกรวมไว้ใน URI โดยตรง จึงต้องมีขั้นตอน resolve เพิ่มเติมเพื่อค้นหา

# สามขั้นตอนของการ resolve at:// URI

  • การแมป at:// URI ไปยังข้อมูลจริง (JOSN) ต้องมีสามขั้นตอน
    1. แปลง handle (เช่น ruuuuu.de) เป็นตัวตน (DID: Decentralized Identifier)
      • handle เป็นชื่อแทนสำหรับระบุผู้ใช้และสามารถเปลี่ยนได้
      • จึงต้องแปลงเป็น DID ซึ่งเป็น Global ID ที่ไม่เปลี่ยนแปลง
      • วิธีแปลง:
    2. ตรวจสอบข้อมูลโฮสต์ของข้อมูลผ่าน DID Document
      • DID Document มีข้อมูลอย่าง public key, service endpoint (เซิร์ฟเวอร์) ของตัวตนนั้น
      • กรณี did:web:~ จะใช้แนวทางอิงโดเมน (https://โดเมน/.well-known/did.json)
      • กรณี did:plc:~ จะค้นหาจาก PLC directory (https://plc.directory/DID)
      • service endpoint (serviceEndpoint) คือเซิร์ฟเวอร์ที่โฮสต์ข้อมูลจริง
    3. ร้องขอข้อมูล JSON ผ่าน API ของเซิร์ฟเวอร์โฮสต์
      • ส่งแต่ละส่วนของ at:// เป็นพารามิเตอร์ไปยัง endpoint com.atproto.repo.getRecord เพื่อร้องขอข้อมูล
      • JSON ที่ส่งกลับมาคือข้อมูลจริงที่แมปกับ at:// URI

# อธิบายกระบวนการ resolve ผ่านตัวอย่าง

  • ตัวอย่าง: at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z
    • ขั้นที่ 1: ruuuuu.de → did:web:iam.ruuuuu.de (ตรวจสอบผ่าน DNS TXT record หรือ .well-known)
    • ขั้นที่ 2: ตรวจสอบ DID Document ที่ https://iam.ruuuuu.de/.well-known/did.json → serviceEndpoint คือ https://blacksky.app
    • ขั้นที่ 3: ร้องขอไปยัง https://blacksky.app/xrpc/com.atproto.repo.getRecord?... → ได้รับ JSON จริงกลับมา 
      {
  "uri": "at://did:web:iam.ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z",
  "cid": "...",
  "value": {
    "text": "posting from did:web, like a boss",
    "$type": "app.bsky.feed.post",
    ...
  }
}
  • แม้ handle จะเปลี่ยนไป หากใช้ at:// URI (permalink) ที่อิง DID ความเชื่อมโยงระหว่างบัญชีกับข้อมูลก็ยังคงอยู่

# ความแตกต่างระหว่าง did:web และ did:plc

  • did:web:
    • สามารถจัดการและยืนยันโดเมนของตนเองได้
    • หากสูญเสียสิทธิ์ควบคุมโดเมน ก็อาจสูญเสีย ID ทั้งหมดได้
  • did:plc:
    • PLC (Public Ledger of Credentials) เป็นผู้ดำเนินการ ID
    • ไม่ผูกติดกับโดเมน แต่ก็มีความเป็นไปได้ของการควบคุมแบบจำกัด เช่น ผู้ดำเนินการ PLC อาจปฏิเสธการอัปเดต
    • ประวัติการเปลี่ยนแปลงทั้งหมดสามารถตรวจสอบและติดตามได้ด้วยแฮช

# การแยกตัวตน โฮสต์ และข้อมูลออกจากกัน พร้อมความคงทน

  • at:// แยกตัวตนออกจากการโฮสต์ข้อมูล ทำให้ข้อมูลผู้ใช้พกพาได้และสร้างลิงก์ถาวรได้
  • Handle (ชื่อเล่น) สามารถเปลี่ยนได้ตลอดเวลา และเซิร์ฟเวอร์โฮสต์ก็สามารถย้ายได้เช่นกัน
  • DID (ตัวตน) ไม่เปลี่ยนแปลง และ at:// URI ที่อิงสิ่งนี้สามารถใช้เป็น permalink แบบถาวรได้
  • DID Document มีทั้งหลักฐานความเป็นเจ้าของ handle, คีย์สำหรับตรวจสอบลายเซ็น, และข้อมูลโฮสต์ จึงรับประกันทั้งความน่าเชื่อถือและความยืดหยุ่น

# การใช้งานจริงและประเด็นด้านการพัฒนา

  • ในทางปฏิบัติ แอปส่วนใหญ่ที่สร้างบน AT มักรับข้อมูลแบบ push ผ่าน Websocket เป็นต้น แล้วรวบรวมลงฐานข้อมูลภายใน
  • ถึงอย่างนั้น การเข้าใจวิธี resolve at:// URI ก็ยังจำเป็นต่อการ ทำความเข้าใจลักษณะของเครือข่ายและการย้ายข้อมูลได้
  • ระบบ at:// มอบชั้น abstraction สำหรับโซเชียลเน็ตเวิร์กบนพื้นฐานของ HTTP, DNS และ JSON และ ทำให้ความเป็นเจ้าของข้อมูลของผู้ใช้เกิดขึ้นจริงในเชิงเทคนิค

# บทสรุป

  • โปรโตคอล AT และ at:// URI ยกระดับเรื่องตัวตน การเชื่อมโยง และความคงทนของข้อมูลโซเชียลในเชิงเทคนิคไปอีกขั้น
  • นักพัฒนาจำเป็นต้องเข้าใจ เวิร์กโฟลว์หลัก เช่น การ resolve handle, การใช้ DID, โครงสร้าง DID Document และวิธีร้องขอข้อมูลจริง
  • ด้วยโครงสร้างนี้ ผู้ใช้จึงได้รับทั้งความยืดหยุ่นและความเป็นเจ้าของระหว่างคอนเทนต์ ตัวตน และตำแหน่งที่โฮสต์ของตนเอง

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

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

 
GN⁺ 2025-10-05
ความเห็นจาก Hacker News

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

    • สำหรับบัญชีใหม่ ฟีด "Discover" ไม่ค่อยดีนัก พอมีข้อมูลไลก์หรือการติดตามสะสมมากขึ้นมันจะค่อย ๆ ดีขึ้น แต่ก็ยังเรียกว่าดีที่สุดไม่ได้ ส่วนตัวแนะนำฟีด "For You" มากกว่า เพราะฟีดนี้สะท้อนไลก์ได้ไวและดันคอนเทนต์สุ่มน้อยกว่า ฟีด "Dev Trending" ก็ค่อนข้างดี For You Feed, Dev Trending
    • วิธีที่ผมใช้คือหาแอ็กเคานต์ดี ๆ สักไม่กี่อันแล้วกดติดตาม จากนั้นซ่อนแท็บ "Discovery" ไปเลย หลังจากนั้นก็ค่อย ๆ ขยายรายชื่อติดตามตามธรรมชาติจากการดูปฏิสัมพันธ์ของคนในรายชื่อผู้ติดตาม/กำลังติดตาม หรือไม่ก็หาแอ็กเคานต์จากบล็อกหรือเว็บไซต์แล้วไปติดตาม ผมคิดว่านี่แหละคือวิธีที่มันควรทำงานแบบโซเชียลมีเดียจริง ๆ ไม่ใช่โดนยัดคอนเทนต์แนะนำอัตโนมัติมาให้
    • โชคดีที่ bsky มีฟีดแบบไม่ใช้อัลกอริทึมที่แสดงเฉพาะโพสต์จากคนที่คุณติดตาม ผมคิดว่านี่คือวิธีเดียวที่จะรักษาสุขภาพจิตไว้ได้
    • ผมใช้ bsky มานานกว่าหนึ่งปีแล้ว แต่คอนเทนต์ส่วนใหญ่ก็ยังเป็นการเมืองอเมริกัน สำหรับคนยุโรปอย่างผมมันรู้สึกเหมือนเสียงรบกวน เลยกลับไปใช้ Mastodon อีกครั้ง สำหรับการติดตามคนสายเทค Mastodon ดีกว่ามาก ส่วนข่าวผมรับผ่าน RSS ของ feedly หมดแล้ว ตอนนี้ก็ไม่ค่อยเข้าใจว่าต้องมี Bluesky ไปทำไม มันให้ความรู้สึกเหมือนทวิตเตอร์เวอร์ชันฝั่งซ้ายเท่านั้นเอง เทคโนโลยีอาจน่าสนใจในฐานะเวอร์ชันพัฒนาต่อของ Nostr แต่ก็แค่นั้น
    • แนะนำให้เข้าไปที่ Settings > Contents and Media > Your Interests > News and Politics แล้วปิดมัน ถ้าอยากดูข่าวและคอนเทนต์การเมืองของประเทศอื่นที่ไม่ใช่อเมริกา ผมก็ไม่รู้ว่ามีวิธีไหนเป็นพิเศษ

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

    • ใน AT ข้อมูลไม่ได้ผูกกับ handle หรือโฮสติ้ง แต่ผูกกับ DID (Decentralized Identifier, ตัวระบุแบบกระจายศูนย์) บทความที่ผมเขียนอธิบายจุดนี้ไว้ละเอียด ถ้าคุณเสียโดเมน "handle" ไป สิ่งที่เกิดขึ้นก็แค่ handle ใช้งานไม่ได้ และในแอปจะขึ้น "invalid handle" แทนชื่อผู้ใช้ประมาณนั้น แต่ข้อมูลอย่างโพสต์หรือผู้ติดตามยังคงอยู่ เพราะยังดึงผ่าน DID ได้ Handle เป็นแค่ชื่อเล่นอย่างหนึ่งเท่านั้น การเปลี่ยน handle ก็ทำได้ผ่านฟังก์ชัน "เปลี่ยน handle" ในแอป เช่นเดียวกับโฮสติ้ง ถ้ามี backup ของ repository ไว้ก็สามารถย้ายไปที่อื่นได้ (แม้จะมีอุปสรรคอยู่บ้าง) จะทำ backup อัตโนมัติก็ได้ และตอนนี้ก็มีแอป third-party ที่ทำ backup ให้อัตโนมัติแล้ว แอป Bluesky อย่างเป็นทางการก็ส่งออก repository ได้ ถ้าผู้ให้บริการโฮสต์ให้ความร่วมมือ ก็มีกรณีอย่าง PDSMover และถ้าไม่ให้ความร่วมมือก็ดู adversarial pds migration ได้ ตอนนี้ยังต้องมีความรู้เชิงเทคนิคอยู่ แต่หวังว่าวันหนึ่งกระบวนการนี้จะง่ายขึ้น พออัปโหลด repository ไปยังโฮสต์ใหม่ ทุกอย่างอย่างโพสต์ ผู้ติดตาม ฯลฯ จะกลับมาเหมือนเดิมภายใต้อัตลักษณ์เดิมแบบไม่มีความแตกต่าง จุดนี้ต่างจากอีเมลมาก ตอนนี้อาจยังยากอยู่ แต่คาดว่าพอ ecosystem ของ AT พัฒนาแล้วจะสะดวกขึ้นมาก
    • แม้มีโดเมน วันหนึ่งก็อาจไม่มีได้เหมือนกัน ต่างจากเซิร์ฟเวอร์ตรงที่โดเมนต้องพึ่ง registrar เลยรู้สึกเปราะบางกว่า ผมเลยเลือก registrar ที่อยู่ภายใต้กฎหมายของประเทศตัวเอง อย่างน้อยถ้ามีปัญหาก็ยังพอมีความหวังเรื่องการกู้คืนมากกว่า
    • ผู้ใช้ส่วนใหญ่ที่ไม่มีโดเมนย่อมเสี่ยงอยู่ตลอดเมื่อผู้ให้บริการโฮสต์กลายเป็น "ศัตรู" ขึ้นมา เช่น บล็อกบัญชีกะทันหัน การป้องกันแบบสมบูรณ์สุดท้ายก็คือต้องถือครองโดเมนเองบน TLD ที่เป็นกลางและทำ routing ทราฟฟิกด้วย DNS ถึงอย่างนั้น ภายใต้ความเป็นจริงนี้ (คือแทบไม่มีใครจะใช้โดเมนของตัวเอง) โปรเจกต์นี้ก็ยังเพิ่มความยืดหยุ่นและการปกป้องบางส่วน เมื่อเทียบกับ Big Social เดิม ๆ (Facebook, X, Instagram ฯลฯ) ที่ข้อมูลถูกขังไว้ตลอดกาล ก็นับว่าเป็นความก้าวหน้า Bluesky ดูเหมือนจะสนใจแนวทางที่สามารถย้ายเฉพาะโฮสต์ข้อมูลได้โดยยังคง handle เดิมไว้ด้วย ผมคิดว่าอุตสาหกรรมคงไปไม่ถึงความสมบูรณ์แบบในครั้งเดียว แต่ค่อย ๆ พัฒนาโดยแก้ปัญหาจริงทีละนิด
    • ผมคิดว่าการพิสูจน์อัตลักษณ์ที่ดีที่สุดคือการถือ private key เอง ส่วนโฮสติ้งน่าจะไม่มีอะไรแข็งแกร่งกว่า BitTorrent แล้วไหม อาจคิดถึงวิธีเก็บคอนเทนต์ไว้ใน git repository เซ็นกำกับที่ commit แล้วแจกผ่าน torrent ก็ได้ ส่วนการแจ้งอัปเดตผมเคยนึกถึง NNTP หรือ RSS ปัญหาคือการค้นหาเจอ (discoverability) และการไม่มีปฏิสัมพันธ์ (ไม่มีคอมเมนต์)
    • อย่างน้อยอีเมลยังย้าย PGP/SMIME key ไปที่อื่นได้ เลยสงสัยว่า ATproto ก็เป็นคอนเซปต์คล้าย ๆ กันหรือเปล่า

  • คำอธิบายของ Dan ยอดเยี่ยมทุกครั้ง และยิ่งตรงจังหวะกับข่าวล่าสุดเรื่อง Bluesky จะโอนสิทธิ์การดูแล PLC ด้วย ทีมของเราก็เลือกใช้ระบบ DID เดียวกันที่ fair.pm เพื่อกระจายการเผยแพร่ปลั๊กอิน WordPress (พูดง่าย ๆ คือระบบจัดการแพ็กเกจคล้าย App Store) ฝั่ง Bluesky โดยเฉพาะ Bryan ช่วยเราเยอะมาก และเรายังขอให้รองรับคีย์ Ed25519 เพื่อให้ใช้ libsodium ได้ด้วย โปรโตคอลของเรากำลังออกแบบอยู่บน DID และระบบ stackable moderation ของ Bluesky แต่ไม่ได้ใช้ atproto โดยตรง ประเด็นสำคัญคือ DID เป็นมาตรฐาน W3C ดังนั้น PLC จึงไม่ได้ผูกติดกับ atproto

    • "พวกเรา" คือใคร และถ้านี่เป็นความพยายามแก้ WordPress drama ในทางเทคนิค ก็อยากฟังรายละเอียดเพิ่ม
    • คุณบอกว่า PLC ไม่ได้ผูกกับ atproto แต่ PLC (did method) เองสุดท้ายก็ผูกกับ bluesky หรือหน่วยงานศูนย์กลางอะไรสักอย่างไม่ใช่หรือ? ในเมื่อรวมศูนย์ขนาดนี้แล้วทำไมถึงเรียกมันว่า DID สงสัยด้วยว่า did:plc ไม่สามารถพกพาได้ ทำไมถึงไม่ทำเป็น did:web แล้วใส่พฤติกรรมแบบ PLC เข้าไป ทำไม method-specific-id ถึงไม่อิง hash ของ public key หรืออะไรที่ย้ายได้ และทำไมถึงไม่ไปทางกระจายศูนย์แบบ DHT (เช่น did:pkarr) ด้วย PLC มันดูเหมือนระบบรวมศูนย์อีกชั้นมากกว่า

  • ถ้าจะหา at:// ต้องส่ง GET ไปที่ plc.directory ซึ่งตรงนี้ทำให้ระบบดูเหมือนกลายเป็นโมเดลรวมศูนย์ 100% อย่างน้อยน่าจะแยก trusted directories หลายแห่งออกจากโปรโตคอลได้ (คล้าย DNS root หรือ CA)

    • ถ้าอยากทำแบบรายบุคคลก็ใช้ did:web:fqdn ได้ อันนี้ก็อธิบายไว้ในบทความแล้ว

  • ทุกเซิร์ฟเวอร์ที่เก็บลิงก์ at:// สุดท้ายคงต้องผ่าน DNS/HTTPS เพื่อหา representation แบบถาวร (permalink) ที่เป็นทางการ ถ้า DNSSEC ไม่แน่นหนา โครงสร้างนี้ก็ดูเปราะบางพอสมควร ยังไม่ได้คิดลึกมาก แต่ความกังวลที่นึกออกทันทีคือปัญหาอย่าง DNS poisoning อาจทำให้ผู้โจมตีโพสต์ในนามของผมได้ (เพราะ public key อยู่ใน DID ที่ดึงมาจาก DNS)

    • DNS poisoning อาจน่ากังวล แต่ในทางปฏิบัติไม่ได้เป็นแบบนั้นเสมอไป โดยทั่วไปที่ตำแหน่ง authority ใน at:// จะใส่ DID ลงไป ดังนั้นถ้าร้องขอด้วย DID แทน handle สุดท้ายก็พึ่งพา HTTPS และ web PKI อยู่ดี แม้เริ่มจาก handle ก็จะผ่าน web PKI และ TXT record อยู่ดี วิธีที่แนะนำคือให้เซิร์ฟเวอร์เป็นฝ่าย resolve handles และถ้าจำเป็นต้องทำเอง ก็ query ผ่านผู้ให้บริการ DoH (DNS over HTTPS) ที่เชื่อถือได้ มันไม่สมบูรณ์แบบแต่ลดพื้นผิวการโจมตีลงได้มาก แน่นอนว่า DNSSEC คือคำตอบของปัญหานี้ แต่เราเองก็เคยเจอปัญหาจาก DNSSEC ในเครือข่าย production หลายครั้ง เช่น สมาชิกวุฒิสภาสหรัฐฯ ใช้โดเมน senate.gov เพื่อยืนยันตัวตน แต่เพิ่งมีช่วงหนึ่งที่การตั้งค่า DNSSEC พัง ทำให้วุฒิสมาชิกหลายสิบคนใน Bluesky กลายเป็น "invalid handle" ประสบการณ์แบบนี้น่าผิดหวังมาก จนตอนนี้เรายังไม่ผลักดันให้บังคับใช้ DNSSEC อย่างหนัก ถ้ามีโปรโตคอลขนาดใหญ่ตัวอื่นที่บังคับ DNSSEC ได้สำเร็จ ก็ค่อยน่าคิดใหม่
    • ถ้าผู้โจมตีจะปลอมตัวเป็นคุณแล้วโพสต์ได้ จำเป็นต้องมี private key ของคุณเท่านั้น DNS record มีหน้าที่แค่บอกว่าจะไปเอา DID document จากที่ไหน และ DID document นี้เองก็ต้องถูกตรวจสอบกลับผ่าน DNS อีกที กระบวนการนี้มีตรรกะการตรวจสอบอยู่ DNSSEC ช่วยลดความเสี่ยงจากการปลอมแปลง DNS record ได้ แต่ถึงไม่มี DNSSEC ก็ไม่สามารถให้คนมั่ว ๆ ปลอมเป็นคุณแล้วโพสต์ได้ และเซิร์ฟเวอร์ก็จะปฏิเสธด้วย
    • ประเด็นนี้ค่อนข้างยาก แต่ใน DNS TXT method ก็ระบุชัดว่า "ไม่ต้องใช้ DNSSEC" อยู่แล้ว ไม่ว่าอย่างไร DNS มีหน้าที่แค่แปลง Handle->DID ส่วนการตรวจสอบเป็นกระบวนการสองทางที่มี DID->Handle ด้วย

  • ในบทความมีข้อมูลน้อยเกินไปเกี่ยวกับคีย์ที่ใช้ในประวัติการเปลี่ยน DID เช่น ถ้าผมคือ foobar.bsky.social ผมไม่เคยจำได้ว่าเคยอัปโหลดคีย์เองหรือมีคำแนะนำให้ดาวน์โหลดเลย เลยอยากรู้ว่าคีย์นั้นอยู่ที่ไหนกันแน่ ใครเป็นเจ้าของ และมันถูกใช้อย่างไรเมื่อไร อีกอย่าง ถ้า DID อยู่ใน plc.directory กลไกอะไรที่ป้องกันไม่ให้ผู้ดูแลเว็บไซต์นั้นเขียนทับ DID ของผมตามอำเภอใจแล้วขโมยอัตลักษณ์ของผมไป

  • แนวคิด at:// น่าสนใจ แต่ก็อดกังวลเรื่องปัญหาที่อาจเกิดในระบบซึ่งยึดการเป็นเจ้าของข้อมูลจริง ๆ ไม่ได้ เช่น ถ้าผู้ใช้ถือข้อมูลเอง ก็สามารถแก้หรือจะลบเนื้อหาเมื่อไรก็ได้ตามใจ สมมติว่าเขาเขียนโพสต์ดี ๆ ไว้ตอนแรก แล้วภายหลังแก้เป็นเนื้อหาร้าย ๆ แม้เราจะเก็บ hash ของโพสต์เก่าไว้เพื่อกันการเปลี่ยนแปลง บริการใหม่ ๆ ก็อาจไม่รู้ประวัตินั้น อีกทั้งการติดตามสิ่งอย่างไลก์หรือ upvote ก็ยาก ถ้าทุกคนเก็บวัตถุของตัวเองแยกกัน ก็ยิ่งหายากว่าใครโหวตอะไร นอกจากนี้ถ้าสร้างบัญชีปลอมขึ้นมาแล้วโพสต์ดันงานของตัวเองเรื่อย ๆ ก็ดูเหมือนไม่มีข้อจำกัด สุดท้ายถ้ามีบัญชีจำนวนมหาศาลจากหลายแพลตฟอร์ม การทำ moderation กับสแปมหรือพฤติกรรมไม่หวังดีจะกลายเป็นไปไม่ได้ไหม ภายใต้สมมติฐานว่าทุกบัญชีจัดการข้อมูลตัวเอง ผมยังไม่แน่ใจว่าการออกแบบระบบในแง่ความโปร่งใส ความรับผิดชอบ การกลั่นกรอง และการกันสแปม จะตั้งอยู่ได้จริงหรือไม่

    • การจัดการการเปลี่ยนแปลง (history) ก็แค่เผยแพร่ไปด้วยกันได้เลย ข้อมูล (json) สามารถใส่ข้อมูลที่ต้องการได้มากพอ จึงอธิบายลิงก์ของที่อยู่โพสต์เดิมต่อเนื่องกันในรูปแบบ at:// ได้ DID ก็อธิบายเรื่อง identity moderation ได้ดี คือให้ข้อมูลพอสำหรับระบุตัว ตัดสิน หรือบล็อกได้ ประเด็นสำคัญคือมันไม่ใช่บล็อกเชน แต่เป็นโครงสร้างที่มีเจ้าของข้อมูลเป็นศูนย์กลางและพร้อมแชร์ได้เสมอ ตราบใดที่ไม่มีใครตั้งใจมาป่วน มันก็เป็นสถาปัตยกรรมที่น่าสนใจพอตัว ถ้าไม่ได้สนใจเรื่องอย่างความโปร่งใสว่า "ข้อมูลของคนนี้อะไรอยู่ที่ไหน" ก็ไม่ใช้ก็ได้
    • เพื่อป้องกันการแก้ไขเนื้อหาต้นฉบับแบบไม่หวังดี มี strongRef ซึ่งเป็น permalink จริงแบบอิง hash อยู่ Dan ไม่ได้ลงรายละเอียดเรื่องนี้ในบทความมากนัก แต่ถ้าเก็บ strongRef ไว้ ก็ตรวจจับได้ทันทีว่าโพสต์เดิมถูกเปลี่ยนเนื้อหาไปหรือไม่ เหตุผลที่ Bluesky ยังไม่ใส่ฟีเจอร์ edit ก็เพราะกังวลเรื่องการแก้ไขแบบไม่หวังดี (ดู สรุปการทดลอง permalink, การทดลองประวัติการแก้ไข record ประกอบ) ส่วนการติดตาม upvote ถ้า crawl เครือข่ายมาเก็บข้อมูลก็น่าจะพอทำได้คร่าว ๆ ด้วย roaring bitmap หรืออะไรแนวนี้ (ตัวอย่าง roaring-bitmaps) เรื่อง moderation ก็มี stackable moderation ซึ่งเจ๋งกว่าระบบเดิมมาก และก็มีการคุยกันเรื่องทำ labeler/feedgen ให้เป็น DAG (ระบบประกอบกฎแบบเซตโอเปอเรชัน) ด้วย ปัญหาการปลอมข้อมูลก็ตรวจจับการเปลี่ยนแปลงได้ผ่าน CID hash ของแต่ละรายการ และการติดตาม history ก็เป็นไปได้ทางเทคนิค

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

    • แม้ยังอยู่ช่วงต้น แต่ก็มีอย่าง tangled.org (คล้าย GitHub), leaflet.pub (คล้าย Medium) ที่ถูกใช้งานอย่างคึกคักแล้ว และยังมีเครื่องมือที่ช่วยทำ network indexing อัตโนมัติ (slices.network) ซึ่งทำให้อุปสรรคในการพัฒนาแอปใหม่ต่ำลงเรื่อย ๆ เลยคิดว่าน่าจะมีแอปเพิ่มอีกมาก บทความก็อธิบายไว้ว่าโครงสร้างนี้ทำงานอย่างไร สิ่งสำคัญคือสำหรับผู้ใช้ "ทั่วไป" เทคโนโลยีแบบนี้ไม่ใช่เรื่องสำคัญ ผู้ใช้ Bluesky ส่วนใหญ่จริง ๆ แล้วแทบไม่สนใจ "การกระจายศูนย์" หรือบางคนถึงขั้นต่อต้านด้วยซ้ำ แต่เพราะโครงสร้างแบบกระจายศูนย์ไม่ได้โผล่ขึ้นมาบนหน้าผลิตภัณฑ์โดยตรง (เหมือนการท่องเว็บ) จึงทำให้การยอมรับใช้งานแนวนี้เป็นไปได้ ผู้ใช้แค่อยากให้มัน "ใช้งานได้ดี"
    • มันให้ความรู้สึกคล้ายอดีตของ Git, GitHub เหมือนกัน (ค่อย ๆ กระจายศูนย์และยืดหยุ่นขึ้นเมื่อมีฟีเจอร์เพิ่ม)

  • มีคำถามเชิงโครงสร้างว่า "จะหา JSON ผ่าน at:// URI ได้อย่างไร" อ่านเอกสารแล้วก็ยังไม่ค่อยเข้าใจว่าทำไมถึงต้องมี 'JSON นั้น' ด้วย ส่วนตัวรู้สึกว่าวิธีนี้ไม่ค่อยเข้าท่า

    • ต้องขอโทษที่การเกริ่นอาจดูห้วนไปหน่อย โปรโตคอล at:// ทำให้แอปต่าง ๆ ฝังคอนเทนต์จากกันได้อย่างอิสระ ส่งออกข้อมูลกันได้ แชร์อัตลักษณ์ผู้ใช้ และทำให้ self-host หรือย้ายคอนเทนต์ได้ พร้อมมอบ URI ถาวรที่ไม่ผูกกับ handle/เซิร์ฟเวอร์ หลักการเชิงเทคนิคอธิบายไว้ตลอดทั้งบทความ ตัวอย่างเช่น leaflet.pub กับ bsky.app เป็นสองแอปที่ต่างก็รวบรวมข้อมูลจาก public network เดียวกัน เลยเชื่อมและแสดงข้อมูลของกันและกันได้ง่ายโดยไม่ต้องมี API แยก (โพสต์เดโม)
    • ถ้าจะช่วยให้เข้าใจ อาจเปรียบได้กับคำถามว่า "จะหา HTML ผ่าน https:// URI ได้อย่างไร" แม้จะง่ายเกินจริงไปหน่อย แต่เหมาะกับการอธิบายให้คนที่เพิ่งเริ่มเรียน DNS, HTTP, TLS

  • สงสัยว่าโปรโตคอลนี้ทำหน้าที่คล้าย public Kafka topic ขนาดมหึมาหรือไม่ เช่น เวลาสร้างเว็บแอปใหม่ ไม่ต้องเก็บข้อมูลเอง แต่ให้ผู้ใช้แต่ละคนเก็บข้อมูลของตัวเองไว้ แล้วเราแค่มี listener ที่คอยฟัง โดยโปรโตคอลรับประกันการกระจายข้อมูล แอปก็ฟังและ cache เอาไว้ แบบนี้หรือเปล่า ฟังดูน่าสนใจในเชิงแนวคิด แต่ก็สงสัยด้วยว่าแนวคิดของ Kafka อย่าง offset หรือ partition เพื่อสเกลและกันพลาดอัปเดต ถูกนำมาใช้ด้วยไหม

    • ใช่ firehose ทำหน้าที่นั้นแทบทั้งหมด ใครก็ subscribe ได้หรือจะรัน firehose เองก็ได้ ดู คำอธิบาย ATProto สำหรับวิศวกรระบบกระจาย firehose และ jetstream มี cursor อยู่ด้วย ดังนั้นแม้จะเชื่อมช้าไปก็ยังรับอัปเดตจนถึงข้อมูลล่าสุดได้ ระยะเวลาที่ครอบคลุมขึ้นกับอินสแตนซ์ อยู่ราว 1–72 ชั่วโมง ถ้าต้องการประวัติทั้งหมดก็จัดการแบบ backfill ได้