สิ่งที่ได้เรียนรู้จากการเข้าร่วม IndieWeb

• IndieWeb คือทางเลือกและชุมชนที่ยึดผู้คนเป็นศูนย์กลาง แทนเว็บที่ขับเคลื่อนโดยบริษัท โดยเก็บรักษาคอนเทนต์ ตัวตน และบทสนทนาไว้บนโดเมนส่วนตัว พร้อมเชื่อมต่อกับโซเชียลเน็ตเวิร์กได้ตามต้องการ
• ใช้โดเมนของตนเองเป็นฐาน แล้วผสานมาตรฐานเล็ก ๆ อย่าง microformats2, rel="me", Webmention, IndieAuth และ Micropub เพื่อทำให้ HTML อ่านได้โดยเครื่อง และรองรับการยืนยันตัวตน การเผยแพร่ และบทสนทนาระหว่างไซต์
• หน้าเว็บ 23 ล้านหน้าของ GeoCities และเพลงมากกว่า 50 ล้านเพลงของ MySpace ได้หายไป อีกทั้งผลสำรวจของ Pew Research ในปี 2024 ยังพบว่าในบรรดาเว็บเพจที่มีอยู่ในปี 2013 มี 38% ที่ไม่สามารถเข้าถึงได้หลังผ่านไป 10 ปี
• POSSE คือการเผยแพร่ต้นฉบับบนไซต์ของตนเองก่อน แล้วจึงกระจายไปยังแพลตฟอร์มภายนอก ส่วน Backfeed จะส่งไลก์ การตอบกลับ และการรีโพสต์จากภายนอกกลับมายังต้นฉบับผ่าน Webmention เพื่อเก็บบทสนทนาทั้งหมดไว้บนโดเมนส่วนตัว
• ในไซต์จริงมีการใช้ Webmention, h-entry, h-card และ rel="me" แต่ตัด Micropub, IndieAuth และ WebSub ออก เพราะไม่เข้ากับเวิร์กโฟลว์ Git·Markdown ที่ใช้อยู่หรือการหน่วงเวลาเผยแพร่ 24 ชั่วโมง โดยแนวทางที่เหมาะกว่าคือ ค่อย ๆ นำเทคโนโลยีที่จำเป็นมาใช้ก่อน แทนที่จะพยายามใช้ทุกสเปก

---

เว็บที่ IndieWeb มุ่งหวัง

• IndieWeb นิยามตัวเองว่าเป็น “ทางเลือกที่ยึดผู้คนเป็นศูนย์กลางแทนเว็บของบริษัท” และใกล้เคียงกับรากฐานเชิงอุดมการณ์ที่เปิดรับแนวทางและโปรเจกต์หลากหลาย มากกว่าจะเป็นซอฟต์แวร์หรือเฟรมเวิร์กเฉพาะ
• ในปี 2010 Aaron Parecki และ Tantek Çelik เข้าร่วม Federated Social Web Summit ที่ Portland แล้วเห็นว่าจำเป็นต้องมี แนวทางที่ยึดผู้สร้างเป็นศูนย์กลาง มากกว่าโปรโตคอล
  • ในปี 2011 มีการจัด IndieWebCamp ครั้งแรกที่ Portland และหลังจากนั้นก็จัดขึ้นทุกปีในหลายพื้นที่ทั่วโลก
  • ที่ Homebrew Website Club ผู้เข้าร่วมจะมารวมตัวกันเพื่อปรับปรุงเว็บไซต์ส่วนตัวของตนเอง
• เสาหลักสามประการของ IndieWeb มีดังนี้
  • ความเป็นเจ้าของคอนเทนต์: คอนเทนต์ที่โพสต์บนเว็บควรเป็นของผู้เผยแพร่ ไม่ใช่ของบริษัท
  • การเชื่อมต่อที่ดีกว่า: ควรกระจายโพสต์ไปยังหลายแพลตฟอร์ม และดึงการตอบกลับกับไลก์จากภายนอกกลับมายังไซต์ของตนเองได้
  • อำนาจควบคุม: สามารถโพสต์และอ่านในรูปแบบที่ต้องการได้ และคง URL ที่ถาวรไว้ได้
• ไม่ได้ห้ามการใช้โซเชียลเน็ตเวิร์ก แต่คัดค้าน ระบบนิเวศแบบปิด ที่กักขังคอนเทนต์และปฏิสัมพันธ์ไว้ข้างใน

ไซโลกับการสูญหายของคอนเทนต์บนเว็บ

