Vouch - ओपन सोर्स contributor trust management system

• ओपन सोर्स पारंपरिक रूप से trust and verify मॉडल पर काम करता आया है
• AI tools के प्रसार से contribution में प्रवेश की बाधा लगभग खत्म हो गई है, इसलिए पहले का implicit trust model अब काम नहीं करता
• यह एक ओपन सोर्स trust management system है, जिसे इस तरह डिज़ाइन किया गया है कि योगदान से पहले trust को स्पष्ट रूप से vouch करना ज़रूरी हो
• भरोसेमंद contributor दूसरे users के लिए vouch कर सकते हैं, और दुर्भावनापूर्ण actors को denounce के ज़रिए स्पष्ट रूप से ब्लॉक किया जा सकता है
  • denounce सार्वजनिक रिकॉर्ड के रूप में बना रहता है, इसलिए दूसरे projects भी उसे संदर्भ के रूप में देख सकते हैं
  • कौन, किन मानदंडों के आधार पर vouch/denounce करेगा, यह हर project खुद तय करता है
  • system किसी खास मूल्य-व्यवस्था को लागू नहीं करता, और policy decisions community के हिस्से हैं
• सभी trust data repository के भीतर एकल plain text file (VOUCHED) में code के साथ version-controlled रहते हैं, जिससे transparency और portability सुनिश्चित होती है
• लंबे समय में project-से-project Web of Trust बनाकर trust information साझा करने की संरचना है
  • किसी upper project के निर्णय को ज्यों का त्यों स्वीकार करना है या नहीं, यह lower project की पसंद है
  • जो projects बिना सोच-समझे vouch/denounce करते हैं, उन्हें trust network से स्वाभाविक रूप से बाहर किया जा सकता है
• GitHub Actions के साथ आसानी से integrate किया जा सकता है, और issue या PR comments में lgtm, denounce जैसे keywords से इसे manage किया जा सकता है
• Ghostty ने अपने contribution model को vouch-based system में बदल दिया है
• Pi project से प्रेरित होकर इसे बनाया गया है, और अभी यह experimental stage में है

उपलब्ध commands

• local files
  • vouch.nu check <user>: user की vouch/denounce स्थिति जांचें
  • vouch.nu add <user>: user को vouch करें
  • vouch.nu denounce <user>: user को denounce करें
• GitHub integration
  • vouch.nu gh-check-pr <pr>: PR लेखक की स्थिति जांचें और automatic processing करें
  • vouch.nu gh-manage-by-issue <issue> <comment>: issue comment के आधार पर vouch/denounce

[kuthia]

मुझे लगता है कि इस सिस्टम को स्वीकार किए जाने के लिए पहले खुद इसकी प्राधिकृति स्थापित होनी चाहिए।

[xguru]

लगता है कि इस पर ध्यान बढ़ने के साथ कुछ गलतफ़हमियाँ भी हुईं, इसलिए इन्होंने अलग से FAQ व्यवस्थित किया है
https://x.com/mitchellh/status/2020628046009831542

• शुरुआती और नए प्रतिभागियों के लिए इसमें शामिल होना मुश्किल है
  • Vouch पाना मुश्किल होने की बिल्कुल कोई वजह नहीं है
  • Vouch का मुख्य उद्देश्य बिना किसी प्रयास के यूँ ही शामिल होने से रोकना है
  • मेरे प्रोजेक्ट्स में (इस प्रोजेक्ट सहित), अगर आप issue में अपना परिचय दें और संक्षेप में बताएं कि आप कैसे contribute करना चाहते हैं, तो आपको Vouch मिल सकता है
  • सरल शब्दों में, सामान्य सामाजिक व्यवहार की तरह अपना परिचय दे दें, तो Vouch मिल सकता है
  • लेकिन अगर समूह के भीतर अधिकारों का दुरुपयोग किया गया, तो कार्रवाई होगी
• यह social engineering के प्रति कमजोर है
  • Vouch पाने वाला उपयोगकर्ता सिर्फ प्रोजेक्ट में भाग लेने की अनुमति पाता है
  • उसे pull request merge, code push, release आदि की अनुमति नहीं मिलती
  • ये सभी काम मौजूदा review और system controls के ज़रिये सीमित रहते हैं
  • साथ ही, केवल admin/collaborator ही उपयोगकर्ताओं को recommend कर सकते हैं
  • इसलिए अगर किसी समस्याग्रस्त उपयोगकर्ता को recommendation मिल भी जाए, तो वह किसी दूसरे उपयोगकर्ता को recommend नहीं कर सकता
