🔗 “เจาะลึก at:// — โปรโตคอลใหม่ที่เปลี่ยนโฉมการเชื่อมโยงข้อมูลบนเว็บให้เป็นของผู้ใช้จริง” ในยุคที่ข้อมูลส่วนตัวถูกผูกติดกับแพลตฟอร์มกลางอย่าง Facebook หรือ Twitter โปรโตคอลใหม่ชื่อว่า AT Protocol กำลังเสนอแนวทางที่ต่างออกไปอย่างสิ้นเชิง โดยให้ผู้ใช้เป็นเจ้าของข้อมูลของตัวเองอย่างแท้จริง ผ่านระบบ URI แบบใหม่ที่เรียกว่า at:// บทความจาก Overreacted ได้อธิบายการทำงานของ at:// อย่างละเอียด โดยเปรียบเทียบกับ https:// ที่เราใช้กันทั่วไป ซึ่งในระบบเดิม “authority” หรือเจ้าของข้อมูลคือเซิร์ฟเวอร์ที่โฮสต์ข้อมูลนั้น แต่ใน at:// ผู้ใช้คือ authority — หมายความว่า URI จะระบุว่าใครเป็นเจ้าของข้อมูล ไม่ใช่ใครเป็นผู้โฮสต์ ตัวอย่างเช่น at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z เป็น URI ที่ชี้ไปยังโพสต์หนึ่งในระบบ Bluesky ซึ่งข้อมูลจริงจะถูกโฮสต์อยู่ที่เซิร์ฟเวอร์ที่ผู้ใช้เลือกเอง และสามารถเปลี่ยนได้โดยไม่กระทบกับ URI เดิม หากต้องการเข้าถึง JSON ที่อยู่เบื้องหลัง URI นี้ จะต้องผ่าน 3 ขั้นตอน: 1️⃣ แปลง handle (เช่น ruuuuu.de) เป็น identity ที่ไม่เปลี่ยนแปลง (DID) 2️⃣ ใช้ DID เพื่อค้นหาเซิร์ฟเวอร์ที่โฮสต์ข้อมูล 3️⃣ ดึง JSON จากเซิร์ฟเวอร์นั้นผ่าน API DID มีสองแบบหลักคือ did:web และ did:plc โดยแบบแรกผูกกับโดเมนเว็บ เช่น iam.ruuuuu.de ส่วนแบบหลังเป็นระบบ ledger กลางที่ไม่ขึ้นกับโดเมนใด ซึ่งช่วยให้ผู้ใช้ไม่ต้องกังวลเรื่องการหมดอายุโดเมนหรือการเปลี่ยนแปลง DNS เมื่อได้ DID แล้ว จะสามารถดึง “DID Document” ซึ่งเป็นเหมือนพาสปอร์ตดิจิทัลของผู้ใช้ โดยระบุว่า handle ไหนที่ใช้, public key ที่ใช้เซ็นข้อมูล, และเซิร์ฟเวอร์ที่โฮสต์ข้อมูล เช่น blacksky.app หรือ morel.us-east.host.bsky.network การออกแบบนี้ทำให้ข้อมูลของผู้ใช้สามารถเคลื่อนย้ายได้อย่างอิสระ โดยไม่ต้องเปลี่ยน URI หรือสูญเสียลิงก์ระหว่างข้อมูล และช่วยให้แอปต่าง ๆ สามารถแสดงข้อมูลเดียวกันได้โดยไม่ต้องพึ่งพาแพลตฟอร์มกลาง ✅ ข้อมูลสำคัญจากข่าว ➡️ AT Protocol ใช้ URI แบบ at:// ที่ให้ผู้ใช้เป็นเจ้าของข้อมูล ➡️ URI เช่น at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z ชี้ไปยัง JSON ที่โฮสต์โดยผู้ใช้ ➡️ การเข้าถึงข้อมูลต้องผ่าน 3 ขั้นตอน: handle → DID → hosting → JSON ➡️ DID มีสองแบบหลักคือ did:web และ did:plc ➡️ DID Document ระบุ handle, public key และเซิร์ฟเวอร์ที่โฮสต์ข้อมูล ➡️ ระบบนี้ช่วยให้ข้อมูลเคลื่อนย้ายได้โดยไม่สูญเสียลิงก์ ➡️ แอปต่าง ๆ สามารถใช้ข้อมูลเดียวกันได้โดยไม่ต้องพึ่งแพลตฟอร์มกลาง ➡️ at:// ที่ใช้ DID เป็น “permalink” ที่ไม่เปลี่ยนแปลง ✅ ข้อมูลเสริมจากภายนอก ➡️ DID (Decentralized Identifier) เป็นมาตรฐานที่กำหนดโดย W3C สำหรับการระบุตัวตนแบบไม่รวมศูนย์ ➡️ did:web ใช้โดเมนเว็บในการระบุตัวตน แต่เสี่ยงต่อการหมดอายุหรือโดเมนถูกยึด ➡️ did:plc ใช้ระบบ ledger กลางที่ไม่ขึ้นกับโดเมนใด ➡️ JSON ที่ถูกเรียกใช้ผ่าน at:// เป็นข้อมูลดิบ ไม่ใช่ UI หรือหน้าเว็บ ➡️ SDK และ cache เช่น QuickDID ช่วยให้การ resolve URI เร็วขึ้นในแอปจริง ‼️ คำเตือนและข้อจำกัด ⛔ URI ที่ใช้ handle อาจเปลี่ยนแปลงได้ หากผู้ใช้เปลี่ยนชื่อหรือโดเมน ⛔ หากใช้ did:web แล้วโดเมนหมดอายุ ผู้ใช้จะสูญเสียการควบคุมข้อมูล ⛔ การ resolve URI ต้องใช้ DNS และ HTTPS ซึ่งอาจช้าในระบบขนาดใหญ่ ⛔ ผู้ใช้ต้องเข้าใจโครงสร้าง URI และ DID เพื่อใช้งานอย่างถูกต้อง ⛔ การเปลี่ยน hosting ต้องอัปเดต DID Document ให้ตรงกัน ไม่เช่นนั้นข้อมูลจะไม่ถูกเรียกได้ https://overreacted.io/where-its-at/