• ไซโล (silo) โดยทั่วไปคือเว็บไซต์แบบรวมศูนย์ที่มักดำเนินการโดยบริษัทแสวงกำไร และเรียกร้องสิทธิ์เหนือคอนเทนต์ที่ผู้ใช้มีส่วนร่วม หรือจำกัดการเข้าถึง
  • ต้องมีบัญชีเฉพาะของแต่ละบริการจึงจะเข้าร่วมได้
  • โต้ตอบกันได้เฉพาะระหว่างบัญชีในบริการเดียวกัน
  • อาจมีเงื่อนไขการใช้งานที่จำกัด การเรียกร้องไลเซนส์คอนเทนต์ การปิดกั้นการทำดัชนีค้นหา และอุปสรรคในการนำเข้า·ส่งออกข้อมูลเพิ่มเติมด้วย
• เมื่อไซโลปิดตัว คอนเทนต์ของผู้ใช้ก็อาจหายไปพร้อมกัน
  • GeoCities ปิดตัวโดย Yahoo เมื่อวันที่ 26 ตุลาคม 2009 ทำให้หน้าเว็บ 23 ล้านหน้าหายไป
  • MySpace สูญเสียเพลงมากกว่า 50 ล้านเพลงที่ศิลปิน 14 ล้านคนอัปโหลดไว้ในช่วง 12 ปีแรก ระหว่างกระบวนการย้ายเซิร์ฟเวอร์ในปี 2019
  • Google+ ปิดตัวในเดือนเมษายน 2019
  • Posterous, FriendFeed, Vine, Yahoo Groups, TinyLetter, Cohost และบริการอื่น ๆ ก็อยู่ในรายชื่อที่ปิดตัวเช่นกัน
• แม้ไซโลจะไม่ปิด คอนเทนต์บนเว็บก็ยังหายไปได้
  • จาก ผลสำรวจของ Pew Research ในปี 2024 เว็บเพจที่มีอยู่ในปี 2013 มี 38% ที่ไม่สามารถเข้าถึงได้หลังผ่านไป 10 ปี
• หลักการรับมือไม่ใช่การเลิกใช้โซเชียลเน็ตเวิร์ก แต่คือการเก็บ สำเนาหลัก (canonical copy) ของคอนเทนต์ไว้บนโดเมนที่ตนเองควบคุม

หลักการ 11 ข้อของชุมชน

• หลักการ 11 ข้อ ไม่ใช่ลำดับความสำคัญ และไม่ใช่ข้อบังคับที่ต้องทำให้ครบทั้งหมด
  1. เป็นเจ้าของข้อมูล: เก็บคอนเทนต์ เมทาดาทา และตัวตนไว้บนโดเมนของตนเอง และคงสิทธิ์การเข้าถึงในระยะยาว
  2. ใช้และเผยแพร่ข้อมูลที่มองเห็นได้: ให้ความสำคัญกับมนุษย์ก่อน แล้วจึงคำนึงถึงเครื่อง หากใส่ข้อมูลไว้ใน HTML ได้ ก็ไม่ต้องสร้าง API แยกต่างหาก
  3. สร้างสิ่งที่ตนเองต้องการ: สร้างเครื่องมือให้ตัวเองในโลกจริง ไม่ใช่ผู้ใช้สมมติที่ไม่แน่ชัดว่ามีอยู่จริงหรือไม่
  4. ใช้งานเองโดยตรง: ใช้สิ่งที่สร้างขึ้นทุกวัน เพื่อพิสูจน์ว่ามันคู่ควรแก่การพึ่งพาหรือไม่
  5. จัดทำเอกสาร: บันทึกกระบวนการ ไอเดีย และโค้ดไว้บนไซต์ของตนเอง เพื่อช่วยผู้อื่นและตัวเองในอนาคต
  6. เปิดเป็นโอเพนซอร์ส: ไม่ใช่ข้อบังคับ แต่ช่วยให้ผู้อื่นเข้าร่วมเว็บอิสระได้เร็วขึ้น
  7. UX มาก่อนโปรโตคอล: กำหนดประสบการณ์ผู้ใช้ก่อน แล้วใช้เฉพาะโปรโตคอลที่เรียบง่ายและเล็กที่สุดซึ่งรองรับสิ่งนั้นได้
  8. ความเป็นโมดูลาร์: สร้างส่วนประกอบขนาดเล็กที่เชื่อมกันแบบหลวม ๆ เพื่อไม่ให้ผูกติดกับอุปกรณ์ ภาษา หรือแพลตฟอร์มใดแพลตฟอร์มหนึ่ง
  9. การคงอยู่ระยะยาว: สร้างเทคโนโลยีเว็บที่ไม่จำเป็นต้องทิ้งงานเดิมทุกไม่กี่ปีเพียงเพราะมีการพัฒนา
  10. ความหลากหลาย: ส่งเสริมหลายแนวทางอย่างตั้งใจ เพื่อสร้างชุมชนที่ยืดหยุ่นกว่าวัฒนธรรมเทคโนโลยีแบบเดียว
  11. ความสนุก: รักษาการแสดงออกส่วนบุคคลที่แปลกและน่าสนใจไว้ เหมือนเว็บยุค 1990

