Vouch - ระบบจัดการความน่าเชื่อถือของผู้มีส่วนร่วมโอเพนซอร์ส

 (github.com/mitchellh)
9 คะแนน โดย xguru 2026-02-09 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • โดยดั้งเดิมแล้วโอเพนซอร์สทำงานอยู่บนโมเดล trust and verify
  • เมื่อเครื่องมือ AI แพร่หลาย กำแพงการเข้ามามีส่วนร่วมแทบหายไป, โมเดลความไว้วางใจโดยนัยแบบเดิมจึงใช้งานไม่ได้อีกต่อไป
  • เป็นระบบจัดการความน่าเชื่อถือสำหรับโอเพนซอร์สที่ออกแบบให้ต้อง รับรองความน่าเชื่อถืออย่างชัดเจน (vouch) ก่อนจึงจะเข้าร่วมได้
  • ผู้มีส่วนร่วมที่ได้รับความไว้วางใจสามารถ vouch ให้ผู้ใช้อื่นได้ และผู้ไม่หวังดีสามารถถูกบล็อกอย่างชัดเจนด้วย denounce (ประณาม/แจ้งกล่าวโทษ)
    • denounce จะถูกเก็บเป็นบันทึกสาธารณะ ทำให้ โปรเจ็กต์อื่นสามารถใช้อ้างอิงได้
    • ใครจะ vouch/denounce ให้ใคร และใช้เกณฑ์ใด เป็นสิ่งที่ แต่ละโปรเจ็กต์กำหนดได้เอง
    • ระบบไม่ได้บังคับชุดคุณค่าใดเป็นพิเศษ และ การตัดสินใจเชิงนโยบายเป็นหน้าที่ของคอมมูนิตี้
  • ข้อมูลความน่าเชื่อถือทั้งหมดถูกเก็บและ จัดการเวอร์ชัน ไปพร้อมกับโค้ดในรูปแบบ ไฟล์ข้อความธรรมดาไฟล์เดียว (VOUCHED) ภายในรีโพซิทอรี เพื่อรับประกันความโปร่งใสและการพกพา
  • ในระยะยาวมีโครงสร้างเพื่อแบ่งปันข้อมูลความน่าเชื่อถือผ่านการสร้าง เครือข่ายความไว้วางใจ (Web of Trust) ระหว่างโปรเจ็กต์
    • โปรเจ็กต์ปลายทางสามารถ เลือกได้เอง ว่าจะยอมรับการตัดสินของโปรเจ็กต์ต้นทางตามนั้นหรือไม่
    • โปรเจ็กต์ที่ vouch/denounce อย่างไม่ไตร่ตรองสามารถ ถูกกันออกจากเครือข่ายความไว้วางใจโดยธรรมชาติได้
  • เชื่อมต่อได้ง่าย ผ่าน GitHub Actions และสามารถจัดการจากคอมเมนต์ใน issue หรือ PR ด้วยคีย์เวิร์ดอย่าง lgtm, denounce
  • Ghostty ได้ เปลี่ยนโมเดลการมีส่วนร่วม มาเป็นระบบแบบ vouch
  • พัฒนาโดยได้แรงบันดาลใจจากโปรเจ็กต์ Pi และขณะนี้ยังอยู่ใน ขั้นทดลอง

คำสั่งที่มีให้

  • ไฟล์ในเครื่อง
    • vouch.nu check <user>: ตรวจสอบสถานะ vouch/denounce ของผู้ใช้
    • vouch.nu add <user>: vouch ให้ผู้ใช้
    • vouch.nu denounce <user>: denounce ผู้ใช้
  • การเชื่อมต่อกับ GitHub
    • vouch.nu gh-check-pr <pr>: ตรวจสอบสถานะของผู้สร้าง PR และจัดการอัตโนมัติ
    • vouch.nu gh-manage-by-issue <issue> <comment>: vouch/denounce ตามคอมเมนต์ใน issue

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

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

 
kuthia 2026-02-09

ดูเหมือนว่าระบบนี้เองก็ต้องได้รับการยอมรับในฐานะผู้มีความน่าเชื่อถือก่อน จึงจะถูกยอมรับได้
 