• Denouncing के लिए कोई appeal process नहीं है.
  • appeal process subproject के अनुसार अलग-अलग होता है
  • मेरे प्रोजेक्ट्स के मामले में, Discord, email आदि किसी भी माध्यम से हमसे संपर्क करें, इंसान की तरह बात करें, और गलती स्वीकार करें, तो हम फिर से मौका देते हैं। यह कठिन नहीं है
• इस प्रोजेक्ट का मुख्य बिंदु यह है कि AI API calls के ज़रिये लोगों को जानकारी देकर मौजूदा प्राकृतिक बाधाओं को न्यूनतम करे
• इंसान-केंद्रित community projects में सिर्फ सीमाओं पर ही मानवीय interaction की ज़रूरत होती है

[GN⁺]

Hacker News की राय

• मुझे लगता है कि यह मान लेना खतरनाक है कि किसी एक प्रोजेक्ट में विश्वसनीय यूज़र दूसरे प्रोजेक्ट में भी अपने-आप विश्वसनीय होगा।
  इस तरह की संरचना का supply chain attack में दुरुपयोग हो सकता है। हमलावर कई प्रोजेक्ट्स में ‘अच्छा contributor’ बनकर भरोसा जमा सकता है, और फिर लक्ष्य प्रोजेक्ट तक पहुंच सकता है।
  अगर यह cross-trust अपने-आप लागू हो जाए, तो एक बार trusted हुआ अकाउंट भी हमले का निशाना बन सकता है। मेरी राय में ‘trust list’ की बजाय ‘distrust list’ से शुरू करना ज्यादा सुरक्षित होगा।

  • विवरण देखकर लगता है कि इस सिस्टम का उद्देश्य security के अर्थ में trust नहीं, बल्कि AI-जनित low-quality contributions को छांटने वाला spam filter है।
  • यह चिंता कुछ बढ़ा-चढ़ाकर कही गई लगती है। Vouch सिर्फ participation access को सीमित करने वाला gate है, merge permission देने वाला सिस्टम नहीं। उसके बाद मौजूदा review प्रक्रिया वैसी ही रहती है। कुल मिलाकर इसे noise-minimization layer की तरह देखना चाहिए।
  • हमलावर का लंबे समय तक अच्छा बनकर reputation बनाना तो पहले से ही वास्तविक दुनिया में होता है। आखिरकार लोग तब पहचानते हैं जब वह बदलता है। यह xkcd 810 जैसी स्थिति है।
  • अगर कोई भरोसा खो देता है, तो जिन सभी प्रोजेक्ट्स ने उस पर भरोसा किया था वहां से भी उसका भरोसा हट जाता है। यह spam filter जैसा विचार है, PGP key signing स्तर का trust नहीं। इसका मकसद nation-state attackers को रोकना नहीं, बल्कि AI spam PRs को रोकना है।
  • यह परफेक्ट सिस्टम नहीं है, लेकिन मुझे यह “इतना सुधार कि झंझट उठाना सही लगे” जैसा लगता है। अगर कोई सच में contributor है, तो थोड़ा extra effort करना ठीक है। मैं भी इतना स्वीकार कर सकता हूं।

