LLM स्पैम का मुकाबला करने के लिए trust का web बनाना

• Tangled डिफ़ॉल्ट रूप से vouching फीचर को सपोर्ट करता है, जिससे उपयोगकर्ता जिन अन्य उपयोगकर्ताओं के साथ इंटरैक्ट कर चुके हैं, उन्हें endorse या denounce कर सकते हैं; इसे LLM-आधारित submissions की बढ़ती संख्या से निपटने के लिए trust signal के रूप में इस्तेमाल किया जाता है
• endorsed उपयोगकर्ताओं की प्रोफ़ाइल फ़ोटो के बगल में हरा shield icon और denounced उपयोगकर्ताओं के बगल में लाल shield icon दिखता है, जिससे यह तय करने का संकेत मिलता है कि उनके साथ इंटरैक्ट करना है या नहीं
• LLM-आधारित tools के जरिए प्रोजेक्ट में code submit करने की बाधा कम होने से ऊपर-ऊपर सही लेकिन सूक्ष्म रूप से गलत “uncanny valley” शैली की submissions बढ़ सकती हैं, और maintainers ऐसे tools का दुरुपयोग कर maintenance burden बढ़ाने वाले contributors को endorse या denounce कर सकते हैं
• endorse/denounce में टेक्स्ट-आधारित reason field शामिल होता है और attenuation लागू होती है, इसलिए उपयोगकर्ता केवल अपने और अपने circle द्वारा किए गए निर्णय ही देख सकते हैं
• Tangled में किसी को endorse या denounce करने पर उपयोगकर्ता के PDS पर एक public record बनता है, और appview इसे aggregate करके issues, comments, pull requests, और pull request comments में प्रोफ़ाइल के ऊपर vouching “hat” दिखाता है

---

Tangled के trust signals

• Tangled डिफ़ॉल्ट रूप से vouching फीचर को सपोर्ट करता है, जिससे उपयोगकर्ता जिन अन्य उपयोगकर्ताओं के साथ इंटरैक्ट कर चुके हैं, उन्हें endorse या denounce कर सकते हैं
• endorsed उपयोगकर्ताओं की प्रोफ़ाइल फ़ोटो के बगल में हरा shield icon दिखता है, और denounced उपयोगकर्ताओं के बगल में लाल shield icon दिखता है
• उपयोगकर्ता अपने circle द्वारा किए गए endorse/denounce निर्णय भी देख सकते हैं, और इन्हें इंटरैक्शन करना है या नहीं, यह तय करने के signal के रूप में इस्तेमाल कर सकते हैं
• LLM-आधारित tools के जरिए प्रोजेक्ट में code submit करने की बाधा कम होने से, ऊपर-ऊपर सही लेकिन सूक्ष्म रूप से गलत “uncanny valley” शैली की submissions बढ़ सकती हैं
• Tangled नेटवर्क के maintainers ऐसे tools का दुरुपयोग कर maintenance burden पैदा करने वाले contributors को endorse या denounce कर सकते हैं

यह कैसे काम करता है और डिज़ाइन की सीमाएँ

• सावधानीपूर्ण डिज़ाइन

  • endorse/denounce में टेक्स्ट-आधारित reason field शामिल होता है
  • attenuation लागू होती है, इसलिए उपयोगकर्ता केवल अपने और अपने circle द्वारा किए गए निर्णय ही देख सकते हैं
  • अभी denounced उपयोगकर्ताओं को प्रोजेक्ट से block नहीं किया जाता; UI के कुछ हिस्सों में केवल लाल warning label दिखता है

• नियोजित अतिरिक्त सुविधाएँ

  • समय के साथ maintainers और contributors प्रोजेक्ट छोड़ सकते हैं, इसलिए endorsements समय के साथ कमजोर होंगे और उन्हें समय-समय पर refresh करना होगा
  • PR merge करने के तुरंत बाद किसी उपयोगकर्ता को endorse करने पर उस PR को endorsement record के evidence के रूप में जोड़ने वाली evidence tracking सुविधा जोड़ी जा सकती है

• public record और display location

  • Tangled में किसी को endorse या denounce करने पर उपयोगकर्ता के PDS पर public record बनता है
  • इस record में यह शामिल होता है कि वह endorsement है या denunciation, साथ ही वैकल्पिक reason भी
  • Tangled appview पूरे नेटवर्क में vouching data को aggregate करता है और इंटरैक्शन पॉइंट्स पर प्रोफ़ाइल के ऊपर vouching “hat” दिखाता है
  • display location हैं: issues, issue comments, pull requests, और pull request comments

• circle-आधारित visibility

  • hat केवल तभी किसी उपयोगकर्ता के ऊपर दिखता है जब उपयोगकर्ता ने उसे सीधे endorse/denounce किया हो, या उपयोगकर्ता ने जिस व्यक्ति को endorse किया है उसने आगे उस व्यक्ति को endorse/denounce किया हो
  • hat पर क्लिक करके उपयोगकर्ता देख सकते हैं कि उनके circle में किसने उस उपयोगकर्ता को endorse या denounce किया है
  • अभी denunciation का परिणाम केवल hat display तक सीमित है; आगे इसका असर बदल सकता है, लेकिन फिलहाल यह निर्णय में मदद करने वाला signal है