xguru 2026-02-09

ดูเหมือนว่าพอได้รับความสนใจก็มีความเข้าใจผิดอยู่บ้าง เลยแยก FAQ ไว้ต่างหาก
https://x.com/mitchellh/status/2020628046009831542

  • ผู้เริ่มต้นและผู้เข้าร่วมใหม่เข้าร่วมได้ยาก
    • ไม่มีเหตุผลอะไรเลยที่การได้รับ Vouch จะต้องยาก
    • จุดประสงค์หลักของ Vouch คือป้องกันการเข้ามามีส่วนร่วมแบบไม่คิดหน้าคิดหลังโดยไม่ลงแรง
    • ในโปรเจ็กต์ของผม (รวมถึงโปรเจ็กต์นี้) ถ้าแนะนำตัวในอิสซูและอธิบายสั้น ๆ ว่าอยากมีส่วนร่วมอย่างไร ก็สามารถได้รับ Vouch ได้
    • พูดง่าย ๆ คือ ถ้าแนะนำตัวเหมือนการใช้ชีวิตในสังคมทั่วไป ก็จะได้รับ Vouch
    • แต่ถ้าใช้อำนาจในกลุ่มในทางที่ผิด ก็จะถูกลงโทษ
  • เปราะบางต่อ social engineering
    • ผู้ใช้ที่ได้รับ Vouch จะได้เพียงสิทธิ์ในการเข้าร่วมโปรเจ็กต์เท่านั้น
    • จะไม่ได้สิทธิ์ในการ merge pull request, push โค้ด, ทำ release เป็นต้น
    • งานทั้งหมดเหล่านี้ยังถูกจำกัดผ่านการรีวิวที่มีอยู่เดิมและการควบคุมของระบบ
    • นอกจากนี้ มีเพียงผู้ดูแลระบบ/ผู้ร่วมงานเท่านั้นที่สามารถรับรองผู้ใช้ได้
    • ดังนั้นต่อให้ผู้ใช้ที่มีปัญหาได้รับการรับรอง ก็จะไม่สามารถรับรองผู้ใช้อื่นต่อได้
  • ไม่มีขั้นตอนอุทธรณ์สำหรับ Denouncing
    • ขั้นตอนอุทธรณ์แตกต่างกันไปตามโปรเจ็กต์ย่อย
    • สำหรับโปรเจ็กต์ของผม หากติดต่อมาหาเราด้วยวิธีใดก็ได้ เช่น Discord หรืออีเมล แล้วคุยกันแบบคนปกติและยอมรับความผิดพลาด เราก็จะให้โอกาสอีกครั้ง ไม่ได้ยากอะไร
  • แก่นของโปรเจ็กต์นี้คือการที่ AI ให้ข้อมูลแก่ผู้คนผ่านการเรียกใช้ API เพื่อลดกำแพงตามธรรมชาติที่มีอยู่เดิมให้เหลือน้อยที่สุด
  • ในโปรเจ็กต์ชุมชนที่มีมนุษย์เป็นศูนย์กลาง จำเป็นต้องมีปฏิสัมพันธ์แบบมนุษย์เฉพาะที่แนวขอบเขตเท่านั้น
 
