- เช่นเดียวกับที่ โอเพนซอร์ส กลายเป็นมาตรฐานของโครงสร้างพื้นฐานซอฟต์แวร์ ตอนนี้ แนวคิด 'โซเชียลแบบเปิด' สำหรับแอปโซเชียล ก็กำลังเกิดขึ้น
- AT Protocol ทำให้ผู้ใช้สามารถเป็นเจ้าของและควบคุมข้อมูลโซเชียลของตนเองได้โดยตรง และนำเสนอแนวคิดที่แตกต่างจากแพลตฟอร์มโซเชียลแบบเดิม
- ข้อมูลโซเชียล จะไม่ถูกขังอยู่ภายในบริการใดบริการหนึ่งอีกต่อไป แต่ถูกเก็บไว้ในพื้นที่จัดเก็บส่วนบุคคลที่ผู้ใช้ดูแลเอง
- สิ่งนี้ทำให้ สามารถนำข้อมูลข้ามแอปกลับมาใช้และรีมิกซ์ได้ และแม้บริการจะปิดตัวลง ข้อมูลก็ไม่หายไปแต่ยังคงอยู่ต่อ
- เมื่อโซเชียลแบบเปิดแพร่หลายมากขึ้น สิทธิความเป็นเจ้าของข้อมูลที่ขับเคลื่อนโดยผู้ใช้และความสามารถในการขยายตัวอย่างยืดหยุ่น จะกลายเป็นคุณค่าหลัก
บทนำ: ความสำเร็จของโอเพนซอร์สและกระแสใหม่
- แม้ในอดีต โอเพนซอร์ส จะเผชิญแรงต้านมากมาย แต่วันนี้มันได้กลายเป็นรากฐานของโครงสร้างพื้นฐานร่วมไปแล้ว
- ต่างจากในอดีต ปัจจุบันการเลือกใช้โอเพนซอร์สไม่ใช่ปัญหาอีกต่อไป และในซอฟต์แวร์สาขาสำคัญต่างๆ โอเพนซอร์สได้กลายเป็นตัวเลือกเริ่มต้น
- ตอนนี้เรากำลังเผชิญ จุดเปลี่ยนในวงการแอปโซเชียลที่คล้ายกับโอเพนซอร์สเมื่อ 35 ปีก่อน
- กระแสใหม่นี้คือ 'โซเชียลแบบเปิด' และ AT Protocol ของ Bluesky ถูกมองว่าเป็นการนำไปใช้ที่น่าเชื่อถือที่สุด
โครงสร้างพื้นฐานของเว็บและการเป็นเจ้าของข้อมูลส่วนบุคคล
- ในอดีตบนเว็บ ผู้คนมีที่อยู่ส่วนตัวอย่าง
alice.com, bob.com และ ผู้ใช้แต่ละคนเป็นเจ้าของพื้นที่ของตนเอง พร้อมเผยแพร่เนื้อหาได้อย่างอิสระบนพื้นที่นั้น
- หากไม่พอใจกับผู้ให้บริการโฮสติ้ง ก็สามารถย้ายไปที่อื่นได้โดย ที่อยู่เดิมยังคงเหมือนเดิม และลิงก์เก่าก็ไม่ขาดหาย
- ด้วยเหตุนี้ ผู้ใช้จึง ไม่ต้องผูกติดกับผู้ให้บริการโฮสติ้งรายใดรายหนึ่ง และผู้ให้บริการต้องแข่งขันกันเอง
- กล่าวคือ ด้วยการออกแบบแบบกระจายศูนย์ของเว็บ ผู้ใช้ถือครองข้อมูล ส่วนผู้ให้บริการมีบทบาทเป็นเพียงผู้ให้บริการเท่านั้น
โซเชียลเน็ตเวิร์กยุคใหม่: การสูญเสียความเป็นเจ้าของข้อมูล
- ทุกวันนี้ แทนที่จะดูแลเว็บไซต์ของตัวเอง ผู้คนมักได้รับไอดีอย่าง
@alice, @bob จากบริษัทแล้วโพสต์ลงใน แอปโซเชียลมีเดีย
- ข้อมูล เช่น โพสต์ คอมเมนต์ และการกดถูกใจ ถูกเก็บไว้ในฐานข้อมูลของบริษัทโซเชียลรายใดรายหนึ่ง
- โครงสร้างลักษณะนี้ทำให้เกิด ความสามารถในการรวบรวมเชิงสังคม เช่น การค้นหา ฟีด คำแนะนำ และการแจ้งเตือน
- แต่ในขณะเดียวกันก็เกิดผลข้างเคียงคือ ข้อมูลสำคัญไม่ใช่ของเราอีกต่อไป
- ผู้ใช้จึงตกอยู่ในสถานการณ์ที่ ไม่สามารถพกพาข้อมูลและความสัมพันธ์ที่ตัวเองสร้างขึ้นออกไปได้อย่างอิสระ
ปัญหา: ผู้ใช้ถูกขังอยู่ในแพลตฟอร์ม
- เมื่อผู้ใช้ย้ายออกไป พวกเขาต้อง ทิ้งสายสัมพันธ์ทั้งหมดที่ตัวเองสร้างไว้เบื้องหลัง
- ไม่สามารถเปลี่ยนผู้ให้บริการโฮสติ้งได้ง่าย และ เมื่อออกจากแพลตฟอร์มก็สูญเสียทั้งความเชื่อมโยงและข้อมูลไปพร้อมกัน
- เพราะแพลตฟอร์มรู้เรื่องนี้ ผู้ใช้จึงต้องทนกับ การเปลี่ยนแปลงที่เสียเปรียบ (โฆษณาล้นเกิน อัลกอริทึมบิดเบือน ตัดฟีเจอร์ออก เป็นต้น)
- แม้จะสำรองหรือส่งออกข้อมูลได้ แต่นั่นก็เป็นเพียง 'ข้อมูลตาย' ที่สูญเสียบริบททางสังคมไปแล้ว จึงยากจะทำให้กลับมามีชีวิตในที่อื่น
โซเชียลแบบเปิด: การกู้คืนความเป็นเจ้าของข้อมูลและเครือข่าย
- ในโซเชียลแบบเปิด ผู้ใช้จะได้รับ ความเป็นเจ้าของข้อมูลโซเชียลอย่างแท้จริง ผ่านแฮนเดิลที่อิงโดเมนอย่าง @alice.com
- ชื่อจะเชื่อมกับ โดเมนที่ฉันเป็นเจ้าของ เช่น
@alice.com
- ผู้ใช้บริหารจัดการข้อมูลโซเชียลทั้งหมดที่สร้างขึ้นด้วยตนเองผ่าน คลังเก็บส่วนบุคคล (repository)
- กิจกรรมอย่างการเขียนโพสต์ การแสดงความคิดเห็น หรือการติดตาม จะถูกบันทึกไว้ใน คลังเก็บส่วนบุคคล (repo)
- คลังเก็บเป็นเพียงเว็บเซิร์ฟเวอร์ธรรมดาที่เก็บบันทึกในรูปแบบ JSON
- ที่อยู่จะอยู่ในรูปแบบ
at://alice.com/... จึงสามารถเชื่อมโยงถึงกันได้
- คลังเก็บที่อิง AT Protocol ทำงานบน DNS, HTTP และ JSON โดย แต่ละข้อมูลถูกจัดเก็บในรูปแบบ JSON ที่เชื่อมโยงกันด้วยไฮเปอร์ลิงก์
- แม้คนที่ไม่รู้เทคโนโลยี เมื่อสมัครแอปก็จะมีการสร้างคลังเก็บให้โดยอัตโนมัติ ทำให้ข้อมูล ยังคงเป็นของผู้ใช้โดยไม่ขึ้นกับแอป
- ข้อมูลเป็นของคลังเก็บของผู้ใช้ ดังนั้นแม้ผู้ให้บริการจะเปลี่ยนไป ความเป็นเจ้าของข้อมูลและความเชื่อมโยงก็ยังคงอยู่
โครงสร้างและการประยุกต์ใช้ของแอปโซเชียลแบบเปิด
- แอปโซเชียลแบบเปิดแต่ละตัวทำหน้าที่ คล้าย CMS โดยจัดการข้อมูลบางส่วนในคลังเก็บโซเชียลของผู้ใช้ และตอนนี้แอปก็เป็นเพียง เครื่องมือสำหรับอ่านและเขียนลงในคลังเก็บของผู้ใช้ เท่านั้น
- ตัวอย่างเช่น ข้อมูลจากแอปต่างๆ อย่าง Bluesky, Tangled และ Leaflet สามารถ อยู่ร่วมกันในคลังเก็บของผู้ใช้คนเดียวกัน ได้
- หากเขียนโพสต์ใน Bluesky ก็จะมีบันทึกอยู่ในคลังเก็บของฉัน และหากกดดาวโปรเจ็กต์ใน Tangled ข้อมูลนั้นก็จะถูกเก็บเข้าไปในคลังเก็บของฉันเช่นกัน
- รูปแบบข้อมูลถูกแยกด้วย namespace (เช่น app.bsky.post, sh.tangled.star เป็นต้น) เพื่อป้องกันการชนกัน
- เมื่อเวลาผ่านไป คลังเก็บของฉันจะกลายเป็นชุดรวมของข้อมูลที่มาจากหลายแอป
การเปลี่ยนแปลงของระบบนิเวศจากการเปิดข้อมูล
- เนื่องจากข้อมูล ถูกจัดเก็บอย่างเปิดกว้าง การผสานรวมข้ามแอป การพัฒนาบริการใหม่ การอ้างอิงข้อมูลของกันและกัน การนำกลับมาใช้ และการรีมิกซ์ จึงทำได้ง่ายขึ้น
- แม้แอปจะยุติบริการ ข้อมูลก็ยัง คงอยู่ในคลังเก็บของผู้ใช้และสามารถนำไปใช้ซ้ำในบริการอื่นได้
- แอปใหม่สามารถใช้ความสัมพันธ์และข้อมูลจากเครือข่ายเดิมเพื่อ เอาชนะปัญหา 'cold start' (ปัญหาการสร้างเครือข่ายเริ่มต้น)
- เนื่องจากข้อมูลนี้ใครก็อ่านได้ แอปอื่นจึงสามารถดึงไปใช้เพื่อ โหลดรูปโปรไฟล์ หรือใช้ความสัมพันธ์การติดตามเดิมได้ทันที
- แม้แอปจะปิดตัว ข้อมูลก็ยังอยู่ในคลังเก็บของผู้ใช้ และแอปอื่นสามารถดึงกลับมาใช้ได้อีก
การรวมศูนย์ข้อมูล (aggregation) และความท้าทายทางเทคนิค
- แม้ว่าข้อมูลของผู้ใช้จะกระจายอยู่ในคลังเก็บของแต่ละคน แต่ก็สามารถรับ สตรีมเหตุการณ์การเปลี่ยนแปลงข้อมูลผ่านการสมัครรับ WebSocket แล้วสะท้อนลงในฐานข้อมูลท้องถิ่นได้
- สามารถรับเหตุการณ์ของทั้งเครือข่ายผ่านรีเลย์ขนาดใหญ่ (เซิร์ฟเวอร์ตัวกลาง) และกรองเฉพาะเหตุการณ์ที่ต้องการ
- เรคคอร์ดข้อมูลจะถูก ลงลายเซ็นเข้ารหัสเพื่อรับประกันความน่าเชื่อถือและความสอดคล้อง
- ตัวอย่างเช่น โครงสร้างพื้นฐานอย่าง Graze, Slices รองรับการรวมข้อมูลของโซเชียลแบบเปิด
แล้วฟังก์ชัน aggregation ทำงานอย่างไร?
- แม้คลังเก็บของผู้ใช้แต่ละคนจะแยกจากกัน แอปก็จะรับ สตรีมเหตุการณ์แบบเรียลไทม์ ที่ออกมาจากคลังเก็บของผู้ใช้ แล้วบันทึกลงในฐานข้อมูลของตัวเอง
- รีเลย์อย่าง Bluesky จะรวบรวมสตรีมทั้งหมดแล้วส่งต่อให้ และแอปจะเลือกเก็บเฉพาะเหตุการณ์ที่ตัวเองสนใจ
- ฐานข้อมูลที่สะสมขึ้นด้วยวิธีนี้สามารถให้บริการฟังก์ชันอย่างการค้นหา ฟีด และคำแนะนำได้อย่างรวดเร็ว
- เรคคอร์ดข้อมูลจะถูก ลงลายเซ็นเข้ารหัสเพื่อรับประกันความน่าเชื่อถือและความสอดคล้อง : ต่อให้ไม่ต้องเชื่อรีเลย์ ก็ยังตรวจสอบความถูกต้องของข้อมูลได้
- โครงสร้างพื้นฐานอย่าง Graze, Slices รองรับการรวมข้อมูลของโซเชียลแบบเปิด
ภาพรวมใหญ่
- เว็บในอดีต: ผู้ใช้ถือครองทั้งเนื้อหาและที่อยู่ของตนเอง
- แอปโซเชียลในปัจจุบัน: มีฟังก์ชัน aggregation แต่ข้อมูลถูกผูกไว้ในฐานข้อมูลของบริษัท
- โซเชียลแบบเปิด: ยังคงฟังก์ชัน aggregation ไว้ แต่ข้อมูล ยังอยู่ในมือผู้ใช้
- แอปเปลี่ยนบทบาทเป็นเพียง หน้าต่างที่รวบรวมและแสดงข้อมูลของผู้ใช้
- แม้บริการจะหายไป ข้อมูลก็ยังคงอยู่ และแอปอื่นสามารถนำไปแสดงใหม่ในบริบทใหม่ได้
บทสรุป
- แก่นสำคัญของโซเชียลแบบเปิดคือการผสานข้อดีของ เว็บส่วนบุคคล (การเป็นเจ้าของข้อมูล อิสระในการโฮสต์ การคงอยู่ของลิงก์) เข้ากับจุดแข็งของ เครือข่ายโซเชียลแบบปิด (aggregation, scalability)
- โซเชียลแบบเปิดรับประกัน ความเป็นเจ้าของข้อมูลที่ขับเคลื่อนโดยผู้ใช้ การเคลื่อนย้ายข้อมูลข้ามแอปอย่างอิสระ และความต่อเนื่องของบริการ
- เช่นเดียวกับที่ โอเพนซอร์ส เคยบอกว่า "โค้ดควรเป็นของผู้ใช้" ก็เช่นกัน "ข้อมูลควรเป็นของผู้ใช้"
- มันช่วยแก้ปัญหาที่ผู้ใช้สูญเสียข้อมูลและความเชื่อมโยงในแพลตฟอร์มแบบปิด
- หากมีผลิตภัณฑ์โซเชียลแบบเปิดเพิ่มขึ้นอีก เส้นแบ่งระหว่างแอปจะพร่าเลือน และระบบนิเวศที่ข้อมูลไหลเวียนอย่างเป็นธรรมชาติระหว่างกัน จะค่อยๆ เกิดขึ้น
- ท้ายที่สุด อาจมาถึงอนาคตที่ผู้ใช้สามารถ ควบคุมข้อมูลและเครือข่ายได้อย่างแท้จริง
- ในระยะแรก อาจเป็นกลุ่มนักพัฒนาและผู้ใช้ที่กระตือรือร้นจำนวนไม่มากที่ขับเคลื่อน แต่เมื่อฐานร่วมถูกสร้างสะสมขึ้น แนวทางแบบเปิดก็มีโอกาสจะชนะในสักวันหนึ่ง
- แม้จะไม่เข้าใจแนวคิดทางเทคนิคอย่างการกระจายศูนย์หรือสหพันธรัฐ ก็ยังรับรู้ถึง ประโยชน์ที่จับต้องได้ (การเชื่อมโยงข้อมูล การย้ายที่ง่าย ความต่อเนื่อง) ได้
- โซเชียลแบบเปิดจะค่อยๆ ขยายตัวผ่าน ความพยายามระยะยาวและผลสะสมจากชุมชนที่ขับเคลื่อนด้วยความหลงใหล
3 ความคิดเห็น
Instagram ก็เป็นที่เก็บความทรงจำเหมือนกันก็จริง แต่ดูเหมือนว่าจะหนีออกมาได้ยากตามใจตัวเองนะครับ
ในแง่ของการแชร์และการใช้งานข้อมูล ก็รู้สึกว่าเป็นส่วนที่คงต้องยอมกันอยู่บ้างเหมือนกันครับ
KakaoTalk... บ้าเอ๊ย
ความคิดเห็นจาก Hacker News
ตอนแรกฉันคิดว่า AT Protocol เป็นระบบของ Bluesky ก็เลยนึกว่าเป็นเวอร์ชันองค์กรของ ActivityPub แต่พออ่านบทความนี้แล้วกลับชอบวิธีที่ข้อมูลถูกเก็บไว้ใน 'repository' ที่ฉันเลือกเองมากทีเดียว มันสอดคล้องกับหลักคิดทั่วไปของฉันด้วย คือฉันเชื่อว่าการทำ filtering และอย่างอื่นฝั่งอ่าน ดีกว่าการไปบังคับตั้งแต่ตอนเขียน ดังนั้นการที่ฉันสามารถใส่ทุกอย่างที่ต้องการไว้ใน repository ของตัวเอง แล้วให้คนอื่นมาอ่านและใช้งานต่อได้ จึงเป็นโครงสร้างที่ดี แม้ว่าลูกศรในภาพจะดูเหมือนคอมเมนต์ถูกเก็บเข้า repository ของฉัน แต่ก็น่าจะเป็นเพียงความคลาดเคลื่อนเล็กน้อยจากการพยายามอธิบายไอเดีย โดยรวมแล้วรู้สึกว่ามันเป็นสถาปัตยกรรมที่เจ๋งและกระจายศูนย์มาก อย่างไรก็ดี พอลองรัน PDS แยกเองจริง ๆ ก็พบว่าแม้จะลื่นไหลและแพ็กมาอย่างดี แต่ก็ยังมีข้อกำหนดบางอย่าง:
น่าจะเป็นเพราะฉันใช้ลูกศรสองแบบจนทำให้สับสน ลูกศรเส้นทึบ (ที่ลงมาจาก @alice.com) หมายถึงความเป็นเจ้าของ ซึ่งตรงกับการจัดกลุ่มด้วยสีด้วย คือสีน้ำเงินทั้งหมดเป็นของ Alice ส่วนลูกศรเส้นประคือ link ระหว่าง record ซึ่งเหมือนกับ
<a href>ทุกประการ กล่าวคือ record ใด ๆ ก็สามารถลิงก์หา record อื่นใน repository ไหนก็ได้อย่างอิสระ ถ้าใครมาคอมเมนต์โพสต์ของฉัน คอมเมนต์นั้นจะถูกเก็บใน repository ของคนคอมเมนต์ และมีการสร้างลิงก์ไปยังโพสต์ต้นฉบับ เหตุผลที่ออกแบบ data model แบบนี้ก็เพื่อให้คนที่ทำ indexing ถ้ามีทั้งสอง record อยู่แล้ว จะสามารถกู้ความสัมพันธ์กลับมาได้ง่าย ตัวอย่างเช่น ถ้า Bob ไปคอมเมนต์โพสต์ของ Alice คอมเมนต์ของ Bob จะอยู่ใน repository ของ Bob ส่วนโพสต์ของ Alice ก็อยู่ใน repository ของ Alice ถ้ามีใครคอมเมนต์โพสต์ของฉัน คอมเมนต์นั้นจะอยู่ใน repository ของคนนั้นเสมอ หลักสำคัญคือไม่สามารถสร้าง record ลงใน repository ของคนอื่นได้แพ็กเกจ PDS เริ่มต้นรองรับการจัดการ SSL อัตโนมัติ แต่ไม่ใช่ข้อบังคับ เป็นเพียงสิ่งที่ทำไว้ให้ใช้งานง่ายสำหรับนักพัฒนา at:// URI จะอยู่ในรูป at://DID/... และ handle ที่คนอ่านได้จะถูกแมปไปยัง DID ผ่าน DNS TXT record (_atproto.roshangeorge.dev) โดย DID จะลิงก์ไปยังเอกสารที่ระบุตำแหน่งของเซิร์ฟเวอร์ ทำให้สามารถวางเส้นทาง HTTPS/WSS ไว้ที่ไหนก็ได้ นอกจากนี้ like, reply และอื่น ๆ ที่เกิดกับโพสต์ของฉัน จะถูกเก็บใน repository ของผู้ที่กระทำ ไม่ได้เข้า repository ของฉัน สัญชาตญาณของคุณในจุดนี้ถูกต้องแล้ว
ฉันเคยคิดว่า ActivityPub เป็นโปรโตคอลที่ดีกว่า และ AT ก็เป็นแค่ของเลียนแบบราคาถูก แต่พออ่านบทความนี้แล้วก็รู้ว่า AT ดีกว่ามาก จุดสำคัญคือหลายโปรแกรมสามารถแชร์อัตลักษณ์เดียวกันได้ นี่เป็นฟีเจอร์ที่ยอดเยี่ยมจริง ๆ และทำให้มุมมองกว้างขึ้นมาก
คำอธิบายเกี่ยวกับ ATProto ส่วนใหญ่มักเน้นเรื่องความเป็นเจ้าของข้อมูล แต่ในทางปฏิบัติ ActivityPub แข็งแกร่งกว่าในส่วนการประมวลผลข้อมูล ATProto มีโครงสร้างที่มองโลกทั้งใบแบบสาธารณะ ทำให้ทุก event ต้องปรากฏต่อ AppServer ส่วนกลางที่เชื่อถือได้และต้องตัดสินเอง ดังนั้นการสร้าง feed การกำหนดสิทธิ์เข้าถึง ฯลฯ จึงต้องพึ่งตัวกลางที่ไว้ใจได้ ในทางกลับกัน ActivityPub กลับคล้าย RSS หรืออีเมลมากกว่า คือเซิร์ฟเวอร์ของฉันจัดการเฉพาะ feed ที่ฉัน subscribe และ inbox ก็ประกอบขึ้นจากโพสต์ที่ฉันเข้าถึงได้โดยตรง นี่เองคือเหตุผลว่าทำไมใน Bluesky ถึงทำ "like แบบ private" เหมือน Twitter ไม่ได้ เพราะแต่ละ AppView ต้องติดตามจำนวน like ของทุกโพสต์ในเครือข่ายด้วยตัวเอง ซึ่งยุ่งยากมาก ในระยะยาวฉันคิดว่าโครงสร้างของ ActivityPub จะได้เปรียบกว่า และเรื่อง “หลายโปรแกรมแชร์อัตลักษณ์เดียวกัน” นั้น จริง ๆ ก็มีอยู่ในการออกแบบ ActivityPub ยุคแรกเช่นกัน เพียงแต่ implementation แรก ๆ ที่ได้รับความนิยม ตัดฟีเจอร์นี้ออกเพื่อให้เข้ากับโครงสร้างเดิม
ประเด็น AT vs AP นั้นซับซ้อนมาก ในชุมชนของเราก็ถกกันหลายครั้งแล้ว เลยขอทิ้งเธรดที่น่าอ้างอิงไว้: https://github.com/bevyengine/bevy/discussions/18302
ดีใจที่ประเด็นนี้โดนใจคุณ ฉันมักหงุดหงิดเวลาถูกเอาไปเทียบกับ AP ตลอด เพราะ scope ของมันต่างกันโดยสิ้นเชิง
ถ้าสนใจ มุมมองคล้ายกันจากสายวิศวกร distributed systems ก็น่าอ่านเหมือนกัน: https://atproto.com/articles/atproto-for-distsys-engineers
ถ้าอย่างนั้นแปลว่ามีบริการอัตลักษณ์แบบรวมศูนย์อยู่หรือเปล่า?
ไม่ว่าโปรโตคอลกระจายศูนย์แบบไหนจะชนะก็ไม่สำคัญ แต่แม้ ATProtocol จะดูดีในทางทฤษฎี ในการใช้งานจริงฉันกลับรู้สึกว่า ActivityPub น่าสนใจกว่ามากขึ้นเรื่อย ๆ ฉันใช้งาน Lemmy บ่อยและมันค่อนข้างคึกคักกับสนุก
ต่างจาก Mastodon ตรงที่ใน AT แนวคิดเรื่อง instance นั้นต่างออกไป ภายในโครงสร้างพื้นฐานของ Bluesky เองก็มี PDS หลายตัว และการทำงานเชิงโครงสร้างก็เป็นอีกแบบหนึ่ง (ดูบทความที่เกี่ยวข้อง) การเรียกมันว่าเป็น instance ที่ครอบงำเพียงตัวเดียวน่าจะไม่ถูกนัก แน่นอนว่าความกังวลเรื่องบริษัทจะชี้นำโปรโตคอลตามใจนั้นเป็นเรื่องจริงจัง แต่จนถึงตอนนี้ก็ถือว่าพวกเขาทำหน้าที่ steward ได้ดี และน่าจะแก้ได้ทีละน้อยเมื่อ ecosystem เติบโตขึ้น อีกอย่าง ความกังวลว่า Bluesky จะปิดบริการแล้วอพยพไม่ได้ ก็มีคำตอบอยู่แล้ว เพราะตัว protocol ฝังเรื่อง backup และ migration มาในตัว ขอแค่มีไฟล์ CAR ก็ย้ายไปโฮสต์อื่นได้ทุกเมื่อ Mastodon มีข้อมูลสูญหายเยอะเวลาย้ายบัญชี แต่ atproto ย้ายได้แบบโปร่งใส 100%
สุดท้ายไม่ว่าจะ Bluesky หรือ Mastodon พอเข้าไปแล้วก็เห็นแต่เรื่องการเมืองอเมริกัน ฉันไม่ค่อยชอบละครการเมืองรายสัปดาห์เท่าไร เลยรู้สึกว่าแพลตฟอร์มที่หลากหลายกว่าอย่าง Tumblr, Pinterest หรือ TikTok น่าจะเหมาะกับฉันมากกว่า
Mastodon ไม่ได้เท่ากับ ActivityPub แบบสมบูรณ์ แต่ฉันไม่ค่อยไว้ใจเพราะ reply มันหาย ๆ โผล่ ๆ บางโพสต์อยู่ดี ๆ ก็เห็นแล้วก็หายไป นี่เป็นหนึ่งในสองเหตุผลที่ฉันเลิกใช้ Mastodon
ฉันรู้สึกเสียดายนิดหน่อยตรงที่แต่ละแอปใช้ collection type ของตัวเอง และแม้จะแชร์ collection กันได้ ก็ยังไม่ชัดเจนว่าสุดท้ายแอปต่าง ๆ จะทำงานร่วมกันได้แค่ไหน ความงามอย่างหนึ่งของ ActivityPub คือผู้ใช้ Mastodon สามารถ subscribe ผู้ใช้ Pixelfed ได้โดยแทบไม่ต้องคิดอะไรเป็นพิเศษ มันให้ความรู้สึกเหมือน Twitter, Instagram, Reddit, YouTube และ Substack เชื่อมถึงกันอัตโนมัติโดยไม่ต้องตั้งค่าอะไร
โดยพื้นฐานแล้ว AP ทำงานร่วมกันได้ดีระหว่างหลายบริการใน type อย่าง Status และ Question ซึ่ง Mastodon, Pixelfed, Misskey, Pleroma และอื่น ๆ ต่างก็หมุนรอบระบบนี้ แต่การรองรับ type อื่นมีจำกัดมาก ทำให้คอนเทนต์ประเภทอื่นไม่ค่อยได้รับการรองรับอย่างเหมาะสม ปัญหาคือชุมชนขาดการจัดระเบียบสำหรับส่วนขยายที่อยู่นอกมาตรฐาน ATproto บังคับให้ data collection ต้องอิงตามนิยาม lexicon/schema และทั้ง reference implementation กับ third-party implementation ก็มีการตรวจสอบความถูกต้องของ schema ให้ด้วย จึงทำให้ความเข้ากันได้พื้นฐานมีโครงสร้างที่ชัดเจนกว่า แต่ในอีกด้านหนึ่ง ฉันก็คิดว่าควรเปิดให้มีการรองรับแบบเลือกใช้สำหรับฟิลด์เสริมบางอย่างได้ เพื่อเพิ่มความยืดหยุ่น ตัวอย่างเช่นข้อมูลจาก APub ที่เข้ามาผ่าน Bridgy Fed ก็มีการแนบ metadata อย่าง URL ต้นฉบับ ข้อความ ฯลฯ มาด้วย (https://fed.brid.gy/docs#bluesky-fields)
กำลังมีความพยายามในการปรับปรุง lexicon กลางอยู่ที่: https://github.com/lexicon-community
ฉันเริ่มรู้สึกว่าโปรเจกต์ที่ประกาศตัวว่าเป็น "Twitter ยุคถัดไป" หลายเจ้า แก้ปัญหาคลาดเป้าไปคนละนิด หลังจากทำฟีเจอร์แบบ Twitter ได้ครบแล้ว ก็ยังไปติดปัญหาเรื่องผู้ใช้กับคอนเทนต์ไม่พออยู่ดี ซึ่งเป็นปัญหา chicken-and-egg สุดท้ายผู้คนก็ไปอยู่ตรงที่มีคนเยอะ และตอนนี้ที่นั่นก็ยังเป็น Twitter ฉันกลับมองว่าทิศทางแบบ timeline ที่ OpenAI เพิ่งเปิดตัวเมื่อไม่นานนี้ ซึ่งเน้นเก็บข้อมูลไว้เบื้องหลังก่อนแล้วค่อยส่งต่อให้ผู้ใช้ น่าจะดูเข้าท่ากว่า แม้ implementation อาจต่างกัน แต่ทิศทางนั้นดูถูกต้อง ผู้ใช้ส่วนใหญ่ไม่ได้ให้คุณค่ากับการเขียนทวีตมากนัก คุณค่าจริงอยู่ที่การบริโภคข้อมูลและการหาแหล่งคอนเทนต์ จากมุมนี้ ฉันคิดว่า multi-social RSS reader + ตัวเลือกแบบ P2P เป็นแนวทางที่ดีกว่า นี่เป็นความเห็นส่วนตัว
อย่างที่บทความอธิบายไว้ การใช้ microblogging ในช่วงแรกเป็นเพียง framing เบื้องต้น แต่จริง ๆ แล้วมันรองรับรูปแบบอื่นได้มากกว่านั้น ตัวอย่างเช่น Tangled คือ "Github on atproto" และ Leaflet คือ "Medium on atproto" ข้อจำกัดของแนวทาง P2P ฝั่ง client คือยากที่จะรับประกัน aggregation ขนาดใหญ่และความสม่ำเสมอ ซึ่งเป็นพื้นฐานที่ผู้ใช้ทั่วไปคาดหวังจากแอปโซเชียลส่วนใหญ่ ตัวอย่าง OpenAI ก็เป็นจุดที่ atproto แข็งแรงอยู่แล้ว เพราะข้อมูลมีอยู่ในเครือข่ายตั้งแต่แรก จึงต่อกับเครื่องมือ crawl, index และ automation ได้ง่าย ตัวอย่างระยะแรกดูได้ที่ https://github.com/graze-social/iftta
โซเชียลเน็ตเวิร์กจะเติบโตไม่ใช่เพราะ “เหมือนเดิมแต่เพิ่มอีกนิด!” แต่เพราะมีรูปแบบใหม่ที่ทำสิ่งซึ่งแพลตฟอร์มก่อนหน้าไม่เคยทำได้
เพราะแบบนี้ Nostr ถึงแตกต่าง! จะทำเป็นบล็อก, คล้าย Twitter, บริการสตรีมมิง, เมสเซนเจอร์ หรืออะไรก็ได้ ตัวอย่างรวมอยู่ที่: https://nostrapps.com
ฉันสงสัยว่าโดเมนระดับบนสุดฟรี (TLD) จะเป็นไปได้ไหม ต้นทุนที่แท้จริงของการจดโดเมนคืออะไร? พอนึกถึง Let's Encrypt ที่แจกใบรับรองฟรี ก็อดสงสัยไม่ได้ว่าทำไมองค์กรไม่แสวงหากำไรจะให้โดเมนฟรีไม่ได้บ้าง ไม่จำเป็นต้องสวยงามก็ได้ จะซ้อน UUID v7 หลายชุดก็ยังได้ ขอแค่ไม่ซ้ำกันทั่วโลกและฟรีก็พอ เบราว์เซอร์จำได้อยู่แล้วหลังจากเข้าใช้งาน ดังนั้นแม้ URL จะยาวก็คงไม่ใช่ปัญหา ไอเดียนี้มันแย่ขนาดนั้นเลยหรือ?
ใน atproto หน้าที่นี้เป็นของ did:plc สามารถออก ID ฟรีได้ที่ https://web.plc.directory/ ตัวอย่างเช่น ID ของฉันคือ https://plc.directory/did:plc:3danwc67lo7obz2fmdg6jxcr และสามารถผูกเข้ากับ did:plc นั้นผ่าน TXT record ของโดเมนได้
TLD ฟรีนั้นในทางปฏิบัติทำได้ยากมาก ทั้ง TLD และ public suffix list มีข้อกำหนด ค่าใช้จ่าย และความซับซ้อนด้านการดูแลหลายอย่าง ดูได้ที่ https://github.com/publicsuffix/list อย่างไรก็ตาม ถ้าไม่ใช่ TLD แต่เป็นโดเมนทั่วไป ก็สามารถใช้งานได้อย่างอิสระ และจะแจก subdomain ฟรีก็ยังทำได้เช่นกัน แต่พอรันบริการจริง คุณจะเจอกับการถล่มจาก spam/phishing และสิ่งมืดมนของอินเทอร์เน็ตอย่างรวดเร็ว จนเริ่มเสียใจที่เปิดบริการ เรื่องนี้ก็เหมือนกับที่ใคร ๆ ก็ทำ URL redirector ได้ แต่การดูแลให้ใช้งานจริงนั้นเป็นอีกเรื่อง พอทำจริงเดี๋ยวก็เจอปัญหา นี่คือความจริงที่น่าเสียดาย
มันแทบจะเหมือนกับการแจก IPv6 address ทุกวันนี้อินเทอร์เน็ตบ้านส่วนใหญ่ได้ public IPv6 ระดับ /64 กันแล้ว แต่ ISP ส่วนมากบล็อกพอร์ตด้วยไฟร์วอลล์ ทำให้ใช้งานจริงลำบาก แถมถ้าเปลี่ยน ISP ก็มักเสีย address ไปอีก ถ้าจะทำให้มันเป็น IPv6 address แบบถาวรและพกพาได้จริง ก็ต้องแจก provider-independent address space ให้บุคคลทั่วไปฟรี และเชื่อมมันเข้าสู่ global routing ผ่าน BGP ด้วย ซึ่งในทางทฤษฎีเป็นไปได้ แต่ยังไม่เคยมีใครทำสำเร็จจริง (คล้ายสภาพของ Let's Encrypt ก่อนจะเกิดขึ้น) ฉันไม่แน่ใจว่าทำไมถึงต้องยึดการตั้งชื่อแบบ DNS ถ้าไม่ได้ต้องการให้สั้นและจำง่าย DNS ก็ไม่ใช่ตัวเลือกที่เหมาะนัก แต่แนวทางแบบ ngrok ที่ออกโดเมนผ่าน gTLD ของตัวเองก็น่าลอง ในอดีต .me ccTLD เคยแจกโดเมนฟรีแบบนี้ โดยแลกกับการสอดแทรกโฆษณาผ่าน proxy กลางในทุกทราฟฟิก
.tk เคยให้ใช้ฟรี และเคยเป็น ccTLD ที่มีจำนวนการจดทะเบียนมากที่สุดในโลก ส่วนใหญ่ก็ถูกนำไปใช้ในทางที่ผิด Facebook ฟ้องบริษัทผู้ให้บริการ (บริษัทดัตช์ชื่อ Freenom) ว่ามีส่วนเกี่ยวข้องกับ phishing ตอนนี้เลยไม่มีให้ใช้ฟรีแล้ว
เคยมีโครงการ .FREE TLD initiative มาก่อน แต่มีปัญหาเรื่องการดำเนินการและไม่ทำตามกำหนดเวลา จนตอนนี้ค่อย ๆ เงียบหายไป https://icannwiki.org/.free
ถ้าเห็นบทความของ Dan ฉันจะกดอ่านเสมอ ฉันกังวลเล็กน้อยว่าเว็บแบบเปิดอาจประสบความสำเร็จเพราะอาศัย first-mover advantage แต่พอมองโอเพนซอร์สที่ประสบความสำเร็จ ก็ยังรู้สึกมีความหวัง อยากเห็นโลกที่อะไรอย่าง atproto ประสบความสำเร็จจริง ๆ มันน่าเสียดายที่แอปที่ดีกว่าเอาชนะไม่ได้เพราะ network effect
HTML ประสบความสำเร็จเพราะมัน ‘ฟรี’ ในยุคนั้นมีมาตรฐาน hypermedia แบบเสียเงินอยู่มาก แต่ HTML เข้าถึงง่ายกว่าคู่แข่งเหล่านั้น สภาพแวดล้อมในตอนนั้นทำให้ใคร ๆ ก็เขียน browser หรือ server เองได้ไม่ยาก
จุดแข็งสำคัญอีกอย่างคือ ATProto ถูกออกแบบมาเพื่อทำลายข้อจำกัดของ network effects ถ้าทุกคนย้ายมาอยู่บน atproto สุดท้ายก็จะกลายเป็นว่าเราแค่ต้องย้าย social network “เป็นครั้งสุดท้าย” เพราะโครงสร้างสุดท้ายจะเปิดทางไปสู่การกระจายศูนย์และการแข่งขันเสรีอย่างแท้จริง
ในทางปฏิบัติฉันนึกภาพไม่ออกเลยว่าระบบแบบนี้จะถูกใช้อย่างแพร่หลายได้อย่างไร กลุ่มเป้าหมายของโซเชียลมีเดียแบบดั้งเดิมกับผู้ใช้สายกระจายศูนย์นั้นต่างกันคนละแบบ คนส่วนใหญ่สนใจแค่แพลตฟอร์มในฐานะเครื่องมือ ไม่ได้สนใจระบบข้างใต้ สุดท้ายถ้าทุกคนแค่ไปสมัครบัญชี bluesky กันหมด มันก็จะไปรวมศูนย์อยู่กับบริการใหญ่ไม่กี่เจ้าเหมือนเดิมจนหมดความหมาย
ถึงทุกคนจะไปรวมกันที่ bsky.social ก็ยังถือว่าก้าวหน้าอย่างมหาศาล เมื่อเทียบกับของเดิม มันก็เหมือนกับที่เราไม่บอกว่าเว็บรวมศูนย์เพียงเพราะมีเซิร์ฟเวอร์จำนวนมากไปรวมอยู่บน AWS เพราะอย่างน้อยก็ย้ายออกได้ทุกเมื่อถ้าจำเป็น
ในความเป็นจริง bluesky ยังไม่ได้ทำ federation อย่างสมบูรณ์ เพราะทราฟฟิกทั้งหมดยังพึ่งเซิร์ฟเวอร์ router "BGS" ตัวเดียว
น่าเสียดาย แต่สุดท้ายต้นตอของปัญหาก็คือ 'คน'
ฉันมีความรู้สึกซับซ้อนกับงานนี้ ด้านหนึ่ง ไอเดียนี้ตรงกับรสนิยมฉันมาก เพราะสอดคล้องกับขบวนการ Indie web ที่เชื่อว่าทุกคนควรเป็นเจ้าของคอนเทนต์ของตัวเอง และหน้าเว็บกับบทความเหล่านี้ก็ทำออกมาได้ประณีตน่าประทับใจมาก แต่อีกด้านหนึ่ง นักพัฒนาที่เอามาตรฐานลักษณะนี้ไปใช้กับบล็อกส่วนตัวหรือโปรเจกต์โอเพนซอร์สจริง ๆ กลับมีน้อยมาก และในหมู่บล็อกเกอร์/วล็อกเกอร์หรือผู้ใช้ทั่วไปก็แทบไม่เห็นการยอมรับ ฉันกังวลที่ผู้คนจำนวนมากเฉยเมยต่อความเป็นเจ้าของข้อมูล ความเปิดกว้าง และการทำงานร่วมกันได้ ดูเหมือนคนส่วนใหญ่ต้องการแค่ฟีดแบบ TikTok หรือ Instagram Reels เท่านั้น ฉันเคารพวิสัยทัศน์และความพยายามนี้มาก แต่ก็ยังสงสัยว่าเรื่องนี้จะไปไกลกว่าความชอบเฉพาะกลุ่มเล็ก ๆ จนกลายเป็นกระแสหลักได้หรือไม่
ยังมีงานต้องทำอีกมากเพื่อทำให้ประสบการณ์นักพัฒนาง่ายขึ้น แต่ความก้าวหน้าในพื้นที่นี้เร็วมากจนน่าตื่นเต้นจริง ๆ อีก 6–12 เดือนข้างหน้าดูน่าสนใจมาก ผู้คนส่วนใหญ่ยังไม่เข้าใจว่า ATProto ใช้ได้กับอะไรที่มากกว่า Bluesky อย่างมหาศาล และต้องใช้เวลาให้ภาพนี้ปรากฏชัดในตลาดมากกว่านี้
ฉันสงสัยว่าทำไมแนวคิดเรื่อง 'ความเป็นเจ้าของข้อมูล' ถึงสำคัญขนาดนั้น และการที่สาธารณชนไม่สนใจจึงน่ากังวลจริง ๆ เพราะที่ผ่านมา ผู้คนก็เสพคอนเทนต์แบบไม่ได้เป็นเจ้าของอยู่แล้ว ไม่ว่าจะเป็นทีวี หนังสือ หรือวิทยุ ทุกวันนี้แค่มีโอกาสโพสต์บางอย่างให้คนรอบตัวเห็นได้เท่านั้น เลยยังสงสัยว่าการ 'เป็นเจ้าของ' โพสต์ใน Instagram จริง ๆ มันสำคัญมากขนาดนั้นหรือ
เห็นด้วยกับคุณ ท้ายที่สุดแล้ว ถ้าเราไม่ช่วยกันเผยแพร่เทคโนโลยีนี้และผลักดันให้เป็นที่นิยม มันก็ไม่มีทางสำเร็จได้ บางทีวันหนึ่งอาจมีผู้ก่อตั้งหรือ CTO ที่หลงใหล open social สร้างแอปที่ประสบความสำเร็จในวงกว้างขึ้นมาก็ได้ และถ้าไม่เริ่มลงมือเลย มันก็ไม่มีวันสำเร็จแน่นอน