.self: โดเมนระดับบนสุดใหม่ที่ออกแบบมาเพื่อรองรับการโฮสต์ด้วยตนเอง

 (hccf.onmy.cloud)
4 คะแนน โดย GN⁺ 19 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ข้อเสนอสำหรับโดเมนระดับบนสุดใหม่ .self ที่รองรับการโฮสต์ด้วยตนเองตั้งแต่รากฐาน เพื่อให้ทุกคนสามารถ เป็นเจ้าของข้อมูลของตนเองได้อย่างสมบูรณ์
  • ความพยายามสร้าง สถาปัตยกรรมเว็บทางเลือก เพื่อเปลี่ยนโครงสร้างที่โครงสร้างพื้นฐานอินเทอร์เน็ตถูกใช้ในการดึงข้อมูลและแสวงประโยชน์จากความสนใจของผู้ใช้
  • ดำเนินงานในฐานะ สาธารณประโยชน์ (public good) และใช้ การกำกับดูแลแบบเปิด ที่ให้ชุมชนมีส่วนร่วมตัดสินใจเกี่ยวกับฟีเจอร์ กฎ และข้อจำกัดทั้งหมด
  • ให้ซับโดเมนฟรีหนึ่งรายการต่อหนึ่งคน พร้อมบริการ แบบใช้ร่วมกัน เช่น VPN tunnel และเมลเซิร์ฟเวอร์ รวมถึงไคลเอนต์โอเพนซอร์สแบบบูรณาการ
  • ในฐานะผู้เข้าร่วมที่ได้รับอนุมัติใน Applicant Support Program (ASP) ของ ICANN เป็นความพยายามขององค์กรไม่แสวงหากำไร 501(c)(3) ในการสร้าง โครงสร้างพื้นฐานอินเทอร์เน็ตที่ยึดมนุษย์เป็นศูนย์กลาง

การตระหนักถึงปัญหาและที่มาของการผลักดัน

  • อินเทอร์เน็ตเป็น เครื่องมือสื่อสาร ที่ทรงพลังที่สุดในประวัติศาสตร์ แต่โครงสร้างพื้นฐานที่รองรับกลับถูกอุตสาหกรรมเทคโนโลยีนำไปใช้ในทิศทางที่ดึงข้อมูลผู้ใช้และแสวงประโยชน์จากความสนใจ
  • เพื่อเปลี่ยนพลวัตเช่นนี้ จำเป็นต้องสร้าง สถาปัตยกรรมทางเลือก สำหรับเว็บ
  • ในฐานะผู้เข้าร่วมที่ได้รับอนุมัติใน Applicant Support Program (ASP) ของ ICANN ได้เปิดตัวแคมเปญอย่างเป็นทางการเพื่อให้ได้มาซึ่ง โดเมนระดับบนสุด (TLD) ใหม่ที่อุทิศให้กับเทคโนโลยีเชิงจริยธรรมและยึดมนุษย์เป็นศูนย์กลางอย่างเต็มที่

ภาพรวมโดเมน .self

  • โดเมนระดับบนสุดที่สร้างขึ้นใหม่ตั้งแต่รากฐานเพื่อรองรับ การโฮสต์ด้วยตนเอง (self-hosting)
  • ดำเนินงานในฐานะ สาธารณประโยชน์ (public good) และออกแบบ·นำไปใช้ตามหลักการที่ยึดมนุษย์เป็นศูนย์กลาง
    • สนับสนุนให้ทุกคนมี สิทธิ์ความเป็นเจ้าของอย่างสมบูรณ์ เหนือข้อมูลของตนเอง