[GN⁺]

Lobste.rs की राय

• इससे बेहतर और सरल तरीका है मज़बूत anti-LLM policy बनाना और उसे ठीक से लागू करना। GitHub जैसे उन प्लेटफ़ॉर्म्स से भी दूर जाना चाहिए जो LLM इस्तेमाल को बढ़ावा देते हैं या pro-AI रुझान रखते हैं
  यह 100% प्रभावी नहीं होगा, लेकिन LLM के इस्तेमाल को छिपाने की कोशिश भी अक्सर पकड़ में आ जाती है, और तब तुरंत ban किया जा सकता है। अगर कोई कंपनी LLM spam को धक्का देती है, तो पूरी कंपनी को block कर देना चाहिए, और अगर self-hosted forge है तो फ़ायरवॉल पर उस कंपनी का नेटवर्क रोक देना चाहिए
  proof-of-work जैसी आधी-अधूरी प्रणालियाँ नए contributors और राह चलते contributors को नुकसान पहुँचाती हैं, और trust vouching भी आख़िरकार proof-of-work ही है। कमज़ोर लोगों को परेशान करने के बजाय बुरे actors पर जल्दी प्रहार करना ज़्यादा असरदार है

  • Tangled का लक्ष्य LLM से बचना कम और spam avoidance ज़्यादा लगता है
    उद्धरण में भी कहा गया है कि यह उन contributors के लिए vouch या blame करता है जो इस टूल का misuse करके maintenance burden बढ़ाते हैं
  • इसके लिए पूरी तरह नया platform चाहिए होगा, और फिर भी असर सीमित ही लगेगा। कई projects LLM submissions स्वीकार करते हैं, और कई developers project के हिसाब से उसके इस्तेमाल पर अलग रुख रखने में सहज हैं
    सिर्फ इसलिए कि कोई LLM witch-hunt चला रहा है, लोगों को platform-level ban स्वीकार करवाना उल्टा असर कर सकता है। यहाँ या HN पर भी कभी-कभी पोस्ट को ग़लत तरीके से LLM-written समझ लिया जाता है; अगर वही चीज़ PRs में सँभालनी पड़े तो वह सच में थका देने वाली होगी
  • यहाँ घोषित लक्ष्य “LLM” नहीं बल्कि spam से बचना है
    यह सिस्टम उन contributors से बचने के लिए है जो टूल्स का misuse करके maintainers पर बोझ बढ़ाते हैं, और इसका इस्तेमाल पुराने तरीकों से maintenance burden बढ़ाने वालों पर भी किया जा सकता है। यह एक अधिक विकसित commit access मॉडल जैसा लगता है
  • यह इस बारे में कम है कि किस specific policy का उल्लंघन हुआ, और ज़्यादा इस बारे में है कि जब कोई policy तोड़ता है, तब क्या किया जाए
    अगर anti-LLM policy है तो इससे उसे लागू किया जा सकता है, और अगर anti-harassment policy है तो उसे भी इसी से लागू किया जा सकता है

• अगर यह सीधे PR submission से जुड़ा नहीं है, तो अच्छा से अच्छा देखें तो यह बेकार लगेगा, और बुरा से बुरा देखें तो एक हानिकारक moderation system बन सकता है। कोई न कोई उन users के ख़िलाफ़ mass blame शुरू करेगा जिन्होंने कभी LLM इस्तेमाल किया हो, और बाद में दूसरे कारणों से भी भीड़-आधारित हमले शुरू हो सकते हैं
  web of trust अपने-आप में शानदार है, लेकिन यह project सिर्फ technical पहलू देखता है, social पहलू नहीं। अगर आप moderation system बना रहे हैं और उसमें “abuse के बिना इसे scale कैसे किया जाए” जैसी बड़ी section ही नहीं है, जो system outcomes में भी दिखे, तो फिर हैरानी की बातें होंगी ही

  • Vouches सिर्फ वही दिखते हैं जो मैंने किए हैं या जिन accounts को मैंने vouch किया है उन्होंने किए हैं, इसलिए अनजान users की ओर किया गया mass blame दिखने के लिए डिज़ाइन ही नहीं किया गया है
  • मुझे भी डर है कि ऐसा हो सकता है, लेकिन असल में यक़ीन से कहने के लिए शायद पहले किसी बड़े cancel incident का इंतज़ार करना होगा
  • इसमें decay की अवधारणा होना सही दिशा में एक कदम है। अभी यह policy को सीधे नियंत्रित भी नहीं करता
    social problem को social incentives के साथ जोड़कर देखने वाला यह experiment काफ़ी दिलचस्प है, और इसका design भी काफ़ी चतुर लगता है