โครงสร้างทางเทคนิคที่เริ่มจากโดเมนส่วนตัว

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

microformats2: ใช้ HTML เป็น API

• microformats2 เพิ่มคลาส CSS ลงใน HTML เดิม เพื่อทำให้คอนเทนต์ เครื่องอ่านได้ โดยไม่ต้องมีไฟล์หรือ API แยกต่างหาก
  • h-*: อ็อบเจกต์ราก
  • p-*: ข้อความธรรมดา
  • u-*: URL
  • dt-*: วันที่
  • e-*: HTML ที่ฝังอยู่
• h-card แสดงตัวตนส่วนบุคคล เช่น ชื่อ URL และรูปภาพ ทำให้แอปพลิเคชันแสดงโปรไฟล์ข้างโพสต์และจดจำผู้ใช้ได้
  • ต่างจาก Gravatar ที่อิงอีเมล ตรงที่ทำงานโดยอิงโดเมน
• h-entry เป็นองค์ประกอบหลักของคอนเทนต์ IndieWeb ใช้ระบุชื่อโพสต์ ผู้เขียน วันที่เผยแพร่ เนื้อหา และอื่น ๆ
• h-feed รวม h-entry หลายรายการเข้าด้วยกัน ทำให้หน้ารายการ HTML นั้นเองกลายเป็นฟีดที่สมัครรับได้
• โครงสร้างนี้ใช้ microformats สำหรับการอ่าน และ Micropub สำหรับการเขียน จึงกลายเป็นรูปแบบที่ “เว็บไซต์คือ API”

rel="me" และการยืนยันตัวตนแบบกระจายศูนย์

• rel="me" ประกาศว่าปลายทางของลิงก์เป็นบุคคลเดียวกับหน้าปัจจุบัน
• เมื่อเว็บไซต์และโปรไฟล์ภายนอกเชื่อมถึงกันด้วย rel="me" ก็สามารถ ยืนยันตัวตนร่วมกัน ได้โดยไม่ต้องมีหน่วยงานกลาง
  • Mastodon ใช้โครงสร้างนี้เพื่อให้เครื่องหมายยืนยันสีเขียวบนโดเมน
  • Threads, PixelFed, GitHub, Keybase และ Wikipedia ก็รองรับเช่นกัน
• RelMeAuth มอบหมายการพิสูจน์ตัวตนให้ผู้ให้บริการ OAuth อย่าง GitHub ที่เชื่อมไว้จากโฮมเพจ เพื่อใช้ URL ส่วนตัวในการยืนยันตัวตนกับบริการต่าง ๆ
  • เป็นรากฐานของบริการอย่าง IndieLogin

Webmention: บทสนทนาระหว่างเว็บไซต์

• Webmention เป็น W3C Recommendation ตั้งแต่วันที่ 12 มกราคม 2017 และสืบต่อจาก Pingback เพื่อส่งความคิดเห็น ไลก์ การตอบกลับ และการรีโพสต์ระหว่างไซต์โดยไม่ต้องพึ่งแพลตฟอร์ม
• ขั้นตอนการส่งมีดังนี้
  1. โพสต์ต้นทางมีลิงก์ไปยังโพสต์ของอีกฝ่าย
  2. เซิร์ฟเวอร์ต้นทางค้นหา endpoint รับจาก HTTP Link header ของโพสต์อีกฝ่าย หรือจาก <link rel="webmention"> ใน HTML
  3. ส่งคำขอ POST ที่มีเพียง source ซึ่งเป็นโพสต์ต้นทาง และ target ซึ่งเป็นโพสต์ปลายทาง
  4. เซิร์ฟเวอร์รับดาวน์โหลด source แล้วตรวจสอบว่ามีลิงก์ไปยัง target จริงหรือไม่
  5. วิเคราะห์ h-entry ของ source เพื่อแยกแยะการตอบกลับ ไลก์ และรีโพสต์ แล้วใช้ h-card แสดงชื่อและรูปภาพของผู้เขียน
• แต่ละไซต์กลายเป็นโหนด และลิงก์ระหว่างไซต์ประกอบเป็น โซเชียลกราฟ แต่ยังมีปัญหาเรื่องสแปมและการกลั่นกรองอยู่
  • Vouch ส่งไซต์รับรองที่ผู้รับรู้อยู่แล้วและลิงก์ไปยังโดเมนผู้ส่งเป็นพารามิเตอร์ตัวที่สาม เพื่อย้ายต้นทุนการกรองไปให้ผู้ส่ง
  • Salmention เมื่อมีการตอบกลับความคิดเห็น จะให้โพสต์ต้นฉบับส่ง Webmention อัปเดตกลับไปยังผู้เข้าร่วม เพื่อกระจายเธรดสนทนา
