- ขยายแนวคิดของ การประมวลผลส่วนบุคคลที่ยึดไฟล์เป็นศูนย์กลาง ไปสู่ การประมวลผลแบบโซเชียล โดยอธิบายโครงสร้างที่คอนเทนต์ทั้งหมดที่ผู้ใช้สร้างขึ้นเป็นของผู้ใช้เอง ไม่ได้เป็นของแอป
- บนพื้นฐานของโปรโตคอล AT ได้นำเสนอแนวคิด ระบบไฟล์โซเชียลแบบกระจายศูนย์ ที่ทำให้ ข้อมูลทำงานร่วมกันข้ามแอป ได้
- ผู้ใช้แต่ละคนจะมี ‘everything folder’ หรือ คลังเก็บข้อมูล (repository) ของตัวเอง และโพสต์ การกดถูกใจ การติดตาม ฯลฯ จะถูกเก็บเป็น ไฟล์ (record) ที่อิง JSON
- ผ่าน DID (Decentralized Identifier) และระบบ URI แบบ
at:// ทำให้คง ลิงก์ที่ระบุตัวตนได้ถาวร แม้จะเปลี่ยนโฮสติ้งหรือเปลี่ยนแฮนเดิลก็ตาม
- โครงสร้างนี้สร้าง ระบบนิเวศโซเชียลที่ยึดข้อมูลเป็นศูนย์กลาง ไม่ใช่แอป ทำให้ใครก็สามารถสร้างแอปใหม่มาทำงานบนข้อมูลเดิมได้
กระบวนทัศน์แบบไฟล์และการขยายสู่สังคม
- เดิมทีไฟล์จะอยู่ในพื้นที่ที่ผู้ใช้ควบคุม ไม่ได้อยู่ภายในแอป และ แอปมีหน้าที่เป็นเพียงเครื่องมือสำหรับอ่านและเขียนไฟล์
- ฟอร์แมตไฟล์แบบเปิด อย่าง
.svg ช่วยให้หลายแอปแชร์ข้อมูลชุดเดียวกันได้
- ภายใต้หลักการที่ว่า “ฟอร์แมตไฟล์ก็คือ API” จึงทำให้แอปต่าง ๆ ทำงานร่วมกันได้
- เมื่อนำแนวคิดนี้มาใช้กับแอปโซเชียล การกระทำอย่าง โพสต์ การติดตาม การกดถูกใจ ก็สามารถถูกจัดการเหมือนไฟล์ได้
- จะมี ‘everything folder’ ที่บรรจุกิจกรรมออนไลน์ทั้งหมดของผู้ใช้
- แอปจะสะท้อนข้อมูลในโฟลเดอร์นี้ และโฟลเดอร์ทำหน้าที่เป็น แหล่งความจริงหนึ่งเดียว (source of truth)
โปรโตคอล AT และระบบไฟล์โซเชียล
- โปรโตคอล AT คือเทคโนโลยีที่ทำให้โครงสร้างนี้เกิดขึ้นจริง โดยมี Bluesky, Leaflet, Tangled, Semble, Wisp เป็นต้นที่ทำงานบนพื้นฐานนี้
- แอปไม่ได้เป็นเจ้าของข้อมูลผู้ใช้ และด้วย การจัดเก็บข้อมูลแบบแยกเป็นรายไฟล์ แอปใหม่จึงสามารถนำข้อมูลเดิมกลับมาใช้ต่อได้
- เมื่อโฟลเดอร์ของผู้ใช้ทั้งหมดรวมกัน ก็จะกลายเป็น ระบบไฟล์โซเชียลแบบกระจายศูนย์
โครงสร้างของเรคอร์ดและคอลเลกชัน
- แต่ละโพสต์จะแสดงในรูปแบบ ไฟล์ JSON (record) โดยไม่รวมข้อมูลผู้เขียนหรือข้อมูลอนุพันธ์ เช่น จำนวนการกดถูกใจ
- ตัวอย่าง:
{ text: 'no', createdAt: '2008-09-15T17:25:00.000Z' }
- ชื่อไฟล์ถูกสร้างจาก คีย์เรคอร์ด (record key) ที่อิง timestamp เพื่อหลีกเลี่ยงการชนกัน
- โครงสร้างไฟล์ถูกกำหนดด้วยสคีมาที่เรียกว่า lexicon และแต่ละแอปสามารถออกแบบ lexicon ของตัวเองได้
- ตัวอย่าง:
com.twitter.post, fm.last.scrobble, io.letterboxd.review
- แม้จะเป็นแนวคิดเดียวกัน แต่แต่ละแอปก็อาจมี lexicon ต่างกันได้ และหลีกเลี่ยงการชนกันด้วย namespace ที่อิงโดเมน
การตรวจสอบและความน่าเชื่อถือ
- ไม่มี Lexicon Police — ไม่มีแอปใดสามารถบังคับข้อมูลของแอปอื่นได้
- แอปจะ ตรวจสอบข้อมูลตอนอ่าน (validate on read) และถ้าไม่ถูกต้องก็จะเมินทิ้ง
- เมื่อมีการเปลี่ยน lexicon จำเป็นต้อง รักษาความเข้ากันได้ย้อนหลัง และถ้าเป็นการเปลี่ยนแบบทำให้พัง ต้องแยกเป็น lexicon ใหม่
- lexicon สามารถเผยแพร่สู่สาธารณะได้ และใช้ DNS เพื่อ พิสูจน์ความเป็นเจ้าของโดเมน
ลิงก์และอัตลักษณ์ (Identity)
- ‘การกดถูกใจ’ หรือ ‘การตอบกลับ’ ที่ผู้ใช้สร้างขึ้นจำเป็นต้องอ้างอิงเรคอร์ดอื่น จึงต้องมี ระบบลิงก์ถาวร
- หลังจากลองมาหลายแนวทาง จึงใช้ DID (Decentralized Identifier) เพื่อสร้างอัตลักษณ์
- ตัวระบุอย่าง
did:plc:6wpkkitfdkgthatfvspcfmjo ไม่สามารถเปลี่ยนได้
- DID แต่ละตัวจะถูกตีความเป็นเอกสารที่บรรจุข้อมูล โฮสติ้งปัจจุบัน แฮนเดิล และกุญแจสาธารณะ
- URI แบบ
at:// จะรวม DID คอลเลกชัน และคีย์เรคอร์ดเข้าด้วยกัน เพื่อให้ได้ ลิงก์ที่ไม่พังแม้เปลี่ยนโฮสติ้ง
- ตัวอย่าง:
at://did:plc:6wpkkitfdkgthatfvspcfmjo/com.twitter.post/34qye3wows2c5
JSON hyperlink และการแสดงความสัมพันธ์
- แต่ละ ‘ถูกใจ’ ‘รีโพสต์’ และ ‘ตอบกลับ’ ใช้โครงสร้าง JSON แบบไฮเปอร์ลิงก์ ที่อ้างอิงเรคอร์ดอื่น
- ตัวอย่าง: ฟิลด์
parent อ้างอิง at:// URI ของโพสต์อื่น
- ข้อมูลทั้งหมดใน UI (ผู้เขียน ข้อความ จำนวนไลก์ ฯลฯ) สามารถคำนวณได้จาก ความเชื่อมโยงระหว่างไฟล์เหล่านี้
คลังเก็บข้อมูล (Repository) และการไหลของข้อมูล
- ‘everything folder’ ของผู้ใช้ถูกเรียกว่า คลังเก็บข้อมูล (repository) และระบุด้วย DID
- ภายในจะมีหลาย คอลเลกชัน (collection) และ เรคอร์ด (record)
- คลังเก็บข้อมูลสามารถโฮสต์ไว้ที่ใดก็ได้ และแม้ย้ายที่อยู่ ลิงก์ก็ยังคงเดิม
- แอปสามารถ อ่านคลังเก็บข้อมูลเหมือนระบบไฟล์ หรือ ติดตามผ่านสตรีม (WebSocket) เพื่อซิงก์แบบเรียลไทม์ได้
- แต่ละคอมมิตจะถูกตรวจสอบด้วย ต้นไม้แฮชที่มีลายเซ็น (Merkle tree) เพื่อ ป้องกันการปลอมแปลงข้อมูล
- เซิร์ฟเวอร์รีเลย์ (relay) มีหน้าที่เพียงส่งต่ออีเวนต์ และสร้างความน่าเชื่อถือผ่านโครงสร้างที่ตรวจสอบได้
การสำรวจ Atmosphere และกรณีใช้งานจริง
- pdsls.dev ทำงานคล้าย ตัวสำรวจระบบไฟล์โซเชียล โดยให้ป้อน DID หรือแฮนเดิล
- สามารถดูแต่ละคอลเลกชันและเรคอร์ดได้โดยตรง
- แอปตัวอย่าง Sidetrail สะท้อนการเปลี่ยนแปลงของเรคอร์ดผู้ใช้แบบเรียลไทม์ และแสดงให้เห็นว่า ข้อมูลอยู่ในคลังเก็บ ไม่ได้อยู่ในแอป
- เดโม teal.fm Relay แสดงภาพ ประวัติการเล่นเพลง (scrobble) โดยทำดัชนีเรคอร์ด
fm.teal.alpha.feed.play แม้ไม่มี API จริง
- สามารถใช้เครื่องมือ
lex-gql เพื่อรัน GraphQL query ที่อิง Lexicon ได้
- ใน Bluesky ผู้ใช้สามารถเผยแพร่ อัลกอริทึมฟีดแบบกำหนดเอง ที่สร้างขึ้นเองได้
- ตัวอย่างเช่น ฟีด “For You” ของ
@spacecowboy17.bsky.social ทำงานอย่างอิสระ และทำให้ บุคคลที่สามสามารถปรับปรุงฟังก์ชันบนข้อมูลที่ใช้ร่วมกัน ได้
บทสรุป
- ระบบไฟล์โซเชียลนำเสนอ โครงสร้างอินเทอร์เน็ตที่ยึดข้อมูลเป็นศูนย์กลาง ไม่ใช่แอป
- ผู้ใช้เป็นเจ้าของคลังเก็บข้อมูลของตนเอง และแอปทำงานตอบสนองอยู่บนข้อมูลนั้น
- เป้าหมายคือการเปลี่ยนจาก “แอปที่ทำได้ทุกอย่าง” ไปสู่ “ระบบนิเวศที่ทำได้ทุกอย่าง”
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
แอปอาจหายไปได้ แต่ ไฟล์ยังคงอยู่
จากบทความของ swyx เน้นว่า สิ่งที่อยู่ได้นานท้ายที่สุดจะคงอยู่ในรูปของไฟล์/ข้อมูล
ข้อมูลสามารถถูกพาร์สได้โดยไม่ต้องขอสิทธิ์ และถึงจะเสียหายไปบางส่วนก็ยังมีประโยชน์อยู่ แต่แรงจูงใจทางเศรษฐกิจก็ยังคงหมุนรอบโค้ด
เมื่อมีมาตรฐานเกิดขึ้นและทำให้โค้ดรับและส่งออกข้อมูลได้ มันจะสร้างคุณค่าอย่างมากต่ออารยธรรมโดยรวม
คิดว่าหนึ่งในคันโยกที่ทรงพลังที่สุดที่เรามีคือการทำให้ระบบนิเวศนักพัฒนาชักจูงให้บริษัทอย่าง Google, Microsoft, OpenAI, Anthropic เข้าร่วมมาตรฐานข้อมูลด้วยความสมัครใจ
แต่แอปทุกวันนี้อยู่ในรูปเว็บไซต์ที่พึ่งรายได้จากโฆษณา จึง ไม่มีแรงจูงใจเลย ที่จะทำงานในโครงสร้างแบบนั้น
แค่ดู Apple ก็เห็นแล้วว่ามาตรฐานมักเปลี่ยนโลกไม่ได้
ถ้าฟิลด์ createdAt เป็นค่าที่ตั้งขึ้นเองได้ งั้นก็หมายความว่าฉันสามารถ แก้ไขบันทึกย้อนหลัง ให้เป็นอย่างที่ต้องการได้ไม่ใช่หรือ?
เลยสงสัยว่ามีวิธีตรวจสอบผ่านการลงลายเซ็น (signing) หรือไม่ ว่ามันถูกสร้างขึ้นเมื่อไรและหลังจากนั้นมีการแก้ไขหรือเปล่า
POSSE และ AT Protocol อาจเข้าใจได้ว่าเป็น มาร์เก็ตเพลสที่ทำงานร่วมกันได้
เหมือน Reddit หรือ Instagram ที่คอนเทนต์ของผู้ใช้คือสินค้า ความสนใจ (attention) คือสกุลเงิน และแพลตฟอร์มสร้างรายได้จากโฆษณาหรือข้อมูลพฤติกรรม
แต่โครงสร้างแบบนี้ไม่จำเป็นต้องเป็นสิ่งหลีกเลี่ยงไม่ได้
ถ้าผู้ใช้เป็นเจ้าของ ข้อมูลโซเชียลของตัวเอง แอปก็จะกลายเป็นอินเทอร์เฟซสำหรับอ่านข้อมูลแทน
ฉันเองก็กำลังนำโมเดลคล้ายกันไปใช้กับคอมเมิร์ซ — ให้ผู้ขายโฮสต์ตรรกะคำสั่งซื้อและการชำระเงินของตัวเองโดยตรง แล้วมาร์เก็ตเพลสเชื่อมกับ API ของผู้ขายโดยตรง
แบบนี้จะลดค่าธรรมเนียมแพลตฟอร์มลง และ คืนความเป็นเจ้าของให้กับผู้ที่สร้างคุณค่า
บทความละเอียดมากจนรู้สึกว่าเกินจำเป็นไปนิดสำหรับการสื่อสารประเด็นหลัก
แต่ถึงอย่างนั้น การเปรียบเทียบก็ยอดเยี่ยมมาก ถ้ามี file browser สำหรับ PDS ก็น่าจะลองสัมผัสได้โดยตรง
PDS ของ Bluesky โดยพื้นฐานแล้วเป็น ไฟล์ซิสเต็มสาธารณะ และมีการจำลองข้อมูล (replication) อยู่ในดีไซน์เหมือน Git
การจำลองข้อมูลควบคุมไม่ได้ แต่ก็มีข้อดีคือเป็นการสำรองข้อมูลอัตโนมัติ
ท้ายที่สุด สิ่งที่อัปขึ้น PDS จะเหมือนกลายเป็นบันทึกถาวร จึงควรระวังให้มาก
ถ้ามีประโยชน์แต่ยาวไป คนอื่นก็หยิบแค่ส่วนที่ต้องการไปได้
ที่เดโมส่วนท้ายบทความ มีตัวอย่าง file manager ให้ดูจริง
ประโยคที่ว่า “โลกที่ทุกคนกลายเป็น scraper” คือแก่นสำคัญ
คิดว่าแนวคิดเรื่อง “ไฟล์” นั้นล้าสมัยไปแล้ว
ถ้าปฏิบัติต่อทุกอย่างเป็น ข้อมูล blob แบบอิงแฮช ปัญหาหลายอย่างจะหายไป
สิ่งที่ผู้ใช้ต้องการไม่ใช่แอป แต่คือ ความสามารถ (capability)
เช่น “ความสามารถในการดูวิดีโอโยคะ” หรือ “ความสามารถในการแชร์ความเป็นอยู่กับคนรู้จัก” ไม่ใช่ตัว YouTube หรือ Bluesky เอง
แอปเป็นเพียงรูปแบบที่รวบรวมความสามารถเหล่านี้ไว้ด้วยกัน
เราต้องการ เวิร์กโฟลว์ที่ปรับแต่งได้ เช่น ค้นหาคำในแอปแชต แล้วแชร์ผลลัพธ์นั้นกลับเข้าไปในหน้าต่างสนทนาได้ทันที
ได้แรงบันดาลใจจากPerKeep
ใช้เป็นอุปมาเพื่ออธิบาย “ความสัมพันธ์แบบหลายต่อหลายระหว่างแอปกับฟอร์แมตไฟล์”
ถ้าดูคำอธิบายโครงสร้าง repository ของ ATProto จะเห็นว่าเป็น โครงสร้างแบบ content-addressed บนพื้นฐาน Merkle-tree
Lexicon ก็ไม่ได้มีความสัมพันธ์แบบ 1:1 กับแอป ดังนั้น AT กำลังมุ่งไปสู่ยุค post-app อยู่แล้ว
ฉันคิดว่า แพลตฟอร์มปิด (walled garden) เป็นผลลัพธ์จากความชอบของผู้บริโภค
พออินเทอร์เน็ตเปิดทุกอย่างออกหมด ผู้คนก็กลับต้องการพื้นที่เล็ก ๆ ที่ยึดโยงกับวัฒนธรรมหรือแนวคิดเฉพาะ
IG หรือ Snap ก็เป็นเหมือนกรุ๊ปแชตแบบแยกย่อยเช่นนั้น
กลับรู้สึกดีเสียอีกที่โพสต์ IG ของฉันไม่ได้ถูกแชร์อัตโนมัติไป HN หรือ Truth Social
ยังไม่ค่อยรู้สึกถึงคุณค่าของ data portability เท่าไร การข้ามแพลตฟอร์มที่บริบทต่างกันดูไม่มีความหมาย
Anisota ที่ฉันทำ ถูกออกแบบมาให้รองรับทั้งไฟล์ของ Bluesky และ Leaflet
ตัวอย่างเช่นโพสต์เดียวกันสามารถดูได้ทั้งบนBluesky และAnisota
และยังมีโปรเจ็กต์ชื่อAturi ที่ให้ ลิงก์สากลสำหรับคอนเทนต์บน ATProto
ใน ATProto ถ้าเป็นแอปที่ใช้ Lexicon เดียวกัน ก็สามารถ ย้ายตัวตนและข้อมูลได้อย่างสมบูรณ์
ไฟล์ภาพต้นฉบับก็อยู่ในเครื่องฉันอยู่แล้ว แต่ละแพลตฟอร์มก็เป็นแค่การนำเสนอคนละแบบ
ฉันไม่ต้องการ การรวมข้ามแพลตฟอร์มแบบไร้ความหมาย
AT แค่ทำให้ การทำงานร่วมกันเป็นไปได้ ไม่ได้บังคับให้ทุกอย่างรวมกัน
เช่น Leaflet จะดึงโพสต์ Bluesky มาแสดงเพื่อใช้ติดตามการอ้างอิง
ด้วยโครงสร้างแบบนี้ ต่อให้ fork ผลิตภัณฑ์ ก็ยังเข้ากันได้กับเครือข่ายเดิมอย่างสมบูรณ์ และทำให้การแข่งขันคึกคักขึ้น
ตัวอย่างจริงคือBlacksky ที่ fork Bluesky แล้วใช้ นโยบาย moderation คนละแบบ
บทความที่ Dan เขียนน่าสนใจเสมอ อ่านไปสักพักก็จะรู้เองว่าสุดท้ายผู้เขียนคือเขา
ฉันค่อนข้างสงสัยกับ โมเดลข้อมูลแบบอธิบายตัวเองได้ (self-describing data model)
คำกล่าวของ ATProto ที่ว่า “แค่เพิ่ม Lexicon ก็มีไคลเอนต์เกิดขึ้นได้” ฟังดูเกินจริง
ในความเป็นจริง ถ้าจะทำ UI ก็ต้องเข้าใจความหมายของข้อมูล และ Lexicon อย่างเดียวไม่พอ
สุดท้ายก็แทบไม่ต่างจากการอ่านเอกสารแล้วลงมือทำเอง
มาตรฐานเป็นเรื่องดี แต่ก็ไม่ใช่ปัญหาระดับฐานข้อมูลที่ต้องถูกจำลองไปทั่วโลกเสียทีเดียว
ถึงอย่างนั้นก็ชื่นชมความพยายามที่จะลด lock-in
เพียงแต่ปัญหาจริงที่ Twitter เจอคือ ปัจจัยทางสังคม อย่างคอนเทนต์การเมืองหรือสแปม
แต่ถ้าบริการที่คนรักอย่าง Bento หายไป ก็ย่อมมีใครสักคนพยายามกู้ข้อมูลนั้นกลับมา
อย่างเช่นBlento คือบริการทดแทน Bento บน ATProto ซึ่งเป็นโอเพนซอร์สและใครก็เอาไปตั้งใหม่ได้
โครงสร้างแบบนี้เป็นความก้าวหน้าที่มีความหมายในการรับประกัน ความคงอยู่ของคอนเทนต์ผู้ใช้
ตอนอ่าน “The Unix Programming Environment” ก็รู้สึกว่า แค่มีเครื่องมือเรียบง่ายกับไฟล์ข้อความก็ทำอะไรได้มากมาย
เลยอดจินตนาการไม่ได้ว่า Slack จะเป็นอย่างไรถ้าถูกสร้างขึ้นด้วยแนว UNIX แบบยึดไฟล์เป็นศูนย์กลาง
อยากกลับไปสู่ ระบบที่เรียบง่ายและประกอบรวมกันได้
การซีเรียลไลซ์ที่มนุษย์อ่านง่ายนั้นดี แต่การต้องพาร์สและฟอร์แมตใหม่ทุกครั้งเป็นเรื่องทรมาน
แนวคิดที่แพลตฟอร์มโซเชียลใหม่ ๆ จะ แชร์โปรโตคอลและฟอร์แมตข้อมูลร่วมกัน ในสภาพแวดล้อมแบบกระจายศูนย์/เฟเดอเรชันนั้นน่าสนใจ
แต่ก็ดูยากที่จะโน้มน้าวแพลตฟอร์มเชิงพาณิชย์เดิม ๆ
ถ้ามาตรฐานแบบนี้ตั้งหลักได้ เครื่องมือ social marketing ก็น่าจะจัดการหลายเครือข่ายพร้อมกันได้ง่ายขึ้น
แต่ในความเป็นจริง ทุกวันนี้ยังเป็น ระบบนิเวศแบบปิด อย่าง Facebook, Instagram, TikTok ที่ครองอยู่