• मुझे लगता है PR submit करने पर $1 की लागत होनी चाहिए।
  अगर PR वैध हो, तो maintainer उसे refund कर दे।
  अभी communication बहुत आसान हो गया है, इसलिए low-quality communication की बाढ़ आ गई है। यह सिर्फ बेकार नहीं, बल्कि समय खा जाने वाला नुकसान है।

  • यह सोच अंत में crypto दुनिया के staking कॉन्सेप्ट तक पहुंचती है। token lock करो, और PR merge हो जाए तो वापस पाओ। तकनीकी रूप से यह elegant लग सकता है, लेकिन जैसे ही पैसा आता है, product design बिगड़ जाता है। ऐसा बिल्कुल नहीं करना चाहिए।
  • “मेरा comment पढ़ना है तो $1 दो” मजाक है, लेकिन यह इस विचार की असली प्रकृति अच्छी तरह दिखाता है।
  • communication पर लागत लगाने के नकारात्मक प्रभाव भी होंगे। उचित लागत का संतुलन महत्वपूर्ण है। अपने करीबी लोगों की ‘low-quality बातचीत’ तो ठीक है, लेकिन काश politicians की Twitter बातचीत कुछ कम हो जाए।
  • आखिरकार यह cost externalization की समस्या है। manufacturing, communication, code generation—हर जगह यह दिखती है। अब तो व्यक्तिगत reputation तक लगभग बिना लागत के बन रही है।
  • अगर ऐसी व्यवस्था हो, तो शायद मैं PR ही न भेजूं। पहले ही बहुत से PR बिना जवाब के पड़े रहते हैं; अगर पैसे भी देने पड़ें, तो मैं बस fork में fix कर लूंगा। अगर refund का प्रोत्साहन न हो तो यह और भी अनुचित है। escrow service जोड़ो तो चीजें और जटिल हो जाती हैं। मुझे तो बस bug fix करना है, इतनी प्रक्रिया नहीं चाहिए।

• अगर किसी नए contributor के पास network नहीं है, तो वह entry barrier कैसे पार करेगा, यह सवाल है।
  चाहे AI ने बहुत noise बनाया हो, यह उसका समाधान नहीं लगता।

  • अपने OSS प्रोजेक्ट में मैं PR से पहले issue या discussion के रूप में proposal देना ज्यादा पसंद करता हूं। PR कई बार project direction से मेल नहीं खाते और तब उन्हें reject करना असहज हो जाता है।
  • contributor से video call पर patch समझाने का तरीका भी है। मैंने वास्तव में इस तरह fraud applicants को छांटा है। आजकल FOSS लगभग fraud detection game बन गया है।
  • यह शायद चरणबद्ध access control जैसा मॉडल है। जैसे पहले staging environment में validate करना, फिर production access देना। ops दुनिया में यह पहले से आम तरीका है।
  • यह Vouch configuration पर निर्भर करता है। कुछ लोग सब कुछ बंद कर सकते हैं, कुछ issue/discussion खुले रखकर सिर्फ PR सीमित कर सकते हैं। Linux की तरह हर प्रोजेक्ट की अपनी प्रथा के हिसाब से इसे अपनाया जा सकता है।

• मैं इस बात से सहमत नहीं हूं कि “open source trust and verify सिस्टम पर चलता है।”
  आदर्श रूप में कोड का मूल्यांकन उसके अपने आधार पर होना चाहिए।
  मैं PR देखकर कुछ ही सेकंड में तय कर लेता हूं कि merge करना है या नहीं। मुश्किल काम है reject करने का कारण शिष्टता से लिखना।
  (संदर्भ: openpilot रिपॉज़िटरी)

  • मैंने हाल में openpilot का कोड देखा, msgq/cereal, Params, visionipc जैसी संरचनाएं दिलचस्प लगीं।
  • जब समय होता है तो review करते हैं, और जब नहीं होता तो trust पर चलते हैं।

• मुझे जिज्ञासा है कि Vouch प्रोजेक्ट Bluesky जैसी बंद bubble बनने से खुद को कैसे रोकेगा।
  चुनाव के बाद Bluesky लगातार सिकुड़ता दिख रहा है। इस तरह का social filtering नए contributions को रोक सकता है।

  • चुनाव के बाद कमी आई है, लेकिन उससे पहले की तुलना में users अभी भी ज्यादा हैं। आंकड़े देखें तो यह spike के बाद stabilization जैसा पैटर्न है।
    और वैसे भी Vouch का मकसद शुरू से ही entry barrier बढ़ाना है, इसलिए शायद उन्हें इस चिंता की परवाह न हो।
  • हर प्रोजेक्ट अपना स्वतंत्र vouch सिस्टम रख सकता है। community issue या PR के जरिए विरोध भी दर्ज कर सकती है।
  • “अगर Bluesky जैसी bubble बन गई तो?” → “शायद वही इरादा हो” ऐसा नजरिया भी है।
  • यह दिलचस्प है कि Bluesky पर सबसे ज्यादा block किया गया अकाउंट सरकारी official account है। यह बंद समुदायों की एक झलक दिखाता है।