• ไซต์แบบ static ที่ไม่มีแบ็กเอนด์สามารถใช้ webmention.io เพื่อรับ Webmention แทน และให้ API สำหรับเรียกดู
  • ใช้ได้กับ static site generator อย่าง Hugo, Jekyll และ Eleventy

การล็อกอินและการเผยแพร่โดยอิงโดเมน

• IndieAuth ใช้ URL ส่วนตัวเป็นตัวตนสำหรับล็อกอิน แทนบัญชี Google หรือ Facebook
  • อิง OAuth 2.0 และระบุผู้ใช้กับแอปพลิเคชันด้วย URL
  • DNS ทำหน้าที่แทนการลงทะเบียนไคลเอนต์ล่วงหน้า และ PKCE ซึ่งป้องกันการขโมย access token เป็นสิ่งจำเป็น
  • บริการจะค้นหาเซิร์ฟเวอร์ยืนยันตัวตนจาก rel="indieauth-metadata" บนหน้าผู้ใช้ และหลังยืนยันสำเร็จจะตรวจสอบสิทธิ์ควบคุม URL นั้น
  • วิธีการยืนยันตัวตนอาจใช้รหัสผ่าน อีเมล RelMeAuth และอื่น ๆ
• Micropub เป็น W3C Recommendation ตั้งแต่เดือนพฤษภาคม 2017 และแยกซอฟต์แวร์ของไซต์ออกจากอินเทอร์เฟซการเผยแพร่
  • ไคลเอนต์บนเว็บ iOS และ Android สามารถสร้าง แก้ไข และลบโพสต์บนโดเมนส่วนตัวได้
  • ใช้ OAuth token ที่ได้จาก IndieAuth แทน MetaWeblog และ AtomPub ซึ่งเคยแชร์รหัสผ่านกัน
  • ไม่สร้างคำศัพท์แยกต่างหาก แต่ serialize แล้วส่งคุณสมบัติของ h-entry เช่น h=entry, content

ฟีดเรียลไทม์และรีดเดอร์ที่แยกออกจากกัน

• WebSub เดิมเรียกว่า PubSubHubbub และเป็น W3C Recommendation ตั้งแต่เดือนมกราคม 2018
  • แทนที่ผู้สมัครรับต้องคอย query เซิร์ฟเวอร์เป็นระยะ ผู้เผยแพร่จะแจ้งโพสต์ใหม่ไปยัง hub และ hub จะส่งต่อไปยังผู้สมัครรับทันทีผ่าน webhook
  • ลดโหลดเซิร์ฟเวอร์และตัดความล่าช้าในการอัปเดต โดย Feedly และ NewsBlur รองรับ
• Microsub เป็นสเปกใหม่ที่สุดและยังอยู่ในสถานะร่าง แยกแอปอ่านโซเชียลออกเป็นสองชั้น
  • เซิร์ฟเวอร์รับผิดชอบการจัดการการสมัครรับ การรวบรวม·วิเคราะห์ฟีด และการทำข้อมูลให้เป็นรูปแบบปกติ
  • ไคลเอนต์แสดงเฉพาะอินเทอร์เฟซการอ่าน ทำให้แข่งขันกันด้วย UX ได้ และย้ายข้อมูลการสมัครรับระหว่างไคลเอนต์ได้
  • เมื่อผสานการเผยแพร่คำตอบของ Micropub กับการแจ้งเตือนของ Webmention ก็จะได้โครงสร้าง โซเชียลรีดเดอร์ ของ IndieWeb ที่สมบูรณ์

POSSE, PESOS และ Backfeed

• POSSE เป็นกลยุทธ์ที่แนะนำ คือ เผยแพร่บนไซต์ของตนเองก่อน แล้วกระจายออกไปภายนอก
  • สำเนาภายนอกมีลิงก์ไปยังต้นฉบับ ผู้อ่านจึงยังอ่านบนแพลตฟอร์มเดิมได้ ขณะที่ผู้เผยแพร่ยังคงสำเนาหลักไว้
  • แม้แพลตฟอร์มจะปิดตัวหรือบัญชีถูกบล็อก ต้นฉบับก็ยังอยู่
  • Tantek Çelik สร้างคำนี้ขึ้นในปี 2012 และ Cory Doctorow กับ Molly White เป็นต้นได้นำไปใช้
  • ผลที่ทำให้ไซต์สแปมคัดลอกโพสต์พร้อมคัดลอกลิงก์ต้นฉบับไปด้วย ถูกเรียกว่า “อินเทอร์เน็ตไอคิโด”
