“เจาะลึก 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/
ในยุคที่ข้อมูลส่วนตัวถูกผูกติดกับแพลตฟอร์มกลางอย่าง 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/
🔗 “เจาะลึก 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/
0 Comments
0 Shares
38 Views
0 Reviews