• इस सिस्टम पर तंज किया गया कि drama-free open source community में इसका कभी दुरुपयोग नहीं होगा—ऐसा तो हो ही नहीं सकता।
  यह भी सवाल उठा कि कहीं blacklisted developers की कोई साझा सूची तो नहीं है।

• मुझे लगता है trust-based सिस्टम तभी काम करेगा जब उसमें जोखिम भी जुड़ा हो।
  अगर मैंने किसी को endorse किया और उसने समस्या पैदा की, तो मेरी reputation भी गिरनी चाहिए।
  उल्टा, अगर मैंने बिना आधार किसी की बुराई की और वह ठीक निकला, तो मेरी reputation कम होनी चाहिए।
  वरना endorsement का गैरजिम्मेदार दुरुपयोग होगा।

  • इसलिए सावधानी जरूरी है। लेकिन अगर किसी को endorse करके अच्छा नतीजा मिले, तो मेरी reputation भी बढ़नी चाहिए। इंसानी रिश्ते भी कुछ ऐसे ही काम करते हैं।
    ऐसी संरचना को blockchain-आधारित trust graph के रूप में भी लागू किया जा सकता है।
  • जैसे कंपनी में referral दिया जाता है, वैसे ही साथ काम करने पर मुझे भी फायदा होता है, इसलिए मैं endorse करता हूं।
  • अगर मेरे endorse किए व्यक्ति के अच्छे contribution पर मेरा score भी बढ़े, तो यह एक अच्छा incentive हो सकता है।
  • लेकिन ऐसी संरचना में Epstein जैसे मामलों की तरह, सिर्फ बहुत connections होने से गलत लोगों को भी छूट मिल सकती है। दूसरी ओर अंतर्मुखी लेकिन सक्षम लोग बाहर छूट सकते हैं।
  • इस तरह के trust network को graph traversal problem की तरह भी देखा जा सकता है। जिस व्यक्ति पर मुझे भरोसा है, वह जिस पर भरोसा करता है, उससे indirect trust निकाला जा सकता है।

• यह सिस्टम मुझे dating app जैसा लगता है।
  यहां filter करने के लिए अत्यधिक उत्साही लेकिन अनुपयुक्त लोग बहुत हैं, और अंततः paid participation, location-based filtering, identity verification, social scoring जैसी चीजें आ सकती हैं।
  आजकल GitHub reputation पाने के लिए लोग बेकार contribution requests की बौछार कर रहे हैं, जो थका देने वाला है।

• मैं Git की उन चीजों को छोड़कर एक minimal forge structure की कल्पना करता हूं, जो Git अपने-आप नहीं कर सकता।
  इसका केंद्र है Identity, signed attestation, और Policy।
  Vouch इनमें से इंसानों के बारे में signature को संभालता है — “यह व्यक्ति भरोसेमंद है” वाला signature, संरचनात्मक रूप से “यह commit test pass कर गया” वाले signature जैसा ही है।
  यानी यह participation को नियंत्रित करने वाली policy layer है।
  ऐसी functionality GitHub जैसे बंद platform पर नहीं, बल्कि repo के अंदर metadata के रूप में होनी चाहिए।
  पांच साल बाद यह विचार कहां तक पहुंचेगा, यह देखने लायक होगा।

  • अगर इस metadata को .github/ फोल्डर की तरह standard रूप में रखा जाए, तो platform-independent trust model संभव हो सकता है।
    LLM-जनित code बढ़ने के दौर में, ऐसी reputation infrastructure इंटरनेट का जरूरी हिस्सा बन सकती है।

• शुरुआत में यह ठीक लगा, लेकिन आखिरकार यह “सिर्फ trusted लोग ही contribute कर सकते हैं” जैसी संरचना पर पहुंचता दिखता है।

  • फिर भी इसमें महत्व है, क्योंकि यहां innovation से ज्यादा अच्छी तरह डिज़ाइन की गई execution मायने रखती है।
  • यह पुराने Usenet के killfile या spam RBL lists जैसा है।
    (killfile wiki, DNS blocklist)
  • बड़े प्रोजेक्ट्स के लिए ऐसी संरचना ज्यादा उपयुक्त लगती है। यह low-quality PRs को डिफ़ॉल्ट रूप से रोकती है, और केवल उन लोगों को access देती है जिन्होंने core maintainers के साथ trust बना लिया है।