• PESOS เป็นวิธีตรงข้าม คือโพสต์ในไซโลก่อน แล้วคัดลอกมาเก็บไว้บนไซต์ของตนเอง
  • สามารถใช้แอปไซโลที่ทำมาดี และยังโพสต์ได้แม้ไซต์ส่วนตัวหยุดทำงาน
  • แต่ถูกผูกกับเงื่อนไขของไซโลตั้งแต่แรก สำเนาบนไซต์ส่วนตัวไม่ใช่สำเนาหลัก และยังสืบทอดข้อจำกัดอย่างจำนวนตัวอักษรหรือลิงก์ t.co มาด้วย
• Backfeed ส่งไลก์ การตอบกลับ และการรีโพสต์บนสำเนาภายนอกกลับมายังต้นฉบับผ่าน Webmention
  • Bridgy เฝ้าดูสำเนาบน Mastodon, GitHub, Flickr, Reddit และ Bluesky แล้วส่ง Webmention ทุกครั้งที่มีปฏิสัมพันธ์
  • ผลคือสามารถเก็บบทสนทนาทั้งหมดที่เกิดขึ้นบนแพลตฟอร์มภายนอกไว้บนโดเมนส่วนตัวได้

ความสัมพันธ์กับ Fediverse และ RSS

• Webmention, Micropub, WebSub และ ActivityPub ล้วนมาจาก W3C Social Web Working Group แต่ยึดปรัชญาต่างกัน
• Fediverse รวมเซิร์ฟเวอร์เข้าด้วยกันและแสดงตัวตนเป็น @user@instance ดังนั้นหากไม่ได้รัน instance เอง ก็ต้องพึ่งพาผู้ดูแลรายอื่น
  • การดูแล instance มี admintax ซึ่งเป็นต้นทุนสูงด้านการกลั่นกรองและการบำรุงรักษา
• IndieWeb รวมเว็บไซต์เข้าด้วยกันและใช้โดเมนส่วนตัวเป็นตัวตน โดยถือ federation เป็นเพียงหนึ่งในหลายช่องทางการกระจาย
• Bridgy Fed แปลง h-card, h-entry และ Webmention ไปมาระหว่าง ActivityPub กับ AT Protocol ของ Bluesky
  • โดเมนส่วนตัวจะกลายเป็นบัญชี Fediverse ในรูปแบบ @[e-mail]
  • สามารถค้นหาและติดตามบัญชีนั้นบน Mastodon ได้ และคำตอบจะกลับไปยังโพสต์ต้นฉบับผ่าน Backfeed
• IndieWeb มองว่า RSS·Atom ต้องรักษาสำเนา XML แยกจาก HTML จึงก่อให้เกิด ต้นทุนการบำรุงรักษา และความเป็นไปได้ที่จะไม่ตรงกัน
  • ไฟล์ Atom บางไฟล์มีขนาดใหญ่กว่า HTML ที่มีเนื้อหาเดียวกันได้สูงสุด 4.5 เท่า
  • ประสบการณ์เมื่อคนเปิดลิงก์ฟีดโดยตรงก็ไม่ดีนัก
• ทางเลือกอย่าง h-feed ใช้ HTML เองเป็นฟีด แต่มีรีดเดอร์รองรับน้อยมาก
  • ดังนั้นในสภาพแวดล้อม IndieWeb แนะนำให้ให้ h-feed ควบคู่กับ RSS·Atom สำหรับผู้อ่านทั่วไป

ลำดับการเริ่มต้น

• Getting Started แนะนำลำดับต่อไปนี้
  1. จดโดเมน: ใช้เป็นตัวตนหลักบนออนไลน์ และเลือกใช้การปกป้องข้อมูลส่วนตัว WHOIS เฉพาะเมื่อไว้วางใจผู้ให้บริการอย่างเต็มที่เท่านั้น
  2. ตั้งค่าโฮสติ้ง: ผู้เริ่มต้นใช้บริการแบบจัดการให้ เช่น GitHub Pages, Netlify, Neocities ส่วนผู้มีประสบการณ์ก็โฮสต์เองได้
  3. สร้างหน้าเว็บ: จะใช้ static site generator, HTML ที่เขียนเอง หรือ CMS ก็ได้ ไม่มีเทคโนโลยีทางการ
  4. ใช้ POSSE: กระจายไปยังแพลตฟอร์มอื่นพร้อมลิงก์ต้นฉบับ
  5. เพิ่ม microformats: ใส่ rel="me" บนโฮมเพจ และ h-entry ในโพสต์
  6. ตรวจสอบ: ใช้ IndieWebify.me ตรวจ rel-me, h-card และ h-entry ทีละขั้น
  7. เข้าร่วมชุมชน: แม้มีเพียงหน้าเดียว ก็แชร์สิ่งที่สร้าง และจัดทำเอกสารในวิกิเพื่อผู้ใช้คนถัดไป
• IndieMark เป็นมาตรวัดแบบเป็นขั้นตอนสำหรับนักพัฒนาที่ต้องการนำไปใช้อย่างค่อยเป็นค่อยไป