GN⁺ 2026-02-09
ความเห็นจาก Hacker News

  • ผมคิดว่าการสมมติว่า ผู้ใช้ที่เชื่อถือได้ ในโปรเจกต์หนึ่งจะถูกเชื่อถือโดยอัตโนมัติในอีกโปรเจกต์หนึ่งเป็นเรื่องอันตราย
    โครงสร้างแบบนี้อาจถูกนำไปใช้โจมตีแบบ supply chain attack ได้ เพราะผู้โจมตีสามารถสั่งสมความน่าเชื่อถือในฐานะ ‘ผู้มีส่วนร่วมที่ดูดี’ ในหลายโปรเจกต์ แล้วค่อยเข้าถึงโปรเจกต์เป้าหมาย
    ถ้าความเชื่อถือข้ามโปรเจกต์แบบนี้ถูกทำให้เป็นอัตโนมัติ บัญชีที่เคยได้รับความเชื่อถือเพียงครั้งเดียวก็อาจกลายเป็นเป้าหมายของการโจมตีได้ ผมว่าการเริ่มจาก ‘รายการไม่ไว้วางใจ’ น่าจะปลอดภัยกว่าการมี ‘รายการไว้วางใจ’

    • จากคำอธิบาย ดูเหมือนว่าจุดประสงค์ของระบบนี้จะไม่ใช่ความเชื่อถือในความหมายด้านความปลอดภัย แต่ใกล้เคียงกับ ตัวกรองสแปม ที่ใช้คัดกรอง ผลงานคุณภาพต่ำที่สร้างโดย AI มากกว่า
    • ความกังวลแบบนี้ออกจะพูดเกินจริงไปหน่อย Vouch เป็นแค่ ด่านจำกัดสิทธิ์การมีส่วนร่วม เท่านั้น ไม่ได้ให้สิทธิ์ merge โค้ด หลังจากนั้นขั้นตอนรีวิวแบบเดิมก็ยังคงอยู่ สุดท้ายก็อาจมองได้ว่าเป็นแค่ ชั้นลดสัญญาณรบกวน
    • การที่ผู้โจมตีแสร้งทำตัวดีเป็นเวลานานเพื่อสะสมชื่อเสียงนั้นเกิดขึ้นจริงอยู่แล้ว สุดท้ายคนก็จะรู้ได้เองว่าเขาเปลี่ยนไปแล้ว นี่มันสถานการณ์แบบ xkcd 810
    • ถ้าใครสักคนสูญเสียความน่าเชื่อถือ โปรเจกต์ทั้งหมดที่เคยเชื่อถือเขาก็จะเลิกเชื่อถือไปด้วย นี่เป็นแนวคิดแบบ ตัวกรองสแปม ไม่ใช่ความเชื่อถือระดับการเซ็นกุญแจ PGP ไม่ได้ออกแบบมาเพื่อหยุดผู้โจมตีระดับรัฐ แต่เป็นเครื่องมือสำหรับกัน AI สแปม PR
    • มันไม่ใช่ระบบที่สมบูรณ์แบบ แต่ผมคิดว่าเป็น “การปรับปรุงที่คุ้มค่ากับความยุ่งยาก” ถ้าเป็นผู้มีส่วนร่วมจริง ก็น่าจะคุ้มที่จะลงแรงเพิ่มอีกนิด ผมเองก็ยอมรับได้ประมาณนั้น

  • ผมคิดว่าถ้าเก็บ ค่าใช้จ่าย $1 สำหรับการส่ง PR ก็น่าจะดี
    ถ้า PR ใช้ได้จริง ผู้ดูแลค่อยคืนเงินให้
    ตอนนี้การสื่อสารมันง่ายเกินไปจนมี การสื่อสารคุณภาพต่ำ ล้นไปหมด ของพวกนี้ไม่ใช่แค่ไร้ค่า แต่เป็น โทษที่คอยกัดกินเวลา

    • แนวคิดแบบนี้สุดท้ายก็จะไปลงที่แนวคิด staking ในโลกคริปโต คือเอาโทเค็นไปล็อกไว้ แล้วถ้า PR ถูก merge ก็ได้คืน ในเชิงเทคนิคนับว่าดูดี แต่ พอมีเงินเข้ามาเกี่ยว การออกแบบผลิตภัณฑ์ก็จะเสื่อม ไม่ควรทำแบบนี้เด็ดขาด
    • “ถ้าอยากให้อ่านคอมเมนต์ของฉัน จ่ายมา $1” เป็นมุกตลก แต่ก็สะท้อนแก่นของไอเดียนี้ได้ดี
    • การตั้งต้นทุนให้การสื่อสารก็มีผลลบเหมือนกัน จุดสมดุลของต้นทุนที่เหมาะสม สำคัญมาก บทสนทนาคุณภาพต่ำจากคนใกล้ตัวพอรับได้ แต่การสื่อสารบน Twitter ของนักการเมืองน่าจะน้อยลงบ้างก็ดี
    • ท้ายที่สุดนี่คือปัญหาเรื่อง การผลักภาระต้นทุนออกไปให้คนอื่นรับ ซึ่งเกิดขึ้นในทุกด้าน ทั้งการผลิต การสื่อสาร การสร้างโค้ด และตอนนี้แม้แต่ชื่อเสียงส่วนบุคคลเองก็แทบไม่มีต้นทุนแล้ว
    • ถ้าเป็นโครงสร้างแบบนี้ ผมน่าจะไม่ส่ง PR เลย ตอนนี้ PR จำนวนมากก็ไม่ได้รับการตอบกลับอยู่แล้ว ถ้ายังต้องจ่ายเงินอีก ผมก็คง แก้ใน fork ของตัวเอง แทน ถ้าโครงสร้างไม่มีแรงจูงใจให้คืนเงินก็ยิ่งไม่ยุติธรรม ต่อให้มี บริการ escrow ก็ยิ่งซับซ้อนขึ้น ผมแค่อยากแก้บั๊ก ไม่อยากเจอกระบวนการแบบนี้

  • ผมสงสัยว่าถ้าผู้มีส่วนร่วมหน้าใหม่ไม่มีเครือข่ายเลย จะ ฝ่ากำแพงการเข้าสู่ระบบนี้ได้อย่างไร
    ถึงจะมีเสียงรบกวนจาก AI เยอะ แต่นี่ก็ไม่ใช่วิธีแก้

    • ในโปรเจกต์ OSS ของผม ผมชอบให้ เสนอผ่าน issue หรือการพูดคุยก่อน มากกว่าส่ง PR มาเลย เพราะ PR มักสร้างสถานการณ์ที่ปฏิเสธยากเมื่อมันไม่สอดคล้องกับทิศทางของโปรเจกต์
    • อีกวิธีก็คือให้ผู้มีส่วนร่วม อธิบายแพตช์ผ่านวิดีโอคอล ผมเคยใช้วิธีนี้กรอง ผู้สมัครหลอกลวง ออกได้จริง ทุกวันนี้ FOSS แทบกลายเป็น เกมตรวจจับการหลอกลวง ไปแล้ว
    • ดูเหมือนจะเป็นโครงสร้างที่ค่อย ๆ จำกัดการเข้าถึงเป็นลำดับขั้น เช่น ตรวจสอบใน staging environment ก่อน แล้วค่อยอนุญาตให้เข้าถึง production ซึ่งเป็นวิธีที่พบได้ทั่วไปในโลก ops อยู่แล้ว
    • มันขึ้นอยู่กับการตั้งค่า Vouch บางที่อาจปิดหมดเลย บางที่อาจเปิด issue และการสนทนาไว้ แต่จำกัดเฉพาะ PR ก็ได้ ควรใช้ให้ สอดคล้องกับธรรมเนียมของแต่ละโปรเจกต์เหมือน Linux

  • ผมไม่เห็นด้วยกับคำพูดที่ว่า “โอเพนซอร์สทำงานอยู่บน ระบบที่เชื่อใจและตรวจสอบ”
    ตามอุดมคติแล้วควรประเมินจากโค้ดได้ด้วยตัวมันเอง
    เวลาผมดู PR ผมใช้เวลาไม่กี่วินาทีก็ตัดสินได้ว่าจะ merge หรือไม่ เรื่องยากคือ การเขียนเหตุผลปฏิเสธอย่างสุภาพ
    (อ้างอิง: ที่เก็บ openpilot)

    • ผมเพิ่งไปดูโค้ดของ openpilot มาเมื่อไม่นานนี้ โครงสร้างอย่าง msgq/cereal, Params, visionipc น่าสนใจดี
    • เวลามีเวลาก็รีวิว เวลายุ่งก็ใช้ความเชื่อใจ มันก็หมุนไปแบบนั้น

  • ผมสงสัยว่าโปรเจกต์ Vouch จะป้องกันไม่ให้กลายเป็น ฟองสบู่ปิดแบบ Bluesky ได้อย่างไร
    หลังการเลือกตั้ง Bluesky ก็ยิ่งหดตัวลงเรื่อย ๆ การทำ social filtering แบบนี้อาจขัดขวางผู้มีส่วนร่วมหน้าใหม่ได้

    • จำนวนหลังเลือกตั้งลดลงจริง แต่ก็ยังมีผู้ใช้มากกว่าก่อนหน้านั้นอยู่ดี จากสถิติจะเห็นว่าเป็นรูปแบบ พุ่งขึ้นแล้วคงตัว
      อีกอย่าง จุดประสงค์ของ Vouch ก็คือ การเพิ่มกำแพงการเข้าถึง ตั้งแต่แรก ดังนั้นคงไม่ได้กังวลเรื่องนี้มากนัก
    • แต่ละโปรเจกต์สามารถมี ระบบ vouch ของตัวเอง ได้ และชุมชนก็อาจแสดงความเห็นคัดค้านผ่าน issue หรือ PR ได้
    • มีมุมมองแบบ “ถ้าเกิดฟองสบู่แบบ Bluesky ขึ้นมาจะทำยังไง?” → “นั่นอาจเป็นสิ่งที่ตั้งใจไว้ก็ได้”
    • น่าสนใจที่บัญชีที่ถูกบล็อกมากที่สุดบน Bluesky คือ บัญชีทางการของรัฐบาล ซึ่งสะท้อนอีกด้านของชุมชนปิดได้ดี

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

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

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

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

  • ผมลองจินตนาการถึง forge แบบมินิมอลที่เหลือไว้เฉพาะสิ่งที่ Git ทำไม่ได้โดยพื้นฐาน
    แกนสำคัญคือ Identity , Attestation ที่มีลายเซ็น และ Policy
    Vouch จัดการกับลายเซ็นที่ผูกกับตัวบุคคล — ลายเซ็นว่า “คนนี้เชื่อถือได้” มีโครงสร้างแบบเดียวกับลายเซ็นว่า “คอมมิตนี้ผ่านการทดสอบแล้ว”
    กล่าวคือมันคือ ชั้นนโยบายที่ควบคุมการมีส่วนร่วมตั้งแต่ต้นทาง
    ฟังก์ชันแบบนี้ควรอยู่ในรูปของ metadata ภายใน repo ไม่ใช่ผูกอยู่กับแพลตฟอร์มปิดอย่าง GitHub
    ผมสงสัยว่าอีก 5 ปีข้างหน้าแนวคิดนี้จะพัฒนาไปได้ไกลแค่ไหน

    • ถ้าเก็บ metadata แบบนี้ในรูปมาตรฐานอย่างโฟลเดอร์ .github/ ก็อาจสร้าง โมเดลความเชื่อถือที่ไม่ขึ้นกับแพลตฟอร์ม ได้
      ในยุคที่โค้ดจาก LLM เพิ่มขึ้นเรื่อย ๆ โครงสร้างพื้นฐานด้าน ชื่อเสียง แบบนี้อาจกลายเป็นองค์ประกอบจำเป็นของอินเทอร์เน็ต

  • ตอนแรกมันดูโอเค แต่สุดท้ายก็ดูเหมือนจะลงเอยเป็นโครงสร้างแบบ “เฉพาะคนที่ได้รับความเชื่อถือแล้วเท่านั้นที่มีส่วนร่วมได้”

    • ถึงจะไม่ใช่ของใหม่ล้ำมาก แต่ก็มีความหมายในแง่ที่ว่า การลงมือทำอย่างออกแบบมาดี สำคัญ
    • คล้ายกับ killfile ของ Usenet สมัยก่อน หรือ รายการสแปมแบบ RBL
      (killfile wiki, DNS blocklist)
    • สำหรับโปรเจกต์ขนาดใหญ่ โครงสร้างแบบนี้น่าจะเหมาะกว่า คือ บล็อก PR คุณภาพต่ำไว้เป็นค่าปริยาย แล้วให้สิทธิ์เข้าถึงเฉพาะคนที่สร้างความเชื่อใจกับผู้ดูแลหลักได้แล้ว