संक्षिप्त सारांश

उपस्थित: cervantes, Complication, jrandom, TrevorReznik

बैठक लॉग

16:02 <jrandom> 0) नमस्ते 16:02 <jrandom> 1) नेट स्टेटस 16:02 <jrandom> 2) zzz के NTCP/SSU प्रस्ताव 16:03 <jrandom> 3) Syndie डेव स्टेटस 16:03 <jrandom> 4) DNS/registrar स्टेटस 16:03 <jrandom> 5) ??? 16:03 <jrandom> 0) नमस्ते 16:03 * jrandom हाथ हिलाता है 16:03 <jrandom> साप्ताहिक स्टेटस नोट्स यहां पोस्ट किए गए हैं http://dev.i2p.net/pipermail/i2p/2007-March/001342.html 16:04 <jrandom> 1) नेट स्टेटस पर चलते हैं 16:04 <jrandom> चीज़ें काफ़ी अच्छी लग रही हैं, और जैसा बताया था नवीनतम बदलावों पर और रिसर्च करनी है 16:05 <+Complication> मैं IRC कनेक्टिविटी के बारे में थोड़ी शिकायत करना चाहता था (बाकी सब ठीक-ठाक लगता है), लेकिन पिछले एक दिन में मुझे लगभग 6 डिसकनेक्ट ही हुए, जो इतना बुरा नहीं है 16:05 <cervantes> /mute Complication 16:05 <jrandom> हँह 16:05 <+Complication> :D 16:06 <+Complication> tunnel build की सफलता बहुत अच्छी है, हालांकि 16:06 * Complication एहतियातन फिर से जांच करता है 16:06 <jrandom> हाँ, मैंने कुछ डिसकॉन churn देखा है (हालाँकि सच कहूँ तो, मैं अपना बैकलॉग grep -v -\!- के साथ पढ़ता हूँ, तो डिसकॉन दिखते ही नहीं ;) ) 16:06 <cervantes> हाल ही में irc फ़्रंट पर कई ISP गड़बड़ियाँ हुई हैं - postman वैकल्पिक होस्टिंग व्यवस्थाओं पर विचार कर रहा है 16:06 <jrandom> स्टैट्स पर tunnel build रेट्स में सुधार आया है, हालांकि वे सामान्यतः stats.i2p पर चक्रों के अनुरूप ही लगते हैं 16:06 <cervantes> उम्मीद है कि हमें बेहतर नेटवर्क रेडंडेंसी मिल सकेगी 16:06 <jrandom> अच्छा ठीक है, cervantes 16:07 * jrandom dev.i2p.net में मदद की पेशकश करता, पर मुझे याद नहीं कि आख़िरी बार उस पर लोड 4 से नीचे कब था 16:08 <jrandom> ठीक है, net status के संबंध में किसी के पास और कुछ उठाने को है? 16:10 <jrandom> अगर नहीं, तो 2) zzz के NTCP/SSU प्रस्तावों पर चलते हैं 16:10 <jrandom> zzz इस समय आसपास नहीं दिख रहे, और मैं अपनी Syndie पोस्ट्स जो थ्रेड का जवाब थीं, घर पर छोड़ आया (d'oh) 16:11 <jrandom> खैर, अपने विचार zzz के ब्लॉग पर पोस्ट करें (या अधिक जानकारी के लिए वहाँ पढ़ें) 16:11 <jrandom> क्या अभी यहाँ उस बारे में कुछ चर्चा करनी है? 16:12 <+Complication> खैर, मैंने वहाँ एक जवाब लिखा है, जिसमें UDP पर बहुत अधिक निर्भरता को लेकर चिंता जताई है (क्योंकि मेरे लिए UDP में पुनःप्रेषण दरें काफ़ी ऊँची रही हैं) 16:12 <jrandom> हाँ 16:12 <+Complication> हालाँकि, मैंने एक तरीका सोचा... 16:12 <+Complication> वर्तमान में बिड्स पूरी तरह निर्धारक हैं (यादृच्छिक घटक वाली प्रायिकता-आधारित के विपरीत), सही? 16:13 <jrandom> हाँ, पूरी तरह निर्धारक 16:13 <+Complication> मैं सोच रहा था कि उनमें प्रायिकता घटक जोड़ने से (अत्यधिक स्थितियों से बचने के अर्थ में) कोई लाभ होगा क्या 16:14 <+Complication> जैसे कि "NTCP मिलने की 60% संभावना, SSU मिलने की 40% संभावना" 16:14 <+Complication> (मानकर कि पहले से कोई डेटा नहीं है - यदि पहले के विफलता/सफलता डेटा मौजूद हो, तो संभवतः उस लिंक के बेहतर प्रदर्शन वाले ट्रांसपोर्ट के पक्ष में प्रायिकता को झुकाना पड़ेगा) 16:15 <jrandom> खैर, यह इस पर निर्भर करता है कि लक्ष्य क्या है - zzz के प्रस्ताव की मेरी समझ में, लक्ष्य है कि संभव हो तो ssu का उपयोग किया जाए 16:15 <+Complication> (बेशक यह मानकर कि किसी दिए गए लिंक के लिए दोनों ट्रांसपोर्ट्स उपयोगी हैं - कभी-कभी वे निश्चित रूप से नहीं होते) 16:15 <jrandom> इसे रैंडम बनाना उससे मदद नहीं करेगा, हालांकि इससे दोनों ट्रांसपोर्ट्स पर वास्तविक वातावरण में डेटा जुटाने की और गुंजाइश मिलेगी 16:16 <+Complication> बस यह सोच कि उनके बीच संतुलन बनाने का एक संभावित तरीका क्या हो सकता है (क्योंकि अगर एक हमेशा ज़्यादा बोली लगाए, तो routers शायद बहुत "प्रयोग" नहीं करेंगे) 16:19 <jrandom> यह एक तरीका है जिससे हम अधिक डेटा जुटा सकते हैं, ध्यान रखने योग्य 16:19 <jrandom> ठीक है, जैसा बताया, अधिक चीज़ों के लिए उस थ्रेड पर पोस्ट करें :) 16:20 <jrandom> 3) Syndie डेव स्टेटस पर चलते हैं 16:20 <jrandom> मेल में जो है उसके अलावा मेरे पास जोड़ने को ज़्यादा नहीं है 16:20 <jrandom> किसी के पास कोई प्रश्न/टिप्पणी/चिंता? 16:21 <+Complication> अभी नहीं। :) 16:22 <jrandom> हेहे 16:22 * Complication I2P या Syndie फ़्रंट पर और मदद करने की आशा रखता है, पर मुझे पहले वह webcache वाली चीज़ रिलीज़ करनी है 16:22 <jrandom> w3rd, दोनों के लिए उत्सुक हूँ :) 16:24 <jrandom> ठीक है, 4 को छोड़कर 5) ??? पर चलते हैं 16:25 <jrandom> बैठक में किसी के पास और कुछ उठाने को है? 16:26 <TrevorReznik> क्या I2P के लिए hashcash जनरेटर में किसी की रुचि है? 16:26 <TrevorReznik> जैसे ब्राउज़र इंटरफ़ेस के जरिए। 16:26 <TrevorReznik> मैंने सोचा कि यह I2P के भीतर संभावित DoS परिदृश्यों को कम करने का एक तरीका हो सकता है। 16:27 <jrandom> हम्म, javascript में या c/java में? 16:27 <jrandom> मुझे लगता है कि कुछ hashcash जनरेटर पहले से उपलब्ध हैं 16:27 <TrevorReznik> java में। 16:28 <+Complication> खैर, hashcash स्कीम्स पर कुछ शोध की ज़रूरत किसी बिंदु पर पड़ेगी 16:28 <TrevorReznik> www.hashcash.org पर कुछ हैं, मेरा खयाल है। 16:28 <TrevorReznik> वे इसे ईमेल क्लाइंट्स के लिए एंटी-स्पैम चीज़ के रूप में स्थापित करने की एक पहल हैं। 16:28 <+Complication> शायद सख्त मायने में शोध नहीं, बल्कि इम्प्लीमेंटेशन और best practice के संदर्भ में 16:28 <+Complication> =sense 16:28 <TrevorReznik> उनके पास कई भाषाओं में इम्प्लीमेंटेशन्स का संग्रह है। 16:28 <TrevorReznik> वहाँ 2 java क्लासेज़ और कम से कम एक ऐपलेट हैं, हालाँकि मुझे अभी सटीक लाइसेंस पैरामीटर्स नहीं पता। 16:30 <+Complication> जगहें जहाँ इसका उपयोग हो सकता है: 1) Syndie में nym पंजीकरण 2) I2P में नाम पंजीकरण 16:30 <+Complication> 3) ईमेल, स्पष्ट रूप से 16:30 * TrevorReznik सहमत है। 16:30 <+Complication> 4) कम आशावादी परिस्थितियों में, Syndie में साधारण संदेश 16:31 <+Complication> I2P नेटवर्क स्तर पर ही... 16:31 <+Complication> हम्म 16:31 <jrandom> उन्हें tunnel निर्माण संदेशों में एम्बेड करना संभव है, पर CPU के मोर्चे पर हम वैसे ही पहले से जाम हैं ;) 16:39 <jrandom> ठीक है, बैठक के लिए किसी के पास और कुछ है? 16:41 <jrandom> अगर नहीं 16:41 * jrandom समेटता है 16:41 * jrandom बैठक को *baf* कर बंद करता है