การนำไปใช้จริงและฟีเจอร์ที่ตัดออก

• ไซต์จริงนำองค์ประกอบต่อไปนี้มาใช้
  • การส่งและรับ Webmention: ทำงานประจำวันในการแจ้งลิงก์ภายนอกของโพสต์ใหม่ให้เป็นอัตโนมัติ แต่เว้นเวลา 24 ชั่วโมงเพื่อให้แก้คำผิดได้
  • Webmention ที่ได้รับจะใช้ในรายการอ้างอิงท้ายแต่ละโพสต์ และแยกจากความคิดเห็นที่จัดการผ่านอีเมล
  • ใช้ h-entry กับทุกโพสต์ ใช้ h-card บนโฮมเพจ และตรวจสอบด้วย mf2py
  • เชื่อม Mastodon, GitHub และ Org Social ด้วย rel="me" ที่ footer เพื่อรับเครื่องหมายยืนยัน
• องค์ประกอบที่ไม่ตรงกับความต้องการและเวิร์กโฟลว์เดิมถูกตัดออก
  • Micropub·IndieAuth: ตัวแก้ไขและ Git คืออินเทอร์เฟซเผยแพร่ และเขียนโพสต์เป็น Markdown ที่จัดการเวอร์ชันอยู่แล้ว จึงไม่ต้องมี endpoint เผยแพร่แยกต่างหาก
  • WebSub: เพราะตั้งใจหน่วงการเผยแพร่ 24 ชั่วโมง การส่งแบบเรียลไทม์จึงไม่คุ้มกับความซับซ้อน
  • h-feed: เทมเพลตการ์ดบทความถูกนำกลับมาใช้ในส่วนอื่น เช่น พื้นที่แนะนำในเนื้อหา ทำให้ parser อาจตีความเป็น h-entry ที่คลุมเครือ และ RSS ก็ทำหน้าที่นี้ได้เพียงพอแล้ว

หลักปฏิบัติที่อยู่ได้นานกว่าเทคโนโลยี

• HTML ธรรมดา เป็นรูปแบบที่คงทนที่สุดซึ่งอ่านคอนเทนต์ทั้งหมดได้แม้ไม่มี JavaScript
• ต้องออกแบบ URL ที่รักษาไว้ได้ถาวร ตามหลัก “Cool URIs don't change”
  • ในไซต์จริง แม้เปลี่ยน slug ของโพสต์ URL เดิมก็ยังทำงานต่อไป
• ไม่จำเป็นต้องออกจากไซโลทั้งหมดในครั้งเดียว สามารถ เปลี่ยนผ่านแบบค่อยเป็นค่อยไป โดยเผยแพร่คอนเทนต์แต่ละประเภทบนไซต์ของตนเองก่อน
• ต้องคำนึงถึงการคงอยู่ระยะยาวในระดับสุดขั้วด้วย
  • อาจพิจารณา “dead man's switch” เพื่อส่งมอบกุญแจของไซต์ให้คนที่ไว้ใจหลังเสียชีวิต
  • ยังต้องแก้ด้วยว่าใครจะจ่ายค่าโดเมนหลังผู้ดูแลหายไป
• การดูแล เว็บไซต์ส่วนตัวที่ไม่สมบูรณ์แบบแต่มีเอกลักษณ์ อย่างสนุกสนาน สอดคล้องกับหลักการของ IndieWeb มากกว่าเทมเพลตที่สมบูรณ์แบบแต่ดูแลแล้วน่าเบื่อ

[GN⁺]

ความคิดเห็นบน Hacker News