ฟีเจอร์หลัก (Core Features)

  • หนึ่งคน หนึ่งซับโดเมน (One Person, One Subdomain)

    • มอบ ซับโดเมนฟรี ให้ผู้ใช้ทุกคน
    • ห้ามการจอดโดเมน (parking), การกักตุนโดเมน (squatting) และการนำไปขายต่อ (reselling)

  • บริการแบบใช้ร่วมกัน (Shared Services)

    • ให้บริการ VPN tunnel สำหรับที่อยู่ IP ส่วนตัว
    • ให้บริการ เมลเซิร์ฟเวอร์ที่เชื่อถือได้ (trusted mail server)

  • ไคลเอนต์ซอฟต์แวร์โอเพนซอร์ส (Open Source Software Clients)

    • ให้บริการ ไคลเอนต์ สำหรับบริการเมลและ VPN แบบใช้ร่วมกัน
    • ฟีเจอร์ สร้างใบรับรอง TLS
    • รองรับ DNS แบบไดนามิก (Dynamic DNS)
    • local DNS resolver พร้อมฟีเจอร์แคช

  • การกำกับดูแลแบบเปิด (Open Governance)

    • ตัดสินใจเกี่ยวกับฟีเจอร์ กฎ และข้อจำกัดทั้งหมดตาม ความคิดเห็นจากชุมชน (community input)

ผู้ดำเนินงาน

  • Human-Centered Computing Foundation เป็นองค์กรไม่แสวงหากำไร 501(c)(3)
  • สร้าง โครงสร้างพื้นฐาน มาตรฐาน และชุมชน เพื่อโลกดิจิทัลที่เป็นมนุษย์มากขึ้น
  • ขอ การสนับสนุนจากภายนอก เช่น การบริจาค การแชร์ การมีส่วนร่วมของชุมชน และข้อเสนอแนะ

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
kaydash 10 시간 전

ตอนแรกคิดว่าน่าจะดีเลยลองเข้าไปดู แต่ดูแล้วไม่ค่อยเท่าไหร่ เฮ้อ
 