• अगर “जिस user को blame किया गया है, उसके साथ कुछ नहीं होता। बस एक hat लगती है” तो फिर इसका मतलब क्या है? आख़िरकार PR handling तो वैसे भी करनी ही पड़ेगी

  • यह देखने के लिए एक शुरुआती बिंदु है कि सिस्टम कैसे काम करता है, और आगे चलकर शायद trust-level-based blocking जैसी features जोड़ी जाएँगी
  • बाद में जोड़ा जा सकता है। शुरुआत में @yorickpeterse की कही बात को test करना है, और बाद में users को यह चुनने देना है कि blamed users पर वे किस तरह का “reaction” देना चाहते हैं
    जैसे block करना, priority कम करना जैसी चीज़ें संभव हैं

• क्या ऐसा कुछ है जो किसी को कई domains बनाकर, हर एक पर दस लाख users खड़े करके, और उन्हें आपस में vouch करवाने से रोके? तब दूसरे लोग मुझसे ऐसे bundled reputation खरीद सकेंगे जिन्हें अलग कर पाना मुश्किल होगा
  इसके बजाय lobste.rs का invite-tree model बेहतर लगता है। अगर कोई abuse शुरू करे तो पूरे नीचे के subtree को काटना आसान है, और growth भी धीमी होती है, जो शायद फ़ायदा ही है

  • human.json मॉडल पसंद आया: https://codeberg.org/robida/human.json खासकर extension में इसका visualization अच्छा है। यह trusted sites तक shortest path ढूँढता है, distance को रंग से दिखाता है, और path भी दिखाता है
    human.json में शायद कोई भी ऐसे network के nodes को vouch नहीं करेगा, या incoming links इतने कम होंगे कि distance बहुत ज़्यादा निकलेगी। इसका मतलब यह नहीं कि ऐसी sites को network में डाला ही नहीं जा सकता, लेकिन vouching और distrust उन्हें जल्दी बाहर धकेल सकते हैं। व्यवहार में यह कैसे चलेगा, यह अभी देखना बाकी है
  • Labelling user-specific है। अगर मैं सिर्फ उन्हीं लोगों को vouch करूँ जो मेरे लाखों random accounts को vouch नहीं करेंगे, तो Sybil-attack जैसी activity का मेरी vouching पर कोई असर नहीं पड़ेगा
    अगर कोई petnames-जैसी UI layer हो जहाँ inline या mouseover में “X, Y, Z ने vouch किया है” दिखे, तो अच्छा होगा
  • अगर vouching की अलग-अलग डिग्रियों को score करने वाला मॉडल हो, तो वह दिलचस्प होगा। जैसे lobste.rs-style invite tree का उपयोग करके, जहाँ 100 लोगों ने vouch किया हो लेकिन सबका एक ही ancestor हो, बनाम 5 लोगों ने बहुत अलग paths से vouch किया हो, तो बाद वाले 5 को ज़्यादा weight दिया जाए
    जानना दिलचस्प होगा कि इससे “reputation farming” कितनी हद तक रोकी जा सकती है
  • ज़्यादा से ज़्यादा bots आपस में अपना vouching circle बना पाएँगे। बाकी network उस circle के फ़ैसले तब तक नहीं देख पाएगा जब तक वे bot accounts को vouch करना शुरू न कर दें
    आख़िरकार सारा data public है, इसलिए कोई tangled2.org बनाकर global graph भी तैयार कर सकता है, लेकिन UI को जानबूझकर ऐसे बनाया गया है कि अपनी circle से बाहर जाते ही vouching कमज़ोर पड़ जाए

• आइडिया अच्छा है, लेकिन शायद स्वाभाविक रूप से बातचीत करना ही बेहतर हो। छोटी-मोटी communication भी बहुत सुथरी और एक जैसी लग रही है
  टाइप किए हुए टेक्स्ट में कुछ typos छोड़ देने से असली इंसान जैसा एक fingerprint बनता है

• यह आइडिया अच्छा लगा। इससे lobste.rs का अपना tree of trust याद आता है

  • या human.json भी है। अपनी site पर मैं उसका नाम meat.json रखने की सोच रहा हूँ

• ऐसा लगता है जैसे हम open source की शुरुआत के लगभग उसी समय हुए trust metric research को तेज़ी से फिर से दोहरा रहे हों। @raph इसे कैसे देखेंगे, यह जानने की उत्सुकता है

  • पुराना जाना-पहचाना नाम देखकर अच्छा लगा। Slashdot का triple meta-moderation system भी मान्यता पाने लायक है
    वह perfect नहीं था, लेकिन कुछ भी न होने से तो निश्चित ही बहुत बेहतर था

• लगता है ऐसी चीज़ें पहले से ही लगभग छह हैं, तो किसी मौजूदा चीज़ में शामिल होने के बजाय एक और क्यों बनाई जाए?

  • https://xkcd.com/927/