• ถ้า IndieWeb ต้องการคอนเทนต์ การเอามันไปฝังไว้ใต้ กองเทคโนโลยีที่ซับซ้อน ก็เป็นสิ่งตรงกันข้ามอย่างสิ้นเชิง
  ชุดโปรโตคอลนี้แทบใช้ไม่ได้จริงสำหรับผู้ใช้ 90% และถ้าจะให้ความสำคัญกับประสบการณ์ผู้ใช้ด้านคอนเทนต์ ก็จำเป็นต้องมีโซลูชันคลิกเดียวที่เริ่มได้ทันที
  ทันทีที่บังคับให้ใช้ command line, Docker หรือแก้ HTML/CSS เอง ก็เท่ากับสร้างกำแพงที่คนส่วนใหญ่ข้ามไม่ได้ และสภาพตอนนี้ดูใกล้เคียง NerdNet มากกว่า IndieWeb

  • ถ้าดูชุมชนและวิกิของ IndieWeb จะเห็นว่ามีคนจำนวนมากเห็นด้วยกับแนวคิด ให้ประสบการณ์ผู้ใช้มาก่อน
    micro.blog ซึ่งเป็นจุดเริ่มต้นแบบคลิกเดียวที่เป็นตัวอย่างเด่น ให้บริการเว็บไซต์ส่วนตัวพร้อมฟีเจอร์ IndieWeb สมัยใหม่ในราคา 5 ดอลลาร์ต่อเดือน
    ตอนนี้คนที่สนใจส่วนใหญ่เป็นนักพัฒนาที่อยากสร้างเอง บทความที่เกี่ยวข้องจึงดูเต็มไปด้วยเทคนิค แต่การดึงคนที่ไม่ใช่นักพัฒนาเข้ามาก็เป็นความเปลี่ยนแปลงที่ชุมชนต้องการเช่นกัน David Shanske ทำปลั๊กอิน WordPress ที่มีเครื่องมือ IndieWeb มาให้ตั้งแต่ต้นมาตลอด 10 ปีที่ผ่านมา: https://profiles.wordpress.org/dshanske/#content-plugins
    ไม่ใช่ว่าต้องใช้เทคโนโลยีทั้งหมดถึงจะเป็น IndieWeb ได้ เริ่มจาก โดเมนของตัวเอง สร้างหน้าด้วย HTML, Markdown, Django ฯลฯ แล้วค่อยเพิ่ม microformats และ Webmention ทีละอย่างก็พอ และไม่ว่าจะอยู่ขั้นไหนก็ถือเป็นเว็บไซต์ IndieWeb ได้
  • ตรงกันข้าม ถ้าเปิดให้ทุกคนเข้ามา สิ่งดี ๆ ก็จะพัง เหมือน Eternal September ที่เต็มไปด้วยสื่อคุณภาพต่ำและ clickbait ไม่รู้จบ ดังนั้น กำแพงการเข้าถึงและข้อจำกัดการมีส่วนร่วม จึงมีประโยชน์
    อินเทอร์เน็ตดีกว่านี้ตอนที่ยังเป็นพื้นที่ซึ่งคนน่าสนใจมารวมตัวกันเอง ก่อนจะกลายเป็น Walmart ระดับโลก
  • เพิ่งรู้จักเรื่องนี้ไม่นาน แต่ก็โทษ IndieWeb ได้ยาก คนที่อยากหลุดจากสวนปิดของแพลตฟอร์มโซเชียลมักเป็นวิศวกรหรือคนที่คุ้นกับเว็บ และเป็นเรื่องธรรมชาติที่จะใช้เครื่องมือที่ตัวเองรู้จักมาแก้ปัญหา
    อินเทอร์เน็ตก็พัฒนามาแบบนี้เสมอ เริ่มจาก สิ่งที่ยากแต่สนุกซึ่งพวก geek สร้างขึ้น แล้วค่อย ๆ กลายเป็นสิ่งที่คนทั่วไปใช้ได้ง่ายขึ้น IndieWeb ก็ยังอยู่ในระยะแรก และถ้าอยู่รอดได้ การแพร่สู่ผู้ใช้วงกว้างก็น่าจะตามมาเอง ตอนนี้จึงควรปล่อยให้สร้างกันต่อไป
  • ในปี 2014 เราเริ่มสตาร์ทอัพชื่อ Known ที่ทำเป้าหมายนี้ให้เป็นจริงในฐานะส่วนหนึ่งของขบวนการ IndieWeb และโค้ดโอเพนซอร์สก็ยังอยู่
    ปัญหาคือความคุ้มค่าทางเศรษฐกิจ โซลูชันคลิกเดียวเป็นเรื่องดี แต่ IndieWeb แก้ปัญหาเชิงอุดมการณ์มากกว่าแก้ปัญหาเร่งด่วนของผู้ใช้ จึงยากที่จะหาลูกค้าที่พอจะรองรับการลงทุนหรือค่าใช้จ่ายในการเดินบริการได้
    micro.blog ใกล้เคียงที่สุด แต่เป็นบริการแบบรวมศูนย์ที่รันบนอินฟราของตัวเองไม่ได้ จึงแม้จะเข้ากันได้ในระดับโปรโตคอล ก็ยังไม่ใช่เครื่องมือ IndieWeb อย่างสมบูรณ์
    ยังมีความเป็นไปได้อย่างบันทึกกิจกรรมของเอเจนต์ หรือเครื่องมือเผยแพร่ของเซ็นเซอร์และเซิร์ฟเวอร์ แต่ถ้าไม่มี ความต้องการจากผู้ใช้จริง ก็ดูยากที่จะเป็นบริการสำเร็จรูปได้
  • รู้ดีว่ามันยากสำหรับผู้ใช้ 90% แต่ก็ไม่ได้สนใจ เช่นเดียวกับซอฟต์แวร์เสรี IndieWeb เป็นปรัชญาของการ แก้ปัญหาความต้องการของตัวเองโดยตรง โดยไม่รับค่าตอบแทน ไม่ได้มีเป้าหมายเพื่อครองตลาด
    ควรส่งเสริมให้ผู้คนสร้างสิ่งที่ต้องการ แทนที่จะยอมจำนนต่อสิ่งที่เป็นที่นิยม อาชีพสายการตลาดที่หมกมุ่นกับกลยุทธ์แสวงหาค่าเช่าและการล็อบบี้ มากกว่าสร้างคุณค่าจริง ทำให้สังคมแย่ลง จึงควรมีน้อยลง