GN⁺ 19 시간 전
ความคิดเห็นบน Hacker News

  • นึกถึงตอนที่ .tk TLD เปิดให้ใช้ฟรีเมื่อ 20 ปีก่อน นักพัฒนาสายงานอดิเรกต่างก็ไปจดกันคนละโดเมน จากนั้นพวกมิจฉาชีพก็แห่เข้ามา สุดท้าย Facebook กับโปรแกรมแอนติไวรัสก็เริ่มบล็อก
    จำได้ว่าเคยเอาเว็บไซต์ที่ทำเป็นงานในชั้นเรียนไปไว้บนโดเมน .tk แล้วครูเปิดไม่ได้ จนเกือบสอบตก

    • ความทรงจำนั้นกลับมาเลย .tk มีอยู่ทุกที่จริง ๆ และยังจำตำนานเมืองที่ว่าโดเมน .tk คิดเป็น กี่เปอร์เซ็นต์ของ GDP ได้ด้วย
    • เพราะไม่มีเงินค่าขนมพอซื้อโดเมน .com ช่วงสองสามปีแรกของการโฮสต์เองเลยประคองตัวด้วย freenom / tk + Cloudflare
    • ถึงอย่างนั้น https://tcl.tk ก็ยัง redirect ไปที่ https://www.tcl-lang.org/
    • tk กับ cc เป็นโดเมนที่สมัยก่อนใช้กับ PHP reverse shell พอเห็นแล้วก็ชวนให้นึกถึงวันเก่า ๆ

  • ตลอด 10 ปีที่ผ่านมา ผมทำงานอยู่บ้างเกี่ยวกับการนิยาม เป้าหมายด้านตัวตนที่ยึดมนุษย์เป็นศูนย์กลาง บนอินเทอร์เน็ต ลองดู Microsoft Vega ก็น่าจะดี: https://www.microsoft.com/en-us/research/blog/vega-zero-know...
    ดูเหมือนเป็นแนวทางที่พยายามตอบโจทย์หลักของบริการที่ต้องยืนยันตัวตนออนไลน์ ให้เป็นมิตรต่อความเป็นส่วนตัวมากที่สุด ตัวอย่างเช่น ถ้า .self มอบโดเมนเดียวที่ปกปิดตัวตนให้กับทุกคนทั่วโลกได้ก็น่าจะดี อาจจินตนาการได้เป็นสองโซน เช่น xxx.v.self คือยืนยันแล้ว ส่วน xxx.u.self คือยังไม่ยืนยัน
    ทั้งสองแบบตรวจสอบด้วย zero-knowledge proof ว่ายังไม่เคยจดโดเมนนั้นมาก่อน ส่วนโดเมนที่ยืนยันแล้ว หากจำเป็นก็ฝาก PII ไว้กับ registrar หรือ data broker เพื่อใช้ยืนยัน/ตรวจสอบ ขณะที่โดเมนที่ยังไม่ยืนยันจะรักษาสัญญาว่า “หนึ่งโดเมน = หนึ่งคน” แต่ทำให้ TLD หรือ registrar ไม่สามารถเปิดเผยได้ว่าคนจริง ๆ คือใคร กรณีใช้งานแบบนี้สามารถทดลองกับโดเมนทั่วไปก่อนได้ และเสนอให้เข้ากับกระบวนการเปิดตัว TLD หรือการประมูลของ ICANN ได้

    • อยากให้ส่งเรื่องนี้ผ่านแบบฟอร์มติดต่อ ต้องการ ความคิดเห็นจากชุมชน จำนวนมาก: https://hccf.onmy.cloud/get-involved/
    • เป็นเรื่องดีที่ Microsoft Vega ทำให้ การพิสูจน์ตัวตนบนฐาน zero-knowledge แพร่หลายขึ้น แต่น่าเสียดายที่ทำในรูปแบบค่อนข้างตายตัว
      ผมคิดว่าน่าจะดีกว่าถ้าทีม Vega วาง zkVM เอนกประสงค์ไว้เป็นแกนกลาง แทนที่จะใช้วงจร zero-knowledge เฉพาะแอปพลิเคชัน อย่างแรกให้ประโยชน์ด้านประสิทธิภาพเพียงชั่วคราว ส่วนอย่างหลังให้ข้อได้เปรียบด้านความยืดหยุ่นในระยะยาว ช่วงไม่กี่ปีที่ผ่านมา ประสิทธิภาพของ zkVM ดีขึ้นหลายลำดับขั้น ดังนั้นผู้สนับสนุนความเป็นส่วนตัวแบบ zero-knowledge ไม่จำเป็นต้องยึดติดกับประสิทธิภาพการพิสูจน์ของระบบปัจจุบันมากเกินไป
      กล่าวคือ งานที่ทีม Vega ทำด้วย Nova นั้นฉลาดมาก แต่มีบางส่วนที่ไม่จำเป็นแล้วเพราะประสิทธิภาพของการคำนวณเอนกประสงค์ดีขึ้น สิ่งอย่าง RISC Zero ทำให้รันโค้ด Rust ใด ๆ ภายใน zero-knowledge ได้ในระดับหลายร้อยมิลลิวินาทีโดยแทบไม่ยุ่งยาก การยืนยันตัวตนเป็นเพียงหนึ่งในแอปพลิเคชันที่มีประโยชน์จำนวนมากซึ่งเป็นไปได้ด้วย แพลตฟอร์มการคำนวณแบบ zero-knowledge ที่ได้รับการยอมรับอย่างกว้างขวาง

  • สงสัยส่วนที่บอกว่า “ทุกคนมีสิทธิ์ได้รับซับโดเมนฟรี” ใน https://hccf.onmy.cloud/wp-content/uploads/2026/06/dot-self....
    ไม่รู้ว่ามีแผนจะรับภาระ ต้นทุนการดำเนินงาน TLD อย่างไรโดยไม่มีรายได้จากค่าจดทะเบียน อยากรู้ว่าเป็นสินค้าล่อให้ใช้บริการอื่น หรือเป็นโมเดลบริจาค 100%
    ยังมีข้อ “ห้ามจอดโดเมน ห้ามกว้านจอง ห้ามขายต่อ” ด้วย แต่ก็ไม่ชัดเจนว่าจะจำแนกการใช้งานที่ชอบด้วยกฎหมายแต่ไม่ได้ให้บริการสาธารณะ ออกจากการจอดโดเมนหรือการกว้านจองอย่างไร

    • โดเมนนี้มีแผนจะดำเนินงานเป็น สาธารณสมบัติ และกำลังมองหาผู้สนับสนุนที่จะช่วยด้านเงินทุนอย่างจริงจัง มองว่าเป็นโมเดลคล้าย ISRG กับ Let’s Encrypt ได้
      หวังว่ากฎ “หนึ่งซับโดเมนต่อหนึ่งคน” จะช่วยกันการกว้านจองขนาดใหญ่ได้ แต่ก็ยอมรับว่าการตรวจสอบโดเมนใดโดเมนหนึ่งอย่างละเอียดนั้นยากกว่า อาจต้องใช้ heartbeat บางรูปแบบที่เจ้าของต้องตอบกลับภายในเวลาที่กำหนด
    • ผมสงสัยว่าในความเป็นจริงการดำเนินงาน TLD มีต้นทุนสูงขนาดนั้นหรือไม่ ตัว TLD เองแค่ต้องเผยแพร่เรคคอร์ด nameserver และโดยทั่วไป TTL ก็ราวหนึ่งวัน การตอบ DNS มีขนาดแค่ระดับหลายร้อยไบต์
      ผู้ให้บริการ DNS รายใหญ่อย่าง Google หรือ Cloudflare คงจะร้องขอทุกวันสำหรับทุกโดเมนที่มีการใช้งานจริง แต่ก็แคชไว้ ผู้ให้บริการรายเล็กอาจแคชได้ไม่ดีเท่า แต่ก็ไม่ได้ร้องขอทุกโดเมนทุกวันเช่นกัน ถ้ามีโดเมนส่วนบุคคล 1 ล้านโดเมน ก็ดูเหมือนทราฟฟิกประมาณไม่กี่ TB ต่อเดือน อาจมากกว่าค่าใช้จ่ายของโปรเจกต์งานอดิเรกส่วนบุคคลเล็กน้อย แต่ไม่ถึงขั้นเกินเอื้อมสำหรับองค์กรไม่แสวงหากำไรขนาดเล็ก
      การแยกโดเมนที่ถูกกว้านจองค่อนข้างง่าย เพราะคนกว้านจองซื้อมาเพื่อขายต่อ ดังนั้นต้องประกาศต่อสาธารณะให้ผู้ซื้อรู้ว่ากำลังขายอยู่ ถ้ามีใครนำโดเมนนั้นไปลงขายที่ไหนก็ตาม ก็ให้ขอหลักฐานความเป็นเจ้าของ และผู้ซื้อจริงก็ต้องขอหลักฐานแบบเดียวกันเพื่อเลี่ยงการถูกหลอก ดังนั้นทันทีที่พิสูจน์ ก็ยึดโดเมนได้เลย น่าเสียดายด้วยซ้ำที่ไม่ได้ใช้กฎแบบนี้กับทุกโดเมน
    • ตรงนี้ไม่ชัดเจนว่ากำลังหมายถึงโดเมนจริง ๆ หรือ ซับโดเมน ซึ่งในฐานะ registrar ที่อาจเข้าร่วม ถือเป็นสัญญาณที่น่ากังวล
    • ไม่แน่ใจว่าการดำเนินงาน TLD แพงขนาดนั้นจริงไหม nameserver ขึ้นชื่อว่าเสถียรได้ยาวนานมาก แม้รันบนเซิร์ฟเวอร์สเปกเก่า
      ถ้าออกแบบดี ๆ ขั้นตอนการจดทะเบียนก็น่าจะรันบนโครงสร้างพื้นฐานเบา ๆ ได้เช่นกัน ถ้าไม่นับเวลา ค่าใช้จ่ายรวมต่อปีอาจอยู่ราว 1,000–5,000 ดอลลาร์ และเป็นขนาดที่เหมาะพอสำหรับโปรเจกต์งานอดิเรกที่น่าสนใจ
    • อาจเป็นบริการสาธารณะก็ได้ หลายประเทศดำเนินบริการสาธารณะที่มีต้นทุนดำเนินงานสูงกว่า TLD แบบนี้หลายลำดับขั้นมาหลายศตวรรษแล้ว

  • ไม่เข้าใจว่า ระบบการตั้งชื่อ นี้คืออะไร และดูเหมือนแทบไม่มีระบบเลยด้วยซ้ำ ถ้าใช้วิธีแบบ UUID ยังพอจะสมเหตุสมผลกว่า
    ถ้าแจกให้คนทั่วโลก 7 พันล้านคน คนละหนึ่งชื่อ ก็จะน้อยกว่า 33 บิตเล็กน้อย และถ้าเผื่ออนาคตกับพื้นที่ภายในไว้โดยปรับเป็น 40 บิต ก็จะกลายเป็นการเลือกคำ 5 คำจากรายการคำ 256 คำ ดูสมเหตุสมผลกว่าการมาก่อนได้ก่อนมากสำหรับ .self ที่เอาไปใช้ในทางผิดได้ง่าย
    ที่สำคัญกว่านั้นคือ ผมไม่เข้าใจว่าทำไมสิ่งนี้ต้องใช้ TLD และขั้นตอนยุ่งยากที่ตามมาด้วย จะเอาไปต่อกับโดเมนที่เข้าถึงได้สักชื่อ เช่น onmy.cloud ก็ทำแบบเดียวกันได้ ผมมีคำถามแบบเดียวกันกับแทบทุก TLD และก็ไม่มั่นใจด้วยว่าตัวเองคิดผิด
    อย่างน้อยถ้าอยากแสดงความจริงจังต่อ ICANN ก็ควรเริ่มให้บริการจริงบน onmy.cloud ก่อน แล้วบอกว่าถ้าได้ .self มา จะย้ายโดเมน onmy.cloud เดิมไปเป็น .self ให้อย่างโปร่งใส วิธีที่ดีที่สุดในการแสดงว่า “ทำได้” ก็คือการลงมือทำจริง

  • เดี๋ยวนะ ไม่เข้าใจว่าทำไม .self ถึงไม่อยู่ในนี้: https://www.iana.org/domains/root/db
    สงสัยว่ายังอยู่แค่ขั้นไอเดีย หรือเป็นโครงสร้างแบบ “ต้องใช้ DNS ของเราเท่านั้นถึงจะแก้ชื่อโดเมน .self ได้” กันแน่

    • ตอนนี้ยังอยู่ในขั้นไอเดีย รอบการสมัคร gTLD รอบถัดไปเปิดอยู่ และกำลังรวบรวมแรงสนับสนุนระหว่างดำเนินขั้นตอนการสมัคร
    • ชื่อโดเมนไม่ได้เป็นแบบรวมศูนย์ และไม่มีองค์กรกลางที่ควบคุมรายชื่อโดเมนที่ได้รับอนุมัติ

  • เว็บไซต์ขึ้น error และทุกครั้งที่รีเฟรชก็มีข้อความ error ต่างกันออกมา 3 แบบ ดูเหมือนหน้า static ก็น่าจะพอแล้ว แต่เหมือนกำลังรันแบบ dynamic โดย โฮสต์เอง บนอะไรบางอย่างที่ประสิทธิภาพไม่พอ

    • ใช่ กระแสตอบรับมากกว่าที่คาดไว้มาก และตอนนี้กำลังพยายามตั้งค่า เว็บแคช อยู่

  • สำหรับ self hosting ผมก็ใช้ .home.arpa เฉย ๆ ฟรี และแค่จัดการเรื่องความเชื่อถือของใบรับรอง TLS root certificate ก็พอ ซึ่งถ้าทำไว้แล้วก็ค่อนข้างดี

    • ตอนนี้ .internal ก็ใช้งานได้ดีแล้วเหมือนกัน

  • your.self ผมอยากจองก่อนเลย น่าจะมี ซับโดเมนระดับสอง เจ๋ง ๆ ออกมาอีกเพียบ

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

  • ดูเหมือนเป็นวิธีที่ ตกเป็นเป้าหมายได้ง่าย สำหรับผู้โจมตี

  • ยังไม่เข้าใจทั้งหมดว่าสิ่งนี้ทำงานอย่างไร ใครเป็นคนกำกับดูแลและนิยามว่าอะไรคือ “self hosting” และอะไรคือ “เทคโนโลยีที่มีจริยธรรม”
    การเปิดตัว suffix โดเมนใหม่คงไม่ได้ช่วยแก้ปัญหาเรื่อง ฉันทามติแบบกระจายศูนย์และธรรมาภิบาล