I2P डेवलपर बैठक - 20 दिसंबर 2005

15:20 <jrandom> 0) हाय 15:20 <jrandom> 1) नेट स्टेटस 15:20 <jrandom> 2) I2PSnark अपडेट्स 15:20 <jrandom> 3) Syndie ब्लॉग UI 15:20 <jrandom> 4) ??? 15:20 <jrandom> 0) हाय 15:20 * jrandom हाथ हिलाता है 15:20 <jrandom> साप्ताहिक स्टेटस नोट्स यहाँ पोस्ट किए गए हैं http://dev.i2p.net/pipermail/i2p/2005-December/001240.html 15:22 <jrandom> ठीक है, 1) नेट स्टेटस पर चलते हैं 15:22 <jrandom> स्टेटस नोट्स में जो है उसके अलावा मेरे पास जोड़ने के लिए ज़्यादा कुछ नहीं है। 15:22 <+Complication> अगर कभी-कभार होने वाली OOM (Out Of Memory त्रुटि) न होती, तो मैं इसे अच्छा कहने की हिम्मत करता 15:22 <jrandom> लोड टेस्टिंग काफ़ी उम्मीदजनक लग रही है, इससे लगता है कि परफ़ॉर्मेंस सुधारने के लिए हमारे पास काफ़ी गुंजाइश है 15:23 <+Complication> और मुझे लगता है कि OOM 15:23 <jrandom> हह, I2PSnark से संबंधित OOMs? या उससे पहले से? 15:23 <+Complication> वे अस्थिरता में योगदान देते हैं, जब i2p-bt, i2psnark, या i2p-rufus की इंस्टेंस... चीज़ें करती हैं। 15:24 <zzz> मेरा मानना है कि बढ़ा हुआ टोरेंट ट्रैफ़िक IRC की विश्वसनीयता को कुछ हद तक प्रभावित कर रहा है 15:24 <+Complication> (शायद मुझे SAM की अजीबता को OOM नहीं कहना चाहिए, क्योंकि मैंने इसे गहराई से नहीं देखा है, लेकिन यह निश्चित रूप से कारकों में से एक है) 15:24 <jrandom> हम्म, मैं पक्का नहीं कह सकता, क्योंकि IRC की स्थिति नवीनतम snark अपडेट्स से पहले जैसी ही थी 15:25 <+Complication> बैंडविड्थ स्थिर रही है, part. tunnels भी स्थिर... बस कभी-कभी क्रैश हो जाता है 15:26 <zzz> किसी भी हाल में, मुझे भरोसा है कि 0.6.1.8 में आने वाली tunnel build फिक्सेस लोगों के IRC अनुभव में सुधार करेंगी 15:26 <+Complication> ज्ञात कारणों से, जो उम्मीद है समय आने पर दूर हो जाएँगे :) 15:26 <jrandom> हाँ, मैं भी ऐसा ही सोचता हूँ zzz, तो संभवतः अगले एक-दो दिनों में हम एक रिलीज़ करेंगे 15:26 <+legion> खैर, IRC शायद बहुत संवेदनशील है, शायद jabber जैसा कुछ इस्तेमाल करना बेहतर होगा? 15:26 <zzz> खासकर धीमी मशीनों और/या कनेक्शनों पर लोगों के लिए 15:27 <jrandom> jabber चीज़ें नहीं बदलेगा 15:28 <+Complication> खासकर जब tunnel redundancy 2 पर है 15:28 <+bar> मैं कहूँगा कि IRC नेटवर्क के 'मौसम' का पता लगाने के लिए एक बेहतरीन crap-o-meter है 15:28 <+legion> हाँ, ज़रा सी हवा चलती है और IRC ठप्प हो जाता है 15:28 <+bar> बिल्कुल :) 15:28 <+Complication> मैंने देखा है कि shitlisting फ़िक्स के बाद, "Recent" अक्सर "Known" से ज़्यादा होता है 15:29 <+Complication> क्या ऐसा इसलिए है कि "Known" में shitlisted पीअर्स शामिल नहीं होते, जबकि "Recent" में होते हैं? 15:29 <jrandom> हाँ, IRC चीज़ों पर अच्छा नज़रिया देता है, क्योंकि इसने अलग-अलग यूज़र्स पर काफ़ी बदलाव दिखाया है (उदा. dreamtheaterfan को हमेशा दिक्कत रहती है, आदि) 15:30 <jrandom> हम्म, यह बात समझ में आती है Complication 15:30 <+Complication> (मुझे पक्का नहीं, बस अंदाज़ा लगा रहा हूँ) 15:30 <jrandom> (क्योंकि shitlisted peers को netDb से हटा दिया जाता है, लेकिन उनके प्रोफाइल हटाए नहीं जाते) 15:32 <+Complication> तो संकेतक ठीक लग रहे हैं (बस पूछना चाहता था, कहीं ऐसा न हो कि वे ठीक न हों) 15:33 <jrandom> ठीक है, 1) नेट स्टेटस पर और कुछ? 15:33 <jrandom> अगर नहीं, तो चलिए 2) I2PSnark अपडेट्स पर बढ़ते हैं 15:33 <tealc_> किस तरह के अपडेट्स उपलब्ध हैं? 15:34 <jrandom> संक्षिप्त सूची के लिए http://dev.i2p.net/pipermail/i2p/2005-December/001240.html देखें ;) 15:34 <jrandom> मूलतः, I2PSnark अब एकल I2P destination (गंतव्य) पर एक साथ कई टोरेंट्स संभाल सकता है, इसमें वेब इंटरफ़ेस है, और यह router console में बिल्ट-इन है 15:35 <tealc_> मैं नवीनतम CVS बिल्ड्स चला रहा हूँ और I2PSnark बहुत सारी मेमोरी हीप एरर वगैरह पैदा कर रहा है 15:35 <+Complication> ...और यह Azureus द्वारा बनाए गए टोरेंट्स को भी संभालता है जिनमें अजीब meta-tags होते हैं। 15:35 <+Complication> जिन पर पहले यह अटक जाता था। 15:35 <jrandom> आह, हाँ, वहाँ अभी भी कुछ चीज़ें हैं जिनकी मैं डिबगिंग कर रहा हूँ tealc_ 15:35 <jrandom> (जैसा साप्ताहिक स्टेटस नोट्स में बताया गया है ;) 15:35 <jrandom> अच्छा, ठीक है Complication 15:36 <jrandom> ओह, और Azureus वालों ने अपने ट्रैकर में एक बग ठीक किया है जो I2PSnark को उसे इस्तेमाल करने से रोकता था 15:36 <jrandom> (तो जो लोग B16 से पहले के Azureus ट्रैकर चला रहे हैं, उन्हें सुविधा होते ही अपग्रेड कर लेना चाहिए) 15:37 <+bar> मैं यह सुविधा चाहूँगा कि i2psnark ऑटोस्टार्ट को आसानी से डिसेबल किया जा सके (कम बैंडविड्थ वाले हालात, आदि के लिए) 15:38 <jrandom> इसे जोड़ना काफ़ी आसान होना चाहिए 15:38 <+bar> बढ़िया लगता है 15:39 <jrandom> ठीक है, 2) I2PSnark अपडेट्स पर और कुछ? 15:40 <jrandom> अगर नहीं, तो 3) Syndie ब्लॉग UI पर बढ़ते हैं 15:40 <zzz> नए i2psnark के लिए दो अंगूठे ऊपर - बढ़िया काम 15:41 <jrandom> ग्रासियस, mjw ने कठिन काम किया, snark को बढ़ाना इतना आसान बना दिया 15:41 <jrandom> ठीक है, जैसा स्टेटस नोट्स में बताया गया है, syndie में अब नया ब्लॉग UI है 15:42 <jrandom> मुझे लगता है यह whitelist (श्वेतसूची) और blacklist (कालीसूची) के बीच संतुलन देगा, ताकि लोग अलग-अलग स्पैम समस्याओं से निपट सकें 15:43 <jrandom> हम इसे अगली रिलीज़ में रोल-आउट करेंगे, ताकि आप सब एक-दो दिन में इसे आज़मा सकें 15:43 <+legion> क्या स्पैम वाकई जल्द ही बड़ी समस्या बनने वाला है? 15:44 <+Complication> legion: जैसा किसी ने कृपापूर्वक प्रदर्शित करने की इच्छा जताई, ऐसा हो सकता है 15:44 <jrandom> नाह, blacklist फ्लड करने वाले लेखकों की देखभाल करती है, और whitelist उन स्पैमर्स की जो बहुत से लेखक बनाते हैं 15:44 <dust> (गुमनामी कुछ लोगों में सबसे बुरा निकाल लाती है) 15:44 <jrandom> (तो स्पैमिंग कोई समस्या नहीं है) 15:45 <+Complication> (हालाँकि मेरा मानना है कि वह व्यक्ति perma-blacklisting से बचने के लिए keys फिर से जनरेट कर रहा था, जो *is* कुछ धीमापन लाता है।) 15:45 <+Complication> हालाँकि बहुत बड़ा धीमापन नहीं, और इसलिए मैं पूरे दिल से सहमत हूँ कि whitelists भी अच्छी हैं। :) 15:46 <+bar> शायद आगे चलकर, ज़रूरत पड़े तो, कोई hashcash समाधान संभव हो 15:46 <jrandom> अगर ज़रूरत पड़ी तो, पर मुझे नहीं लगता कि इसकी ज़रूरत पड़ेगी 15:46 <+bar> सहमत, अभी तो मुझे भी नहीं लगता 15:46 <+Complication> bar: जैसे कि "जब तक उन्होंने कुछ नंबर क्रंच करने की मेहनत न की हो, तब तक दिखाओ ही नहीं"? 15:47 <+bar> हाँ, कुछ उसी तरह 15:47 <+Complication> संभावित लगता है, भले ही शायद अनावश्यक हो। 15:47 <+bar> शायद हाँ। 15:47 <jrandom> अगर स्पैमर्स का एक समूह हर समय बहुत से नए लेखक जोड़कर फ़्लड कर रहा हो, तब भी लोग अपने ब्लॉग में उनके बुकमार्क्स और ब्लॉग रेफ़रेंस पोस्ट करके दूसरों को नए लेखकों के बारे में बता सकते हैं 15:47 <+Complication> या यूँ कहें, उम्मीद है कि अनावश्यक। 15:48 <+Complication> यह देखना अच्छा होगा कि Syndie ऐसी फ़ंक्शनैलिटी समायोजित कर सकता है या नहीं, यदि कभी ज़रूरत पड़े। 15:49 <jrandom> हाँ, कर सकता है, ब्लॉग पोस्ट के हेडर में या ब्लॉग के अपने metainfo में 15:49 <jrandom> उह, metadata (धत्त तेरे की bt!) 15:51 <jrandom> ठीक है, अगर 3) Syndie पर और कुछ नहीं, तो 4) ??? पर चलते हैं 15:51 <jrandom> किसी और के पास मीटिंग में उठाने के लिए कुछ है? 15:51 <+legion> हाँ, कुछ बातें 15:52 <+legion> पहले clunk 15:52 <jrandom> कूल, हाँ, clunk दिलचस्प लगता है 15:52 <+legion> जैसा मैंने आज पहले i2p-chat में बताया था, मैं इसे cygwin और/या mingw के साथ कंपाइल कराने पर काम कर रहा हूँ। 15:53 <+legion> अब तक सिर्फ़ क्लाइंट टूटा हुआ है, बाक़ी, सर्वर सहित, कंपाइल हो जाता है और काम करता दिखता है 15:53 <jrandom> बहुत बढ़िया 15:54 <tealc_> I2P जॉर्ज बुश के असीमित निगरानी कार्यक्रम के लिए वाकई एक बड़ा सिरदर्द साबित हो सकता है। मौत के कैंपों में मिलते हैं दोस्तों, ताश के पत्ते साथ लाना 15:54 <+legion> मैं न सिर्फ़ यह ढूँढने की कोशिश कर रहा हूँ कि क्लाइंट क्यों टूटा है, बल्कि इसे ठीक करने की भी। अभी के लिए मैं अटका हुआ हूँ। 15:56 <+legion> दूसरी बात जो मैं चर्चा करना चाहता था: क्या अगले अपडेट में मेरे jabber सर्वर के लिए एक डिफ़ॉल्ट tunnel शामिल की जा सकती है? ताकि जो भी jabber आज़माना चाहता है उसके लिए चीज़ें आसान हो जाएँ। 15:57 <tethra> 20:34:37 <jrandom> अगर स्पैमर्स का एक समूह हर समय बहुत से नए लेखक जोड़कर फ़्लड कर रहा हो, तब भी लोग अपने ब्लॉग में उनके बुकमार्क्स और ब्लॉग रेफ़रेंस पोस्ट करके दूसरों को नए लेखकों के बारे में बता सकते हैं <--- शायद polecat के trust को जोड़ने के तरीके जैसा कुछ इसमें भूमिका निभा सकता है? (अर्थात स्पैमर्स को ब्लॉक करना -और- लोकप्रिय लेखकों को बढ़ावा देना.) 15:57 <tethra> </$0.02> 15:58 <+polecat> वह मेरे trust network विचार का एक प्रारंभिक उदाहरण होगा, 100% trust transfer की ह्यूरिस्टिक के साथ, हाँ। 15:58 <jrandom> legion: हम्म, नए यूज़र्स के लिए disabled कॉन्फ़िग जोड़ना काफ़ी आसान है, लेकिन मेरी हिचक प्रोटोकॉल फ़िल्टरिंग (और कौन से क्लाइंट कौन सी जानकारी लीक करते हैं). विभिन्न क्लाइंट्स के साथ तुम्हारा अनुभव क्या है? 15:59 <jrandom> हाँ, syndie में trust metrics के एकीकरण की काफ़ी गुंजाइश है 16:01 <+legion> जहाँ तक मुझे पता है, jeti लीक नहीं करता, उसके filetransfer के अलावा, जो वैसे भी मेरे सर्वर सेटिंग्स में disabled है। संभव है कि अगला jeti वर्ज़न इसे सुधार दे। इसके अलावा मुझे अन्य क्लाइंट्स के बारे में नहीं पता। 16:02 <+legion> मुझे इतना ज़रूर पता है कि groupchat मज़बूत है, क्लाइंट्स की परवाह किए बिना; बस groupchat के बाहर का संपर्क है जिसे कुछ क्लाइंट्स लीक कर सकते हैं, हालांकि मैं पक्का नहीं। 16:03 <jrandom> हम्म, लीक होना वास्तव में कोई boolean नहीं है, यह बात इस पर है कि क्लाइंट्स /कौन सी जानकारी/ लीक करते हैं, न कि क्या वे कोई जानकारी लीक करते हैं 16:04 <+legion> बिलकुल, मेरा इशारा तो अहम जानकारी, जैसे IP addresses, की ओर था; हालांकि अच्छे क्लाइंट्स, अगर वे वह जानकारी लीक भी करें, तो उसे 127.0.0.1 या localhost के रूप में ही रिपोर्ट करें 16:06 <+legion> तो मैं सलाह दूँगा कि सिर्फ़ ऐसे जाने-माने क्लाइंट्स का इस्तेमाल करें जो लीक नहीं करते, जैसे jeti। 16:07 <zzz> क्या आप अपनी क्लाइंट चार्ट में एक verified-doesn't-leak कॉलम जोड़ सकते हैं? 16:07 <jrandom> यह उपयोगी होगा अगर आप डॉक्यूमेंट कर सकें कि jeti क्या लीक करता है और क्या नहीं (कुछ वैसा ही जैसा postman ने SMTP और POP proxy के लिए तैयार किया था) 16:08 <+legion> jeti के डेवलपर के अनुसार यह ऐसी कोई चीज़ लीक नहीं करता जो किसी की anonymity से समझौता करे। यह तो बिना किसी संदेह के पक्का है। मैंने इसके सोर्स को भी देखा है और ऐसी कोई चीज़ नहीं पाई जिससे मुझे और कुछ लगे। 16:09 <jrandom> डेवलपर ने जो कहा वह पक्का हो सकता है, पर डेवलपर anonymity के बारे में क्या समझते हैं, यह अलग सवाल है ;) 16:09 <+legion> हाँ zzz, मैं ऐसा एक और कॉलम जोड़ सकता हूँ 16:09 <jrandom> मुझे इस पर शक नहीं कि jeti सही तरह से काम करता है, पर हमें यह जानना होगा कि उसका मतलब क्या है 16:10 <zzz> लगता है कि non-leakage सिर्फ़ प्रोटोकॉल ट्रेसिंग से ही सत्यापित की जा सकती है 16:10 <zzz> सोर्स देखकर या डेवलपर से पूछकर नहीं 16:12 <jrandom> ठीक है, क्या किसी के पास मीटिंग के लिए और कुछ है? 16:12 <+bar> बस याद दिलाना था कि amd64 jbigi को न भूलें 16:13 <+bar> (पर शर्त लगाता हूँ, यह आपकी todo सूची में है) 16:13 <jrandom> हाँ :) 16:13 <jrandom> (win amd64, यानी, linux amd64 पहले से काम कर रहा है) 16:13 <jrandom> लेकिन, अगर कुछ और नहीं है... 16:14 * jrandom समेटता है 16:14 <+bar> हाँ, win amd64. 16:14 * jrandom *baf*s मीटिंग बंद करता है