• วิธีคิดของ Nostr ดูใกล้กับ POSSE มากกว่า Mastodon หรือ AT Protocol จึงชอบมากกว่า

  • ชอบ Org Social มากกว่า Nostr มาก: https://en.andros.dev/blog/8c640241/why-org-social-when-you-...
  • สงสัยว่า Nostr หลุดจาก วัฒนธรรมที่มี bro coin เป็นศูนย์กลาง ไปแล้วหรือยัง

• ถ้าบล็อกเป็นประจำและเป็นเจ้าของโดเมนกับโพสต์เอง แต่กลับไม่ถือว่าเป็น IndieWeb เพียงเพราะใช้ WordPress สุดท้ายก็เท่ากับยังพึ่งพาบริษัทอยู่ดี บล็อกที่เคยทำบน Blogger ในอดีตจำนวนมากก็ยังอยู่เหมือนเดิมมาเกือบ 10 ปีแล้ว
  การเป็นเจ้าของเซิร์ฟเวอร์เอง ไม่ใช่เรื่องสมจริง ถ้าเป็นเซิร์ฟเวอร์เสมือนก็อยู่บนคลาวด์ของ Amazon หรือ Microsoft และแม้จะเป็นเซิร์ฟเวอร์จริง ก็ต้องเอาไปไว้ในดาต้าเซ็นเตอร์ของบริษัทอยู่ดี แถมยังยากที่จะดูแล UPS และอินเทอร์เน็ตที่เชื่อมต่อถาวรเองทั้งหมด

• ทางเลือกเดิม ๆ มักหยุดอยู่แค่การไล่ตามความคิดถึงยุค 1990 จนแทบหา उपयोगอะไรไม่ได้ นอกจากความรู้สึกย้อนยุคชั่วครู่ แต่วิธีนี้ดูต่างออกไป
  มัน ยอมรับเว็บสมัยใหม่ ขณะเดียวกันก็ให้ผู้สร้างควบคุมพื้นที่ของตัวเองได้อย่างสมบูรณ์ ถ้ามีเวลา อยากให้บล็อก myzopotamia.dev เข้าร่วม IndieWeb

• indiekit แทบจะให้ ฟีเจอร์ IndieWeb ทั้งหมด มาในตัว ใช้อยู่ที่ https://rmendes.net และกำลังทำเพื่อเอาไปใช้งานใน https://textcaster.app ด้วย

• ปัญหาเรื่อง หลักการไม่ทำซ้ำ (DRY) ของ RSS feed ดูถูกพูดเกินจริงไปหน่อย ไม่ว่าจะเขียนด้วยเฟรมเวิร์กโอเพนซอร์สไหน ก็จำไม่ได้ว่าเคยมีปัญหาในการสร้าง RSS feed อัตโนมัติ

  • ถึงอย่างนั้นความซ้ำซ้อนของ RSS ก็ชัดเจน มันทำซ้ำหน้ารายการของเว็บไซต์ทั้งหน้า และทั้งที่มี h-entry อยู่แล้ว ก็ยังต้องดูแลคอนเทนต์เดียวกันสองเวอร์ชันกับ XML ซึ่งน่าหงุดหงิดอยู่บ่อย ๆ
    RSS ถูกคิดขึ้นในช่วงเวลาที่ไม่ดีนัก คือ ก่อนการปฏิวัติ semantic markup ไม่นาน หลังยุคเลย์เอาต์แบบตารางกำลังจะจบลง
  • ดูเหมือนมีน้อยคนที่ชอบสร้างหรืออ่าน RSS feed ทางเลือกมีมากมาย แต่ยังไม่มีอะไรเหนือกว่า ความแพร่หลายของ RSS ได้

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

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

• การทำให้เครื่องอ่านคอนเทนต์ได้โดยไม่ต้องมีไฟล์ขนานหรือ API แทบไม่ใช่ปัญหาที่จำเป็นต้องแก้ตั้งแต่แรก
  เช่นเดียวกับ ontology รุ่นก่อน ๆ มัน ไม่มีประโยชน์ต่อผู้เข้าชมที่เป็นมนุษย์ และมีแต่ป้อนข้อมูลให้ตัวการที่เป็นปฏิปักษ์

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

• สงสัยว่ารู้ไหมว่าโดเมน .dev เป็น ของ Google

  • รู้ และอยากได้โดเมนระดับบนสุดส่วนตัว แต่ขั้นตอนดูซับซ้อน