I2P डेवलपर मीटिंग - 18 अक्टूबर, 2005

16:10 <jrandom> 0) नमस्ते 16:10 <jrandom> 1) 0.6.1.3 16:10 <jrandom> 2) Freenet, I2P, और darknets (ओह माय) 16:10 <jrandom> 3) Tunnel bootstrap हमले 16:10 <jrandom> 4) I2Phex 16:10 <jrandom> 5) Syndie/Sucker 16:10 <jrandom> 6) ??? 16:10 <jrandom> 0) नमस्ते 16:10 * jrandom हाथ हिलाता है 16:10 <jrandom> साप्ताहिक स्थिति नोट्स यहाँ उपलब्ध हैं http://dev.i2p.net/pipermail/i2p/2005-October/001017.html 16:10 <dust> ये, अब काम कर रहा है। धन्यवाद Gregor 16:10 <cervantes> हैलो 16:11 <+fox> <blx> हेलो 16:11 <jrandom> ठीक है, 1) 0.6.1.3 पर चलते हैं 16:11 <jrandom> आप सबने काफ़ी तेजी से अपडेट किया है, धन्यवाद! 16:12 <jrandom> चीज़ें ठीक-ठाक लग रही हैं, लेकिन स्थिति नोट्स में जो है उसके अलावा मेरे पास ज़्यादा जोड़ने को नहीं है 16:12 <jrandom> क्या किसी के पास 0.6.1.3 के बारे में कोई सवाल/टिप्पणियाँ/चिंताएँ हैं? 16:13 <jrandom> ठीक है, अगर नहीं, तो 2) Freenet, I2P, और darknets (ओह माय) पर चलते हैं 16:13 <cervantes> 609 ज्ञात पीयर्स! 16:14 <cervantes> (w00t) 16:14 <jrandom> हाँ, नेटवर्क बढ़ रहा है 16:14 <+fox> <blx> ओह माय! 16:14 * cervantes इस बात पर सट्टा लगा रहा है कि बड़ा 1000 कब तक पहुँचेगा 16:14 <jrandom> हेह 16:14 <tethra> हेहेह 16:15 <tethra> क्या हम digital cash से दांव लगा रहे हैं? ;) 16:15 <cervantes> लेकिन यह दिखाता है कि हाल ही में I2P कोर कितना मजबूत हुआ है कि उपयोगकर्ता अपनाने की गति तेज़ हो गई है 16:16 <cervantes> नाह... jrandom ने इस साल की अपनी सारी बीयर की रकम अनजाने में ही दान कर दी है 16:16 <jrandom> hehe 16:16 <jrandom> ठीक है, 2) पर, मुझे नहीं लगता कि मेरे पास और जोड़ने को कुछ है (लगता है हम इस घोड़े को काफी पीट चुके हैं — यानी विषय पर काफी चर्चा हो चुकी है)। क्या किसी के पास इस पर कोई सवाल/टिप्पणी/चिंता है? 16:18 <cervantes> जैसा आपने कहा, अगर और कुछ नहीं तो इससे कुछ दिलचस्प, आंशिक रूप से संबंधित सुरक्षा चर्चाएँ प्रेरित हुई हैं, यानी 3) 16:18 <jrandom> अगर नहीं, तो हम तेज़ी से 3) Tunnel bootstrap हमले पर चल सकते हैं 16:18 <jrandom> हाँ, ऐसा ही हुआ है 16:19 <jrandom> Michael ने जो मुद्दा उठाया, वह मेरे एक सामान्य दृष्टिकोण को परिमाणित करता है, और उसे स्पष्ट रूप से रखना अच्छा है 16:20 <jrandom> इस नए हमले पर आज शाम को और चर्चा होगी (जैसे ही मैं जवाब लिख सकूँ), लेकिन पहला वाला ज़्यादा समस्या जैसा नहीं लगता 16:21 <jrandom> क्या यह लोगों को समझ में आता है, या इसके बारे में कोई सवाल या चिंताएँ हैं? 16:22 <cervantes> हेह... इसका मतलब या तो सभी इससे सहमत हैं या फिर किसी को समझ ही नहीं आया कि मुद्दे क्या हैं 16:23 <cervantes> मैं खुद को 'अज्ञानता ही आनंद है' श्रेणी में रखूँगा 16:23 <jrandom> हेह, यह मूलतः ऐसा हमला है जहाँ बुरे लोग संयोग से हर उस tunnel के आउटबाउंड endpoint बन जाते हैं जिसे आपने कभी बनाया है 16:23 <jrandom> अब, जब आप अभी-अभी शुरू कर रहे होते हैं, तो "आपने जितने भी tunnel बनाए हैं" की संख्या बहुत छोटी होती है (उदा. 0, 1, 2) 16:24 <jrandom> लेकिन कुछ सेकंड बाद, संख्या इतनी बड़ी हो जाती है कि (c/n)^t बहुत ही छोटा हो जाता है 16:25 <tethra> (c/n)^t मतलब... 16:25 <jrandom> (यह उन कारणों में से एक है कि हम स्टार्टअप के थोड़ी देर बाद तक i2cp listener - और इसलिए, i2ptunnel/etc - शुरू नहीं करते) 16:25 <jrandom> c == मिलीभगत करने वाले peers (बुरे लोग) की संख्या, n == नेटवर्क में peers की संख्या, t == आपने बनाए हुए tunnels की संख्या। 16:25 <cervantes> ठीक... 16:25 <tethra> आह 16:26 <jrandom> तो जैसे-जैसे t बढ़ता है, सफल हमले की संभावना बहुत छोटी हो जाती है 16:26 <cervantes> तो इसे व्यवहार्य होने के लिए आपको स्टार्ट होते ही कुछ मिनटों के भीतर अपने router का उपयोग संवेदनशील कामों के लिए शुरू करना होगा? 16:26 <jrandom> (या किसी भी हालत में, एक tunnel के सभी hops पर कब्ज़ा करने की संभावना से भी कम) 16:26 <tethra> आह, समझ गया 16:27 <jrandom> cervantes: तुरंत, तीसरा tunnel बनने से पहले 16:27 <jrandom> (मान लेते हैं कि आप 3 hop tunnels इस्तेमाल करते हैं) 16:27 <cervantes> वह काफ़ी असंभाव्य है 16:28 <cervantes> सिर्फ़ उपयोग-परिदृश्य के नज़रिये से 16:28 <jrandom> बिलकुल। 16:28 <jrandom> और क्योंकि हम स्टार्टअप पर किसी client को चलने देने से पहले 3 से ज़्यादा tunnels बना लेते हैं, यह सिर्फ़ संभावना का मामला नहीं है 16:28 <jrandom> लेकिन फिर भी, हमले को मात्रा में व्यक्त करना अच्छा है 16:29 <cervantes> क्या किसी भी संभावना से बचाव के लिए router को थोड़ी देर और 'चर्न' करने देना उचित होगा? 16:30 <cervantes> या और ज़्यादा 'चर्न'... 16:30 <jrandom> शायद। अगर हम connection स्थापित करने के समय और nonrandom peer selection को नज़रअंदाज़ करें, तो इसकी कोई संभावना नहीं रहती 16:31 <tethra> तो क्या यह 'woot!' मनाने जैसा है, मैं मान लूँ? 16:32 <jrandom> हाँ, लेकिन इंजीनियरिंग के नज़रिये से हमें उन गुणों को नज़रअंदाज़ नहीं करना चाहिए ;) 16:32 <jrandom> तो 0.6.2 के लिए, हम इसे नए सिरे से किए जा रहे tunnel peer selection / ordering implementation के दौरान देखना चाहेंगे, ताकि यह सेंसिबल ढंग से काम कर रहा हो 16:34 <jrandom> ठीक है, अगर 3) पर और कुछ नहीं है, तो 4) I2Phex पर चलते हैं 16:34 <jrandom> sirup यहाँ नहीं है, और मैंने irc पर striker को नहीं देखा - redzara, तुम हो? 16:36 <+redzara> हाँ 16:36 <+redzara> पहला पास लगभग पूरा है : Sirup के mod को नवीनतम phex cvs पर पोर्ट करना। 16:36 <jrandom> बहुत बढ़िया! 16:36 <+redzara> अगला : दूसरा पास : प्रारम्भिक रिलीज़ में इस्तेमाल हुए base phex कोड के साथ Sirup कोड का diff, ताकि मैं कुछ भूल न जाऊँ :) 16:37 <+redzara> शायद इस वीकेंड तक पूरा हो जाएगा 16:37 <jrandom> वाह, यह बढ़िया होगा 16:37 <+redzara> तीसरा पास : GregorK के साथ comm लेयर का refactoring 16:37 <+fox> <GregorK> आशा है कि आप जानते हैं कि नवीनतम Phex CVS में डाउनलोड कोड स्थिर नहीं है और डाउनलोड फ़ाइल पिछली रिलीज़ के साथ संगत नहीं है 16:38 <jrandom> यह I2P है, हम अस्थिरता के आदी हैं :) 16:38 <+fox> <GregorK> :) 16:38 <+redzara> अंतिम पास के लिए, चूँकि इस समय मेरा GregorK से संपर्क नहीं है, यह काफ़ी कठिन होगा :( 16:38 <jrandom> GregorK: एकीकरण के लिए आप क्या सुझाव देंगे? 16:39 <+fox> <GregorK> अच्छा, अब आपका मुझसे संपर्क हो गया ;) 16:39 <jrandom> 'ठीक है' redzara, पहले दो तो वैसे भी काफ़ी बड़े हैं :) 16:39 <+redzara> GregorK : हाय यार 16:40 <+redzara> GregorK : मैंने सारा कोड ध्यान से पढ़ लिया है 16:40 <+fox> <GregorK> मुझे एक परत (layer) बनाने का आइडिया है... मैं इसे जितना अच्छा तैयार कर सकूँगा, कर दूँगा और फिर देखेंगे कि यह कितना फिट बैठता है और क्या बदलने की ज़रूरत है 16:40 <+fox> <GregorK> सारा?? वाह... 16:40 <+redzara> Gregork : हाँ, सब !! 16:41 <cervantes> उसे तो तुम्हारे अंडरवियर का साइज़ भी पता है 16:41 <Rawn> :D 16:41 <+fox> <GregorK> बहुत बढ़िया... अगली बार जब मैं शॉपिंग करूँगा तो बस तुमसे पूछ लूँगा... 16:43 <+fox> <GregorK> अच्छा होगा अगर i2phex टीम में से कोई phex टीम में भी हो सके.. 16:43 <jrandom> redzara: तो, क्या आपको लगता है कि मुख्य Phex में सब कुछ एक plugin layer में मर्ज करने से पहले आपके दूसरे पास के नतीजों के साथ हमारा 0.1.2 I2Phex रिलीज़ होगा? या यह सब एक साथ ही होगा? 16:43 <+redzara> माफ़ कीजिए, लेकिन मैं अंग्रेज़ी उतनी अच्छी तरह नहीं समझ/बोल/पढ़/लिख पाता कि जो आपने लिखा है उस पर हँस सकूँ 16:43 <+fox> <GregorK> यह उन बग्स को सुलझाने में भी मदद करेगा जो दोनों तरफ हैं 16:44 <jrandom> GregorK: उम्मीद है हम ऐसा तरीका निकालेंगे कि I2P वाला हिस्सा Phex में बस एक पतला plugin हो, है न? 16:44 <jrandom> या आपको लगता है कि दोनों अलग ही रहें? 16:44 <+redzara> jrandom : मेरा मानना है कि हम I2P पर Phex 2.6.4 रख सकते हैं, मेरे लिए I2Phex अब डाउन 16:45 <jrandom> डाउन? 16:45 <+fox> <GregorK> मुझे नहीं पता कि शुरू से ही इसे ऐसे कर पाएँगे या नहीं, लेकिन मुझे लगता है इसका बड़ा हिस्सा एक plugin में अलग किया जा सकता है। 16:45 <jrandom> कूल, हाँ, यह बहुत काम है, पक्का 16:46 <jrandom> खासकर जब आप java.net.URL जैसी चीज़ों को देखते हैं (जो instantiation पर DNS अनुरोध लीक करता है, आदि) 16:46 <+redzara> jrandom : डाउन, ख़त्म 16:46 <+Ragnarok> ग्र्र 16:47 <jrandom> ठीक है redzara, एक बार जब हम I2P पर Phex 2.6.4 सबकुछ काम करवा लें, मैं सहमत हूँ, तब I2Phex की ज़्यादा ज़रूरत नहीं लगेगी 16:47 <+fox> <GregorK> ठीक है... मेरा खयाल है Phex कुछ जगहों पर इसे बायपास करने के लिए Apache की URI क्लास का इस्तेमाल करता है... पर सिर्फ़ जब ज़रूरी हो 16:48 <jrandom> अच्छा सही, मुझे याद है कि मैंने उस लाइब्रेरी के साथ खेला था, ठीक लगती है 16:49 <jrandom> हम निश्चित रूप से I2P पर एंड यूज़र्स के लिए इसे पुश करने से पहले anonymity/security के लिए कुछ ऑडिट में मदद करेंगे 16:49 <jrandom> (यह सुझाव नहीं कि Phex में कोई समस्या है, बस हर ऐप में समस्याएँ होती हैं, और उम्मीद है हम उन्हें सुलझाने में मदद कर सकेंगे) 16:50 <+fox> <GregorK> Socket के उपयोग वगैरह जैसी कुछ चीज़ों के लिए मेरे पास इसे स्मूथली इंटीग्रेट करने का आइडिया है... लेकिन अन्य जगहें जैसे अलग-अलग फीचर्स UDP वगैरह... उनके लिए अभी पक्का नहीं कि उन्हें सबसे अच्छे तरीके से कैसे हल करें 16:50 <+fox> <GregorK> ओह, मुझे यक़ीन है कि Phex में कई समस्याएँ हैं. :) 16:50 <jrandom> हाँ, sockets आसान होंगे, लेकिन हमें अन्य चीज़ें disable करनी पड़ सकती हैं। UDP किस काम के लिए है - तेज़ queries? 16:51 <+fox> <GregorK> फिलहाल केवल bootstrapping 16:51 <+fox> <GregorK> UDP Host Cache.. GWebCache का एक विकल्प 16:52 <jrandom> आह्ह, ठीक है। 16:52 <+redzara> तो अगर हमारे पास एक बढ़िया GWebCache हो तो इसकी ज़रूरत नहीं? 16:53 <+fox> <GregorK> हाँ... लेकिन स्टैंडर्ड GWebCache में भी सुरक्षा समस्याएँ होती हैं... 16:53 <+redzara> GregorK : I2P के अंदर नहीं, मेरा खयाल है 16:54 <jrandom> ओह, वह हिस्सा संभाला जा सकता है - I2PSocket authenticated है - आपको दूसरी तरफ़ वाले peer का 'destination' पता होता है, तो वे यह नहीं कह सकते "मैं, उह... whitehouse.gov.. हाँ!" 16:54 <jrandom> पर आप सही हैं, इसे सत्यापित करना पड़ेगा 16:54 <+fox> <GregorK> साथ ही firewall-to-firewall ट्रांसफ़र्स भी UDP से जुड़ा एक विषय है जिसे हम किसी स्वयंसेवक के मिलते ही लागू करना चाहेंगे :) 16:54 <jrandom> अच्छा, I2P को firewall-to-firewall ट्रांसफ़र्स की ज़रूरत नहीं है - I2P एक पूरी तरह खुला end to end address space देता है :) 16:55 <jrandom> लेकिन... ओह, वह उपयोगी हो सकता है 16:55 <jrandom> अगर Phex यूज़र्स के पास "0 hop tunnels" हों, तो उन्हें NAT traversal/firewall-to-firewall ट्रांसफ़र्स मुफ़्त में मिलेंगे, और काफ़ी अच्छी स्पीड के साथ 16:55 <+fox> <GregorK> एक और चीज़ होगी LAN पर queries आदि की ब्रॉडकास्ट... निजी नेटवर्क्स में सामग्री साझा करना आसान करने के लिए 16:56 <jrandom> (0 hop tunnels किसी भी मध्यवर्ती peers को ट्रैफ़िक वहन करने की ज़रूरत के बिना plausible deniability का एक स्तर देते हैं) 16:57 <jrandom> हम्म, LAN broadcast अच्छा है, पर मुझे यक़ीन नहीं कि i2p को सच में उसकी ज़रूरत होगी (क्योंकि दूसरे peer का स्थान जानना anonymity के लिए जोखिम है :), तो शायद I2P plugin उपयोग करते समय उस फ़ीचर को disable किया जा सके? 16:58 <cervantes> *डिफ़ॉल्ट रूप से disabled 16:58 <+fox> <GregorK> खैर, यह अभी उपलब्ध नहीं है.. लेकिन इस मामले में वैसे भी उपयोगकर्ता उस private नेटवर्क को बनाने के लिए आमतौर पर एक-दूसरे को जानते हैं.. 16:58 <jrandom> ओह सही cervantes 16:58 <jrandom> सही सही GregorK 16:59 <+fox> <GregorK> यूज़र इंटरफ़ेस के संबंध में कोई बदलाव हैं?? 17:00 <+bar> ठीक है, हमें झंडों की ज़रूरत नहीं पड़ेगी :) 17:00 <jrandom> कम से कम, I2P से संबंधित कुछ configuration विकल्प रखने की क्षमता उपयोगी होगी। 17:01 <jrandom> मुझे लगता है sirup कुछ डिस्प्ले को इस तरह स्विच कर पाया था कि IP + पोर्ट नंबर दिखाने के बजाय I2P 'destinations' दिखें, तो मुझे लगता है वह ठीक था 17:01 <+redzara> और bitzyNot के बारे में—अभी के लिए, लेकिन flags और countries उपयोग में नहीं हैं 17:01 <jrandom> bitzy? 17:01 <+redzara> सॉरी, गलत कॉपी/पेस्ट :( 17:02 <+fox> <GregorK> क्या आप आवश्यक configuration विकल्पों और वैकल्पिक फ़ीचर्स की सूची दे सकते हैं? 17:03 <jrandom> मुझे यकीन है हम आपको वे दे सकेंगे। I2P जिस host+port पर चल रहा है और प्रदर्शन/anonymity ट्वीक्स से जुड़ी कुछ ड्रॉपडाउन—इतना काफ़ी होना चाहिए 17:03 <jrandom> फिर भी, हम आपको विवरण दे देंगे 17:02 <cervantes> [x] सुपर ट्रांसफ़र स्पीड मोड 17:02 <+fox> <GregorK> खैर bitzi फ़ाइलों की पहचान करने के लिए इस्तेमाल होता है.. क्या वह anonymity की समस्या है? 17:03 <vulpine> <redzara> GregorK : मैं इसे तैयार कर रहा हूँ, पर मूल रूप से, कोई बदलाव नहीं है 17:03 <+fox> <GregorK> :) अपने प्रदाता से पूछो cervantes... 17:03 <redzara> GregorK : शायद, मैं इस पर काम कर रहा हूँ 17:04 <cervantes> GregorK: हेह, यूके निवासी.... कोई चांस नहीं ;-) 17:04 <+fox> <GregorK> अगर आप एक ही पीसी पर 2 Phex instances के बीच फ़ाइलें ट्रांसफ़र करें.. ट्रांसफ़र बिजली-सी तेज़ होते हैं ;) 17:05 <cervantes> कूल... मेरे पास ढेर सारी बढ़िया फ़िल्में हैं जिन्हें मैं अपने आप से साझा कर सकता हूँ :) 17:05 <cervantes> * इसे बैठक नोट्स से निकाल दें * 17:06 <bar> jrandom ने पहले इस विषय को छुआ था, लेकिन, यहाँ वह पागलपन भरा आइडिया फिर से है: 17:06 <+bar> i2p को Phex में इंटीग्रेट करने के बारे में क्या खयाल है, ताकि सामान्य उपयोगकर्ताओं के पास 0-hop tunnels हों? 17:07 <+fox> <GregorK> मेरा खयाल है flags और IP+port का डिस्प्ले HostAddress ऑब्जेक्ट से आता है.. जिसे नई layer से छिपाया जाएगा.. तो आप कुछ और दिखा सकते हैं 17:07 <+bar> (plausible deniability और UDP फ़ायरवॉल होल पंचिंग के लिए) 17:08 <+fox> <GregorK> पक्का नहीं कि मैं सच में समझ रहा हूँ कि उसका मतलब क्या है ;) 17:08 <+bar> शायद मैं भी नहीं ;) 17:09 <jrandom> GregorK: मूल रूप से, इसका मतलब है कि Phex उपयोगकर्ता आपस में सीधे बात करेंगे, लेकिन plausible deniability मिलेगी, क्योंकि वे परोक्ष रूप से भी बात कर रहे हो सकते हैं 17:09 <+bar> jrandom, यक़ीन है आप मेरी बात समझ रहे हैं, क्या आप विस्तार से बताएँगे? 17:09 <jrandom> उन्हें I2P का NAT traversal भी मुफ़्त में मिल जाएगा, साथ ही डेटा सुरक्षा और ISP/आदि द्वारा स्निफ़िंग से सुरक्षा भी 17:09 <+redzara> GregorK : तो आपको host+port + IsLocalIP + IsPrivateIP + ... से संबंधित सारा कोड हटाना होगा 17:10 <jrandom> दूसरी ओर, (एक बड़ी दूसरी ओर), यह उन gnutella क्लायंट्स से बात नहीं कर पाएगा जो I2P के ऊपर नहीं चलते 17:10 <jrandom> (हालाँकि, अंततः, सब चलेंगे ;) 17:10 <+fox> <GregorK> मुझे लगता है पहला कदम—और वह अपने आप में काफ़ी बड़ा कदम है—i2p और phex को ज़्यादा करीब लाना है। 17:10 <jrandom> सहमत 17:10 <+bar> (कमबख्त, यह ध्यान नहीं आया) 17:11 <+bar> हाँ, निश्चित रूप से 17:11 <jrandom> यह उड़ते टट्टू वाली बातें हैं। पहले व्यावहारिक चीज़ें कर लें 17:11 <+fox> <GregorK> और जब देख लें कि वह कितना अच्छा चला, तब तय करेंगे कि आगे कैसे बढ़ना है.. 17:11 <jrandom> बिल्कुल 17:12 <+fox> <GregorK> redzara: मैं HostAddress की दो implementations रखना चाहूँगा—एक i2p के लिए और एक अभी जैसी। 17:14 <+redzara> Gregork : कोई समस्या नहीं, मैंने अपने mod में सारा कोड कमेंट कर दिया है, आप आसानी से दो implementations बना सकते हैं। बस मुझे प्रारम्भिक काम पूरा करने दीजिए 17:14 <+fox> <GregorK> ज़रूर.. कोई दिक्कत नहीं.. 17:14 <jrandom> :) ठीक है, तो redzara, क्या आपको लगता है कि हम अगले हफ्ते कभी नए Phex-2.4.2 आधारित वर्शन का अल्फ़ा टेस्ट कर पाएँगे? 17:15 <jrandom> (फेज़ 2 वाले हिस्से के लिए। आपका फेज़ 3 मुख्य लाइन के साथ इंटीग्रेट करने में अधिक काम लेगा) 17:15 <+redzara> jrandom : अगला हफ़्ता मेरे लिए ठीक लगता है 17:16 <jrandom> ठीक है, बढ़िया 17:16 <+redzara> s/next/next week/ 17:16 <jrandom> ठीक है, यह काफ़ी रोमांचक चीज़ है, इसे सुचारू रूप से चलाना शानदार होगा 17:17 <jrandom> क्या किसी के पास 4) I2Phex पर कुछ और उठाने के लिए है, या हम संक्षेप में 5) Syndie/Sucker पर बढ़ें? 17:17 <cervantes> I2P को ऐसी killer apps से ज़रूर फ़ायदा होगा 17:18 <+fox> <GregorK> वैसे Phex में सभी CVS परिवर्तनों के लिए एक Phex CVS मेलिंग सूची है... अगर वह मददगार हो 17:18 <jnymo> *एहेम*.. बिल्कुल हाँ 17:18 <jrandom> ठीक है, बढ़िया, धन्यवाद GregorK 17:18 <jrandom> बिल्कुल cervantes 17:19 <jrandom> ठीक है, 5) पर, वहाँ जो है उसके अलावा मेरे पास सच में जोड़ने को कुछ नहीं है 17:19 <jrandom> dust: क्या तुम हो? 17:19 <+redzara> GregorK : धन्यवाद, लेकिन एक ही वर्शन संभालना मेरे लिए काफ़ी है :) 17:19 <jrandom> हेहे redzara 17:19 <dust> हाल में मेरे पास ज़्यादा खाली समय नहीं था, पर अगर मिला तो मैं addresses.jsp वाली चीज़ को समझने की कोशिश करूँगा, वहाँ protocol ड्रॉपडाउन में 'RSS' जोड़ूँगा और फिर Updater, Sucker से होते हुए BlogManager तक एक पाथ बनाऊँगा। 17:20 <dust> जब तक किसी के पास इससे बेहतर आइडिया न हो 17:20 <jrandom> जबर्दस्त 17:20 <jrandom> यह बढ़िया लगता है। 17:21 <jrandom> हालाँकि, हम्म, शायद इसमें एक अतिरिक्त फ़ील्ड की ज़रूरत पड़े ("किस blog में पोस्ट करना है" और "कौन-सा tag prefix")... 17:21 <jrandom> शायद एक अलग फ़ॉर्म/टेबल मायने रखे, हालांकि हो भी सकता है कि नहीं 17:22 <dust> ओह, मुझे लगा addresses.jsp केवल एक blog के लिए है (क्योंकि वहाँ पहुँचने के लिए लॉगिन करना पड़ता है?) 17:22 <jrandom> आह, सही, अच्छा पॉइंट 17:23 <jrandom> updater वाला हिस्सा थोड़ा अस्पष्ट है, पर तुम सही हो 17:23 <dust> (जब वहाँ पहुँचेंगे तो समझ लेंगे) 17:23 <jrandom> हाँ 17:24 * jnymo सोचता है www.i2p.net एक 'merchandise cafe' जैसा कुछ शुरू कर सकता है 17:24 <jnymo> 'eyetoopie' टी-शर्ट्स के साथ, जिन पर लिखा हो "I am Jrandom" ;) 17:24 * mrflibble अभी भी "flamewar" को पकड़ रहा है, जो लगता है कि एक असली flamewar में बदल रही है :) 17:24 <jrandom> हेह jnymo 17:25 <jrandom> हाँ, उस थ्रेड में बहुत सारा कंटेंट है 17:25 <jrandom> ठीक है, शायद यह हमें 6) ??? तक ले आता है 17:25 <jrandom> क्या किसी के पास बैठक में उठाने के लिए कुछ और है? 17:25 <+bar> हाँ, symmetric NAT मुद्दे पर एक छोटा-सा नोट (थोड़ा-सा 'snooping' कर रहा था): 17:25 <+nickless_head> jrandom: मुझे सच्चाई पता है! 17:25 <+fox> <blx> kaffe? 17:25 <mrflibble> उफ़, माफ़ करना jr 17:26 <jnymo> लेकिन सच में.. किसी भी आकार का हर ओपन सोर्स प्रोजेक्ट अपनी खुद की merchandise सेक्शन रखता है 17:26 <+nickless_head> jrandom: मेरे पास पक्का सबूत है कि आपने last.fm का होमपेज हैक किया! 17:26 <+nickless_head> (साइन अप करने पर क्या मिलता है वाले सेक्शन में 'a pony' सूचीबद्ध था) 17:26 <jrandom> jnymo: मुझे लगता है आप सही हैं, हमें उस दिशा में तलाश करनी चाहिए, यह फंडरेज़िंग का अच्छा तरीका भी हो सकता है 17:27 <jnymo> jrandom: बिल्कुल 17:27 * mrflibble टी-शर्ट खरीदूँगा 17:27 <+bar> हाँ, symmetric NATs के बारे में, 17:27 <+bar> जहाँ तक मेरी समझ है, पहले से समर्थित NATs के विपरीत, इसमें कोई जादुई ट्रिक नहीं है। इसे सही तरीके से करने का एक ही तरीका है: हर symmetric NAT के व्यवहार का अध्ययन और परीक्षण करना और probing के लिए introducers का उपयोग करना। 17:28 <jrandom> blx: नवीनतम kaffe CVS पूरी तरह b0rked है। crypto पैकेज स्रोत में हैं ही नहीं, prng initialize होने में विफल रहता है, और URL handlers file:// को संभाल नहीं पाते :( 17:28 <jnymo> शायद आप इसे पब्लिक में तब तक नहीं पहनना चाहेंगे जब तक i2p के कुछ हज़ार यूज़र्स न हो जाएँ ;) 17:28 <+bar> (मेरा मानना है कि उदाहरण के लिए Hamachi और Skype symmetric NATs के पीछे से UDP hole punching इसी तरह करते हैं) 17:28 <+nickless_head> jnymo: कप्स बढ़िया रहेंगे :) 17:28 <+bar> अब तक नेट पर जो मैंने पढ़ा है, उसके आधार पर symmetric NAT prediction एल्गोरिद्म काफ़ी बेकार हैं। 17:28 <jrandom> हम्म bar 17:28 <mrflibble> हेहे, मैं अपना निक नहीं डालूँगा। ओह, और मैं अभी भी ज़िंदा/गिरफ्तार-नहीं, जबकि मेरे पास IIP टीशर्ट है 17:28 <jrandom> हाँ, मैंने भी यही पढ़ा 17:29 <+bar> मैं इस पर कुछ और अच्छा, प्रासंगिक पढ़ने का सामान इकट्ठा करने की कोशिश करूँगा। 17:29 <+redzara> छोटा-सा सवाल: 0.6.1.3 में retransmitted bytes का सामान्य औसत प्रतिशत क्या था? 17:29 <jrandom> धन्यवाद bar 17:29 <+fox> <jme___> bar, जो prediction उन्होंने पाए हैं क्या वे सुसंगत हैं? 17:29 <+fox> <jme___> bar, मुझे फिर से कहने दीजिए :) 17:29 <+fox> <blx> jrandom, यह सुनकर दुख हुआ 17:30 <jrandom> redzara: दुर्भाग्य से मैं उसे netDb में डालना भूल गया। हालांकि अभी 2.6 और 3.8 दिख रहे हैं 17:30 <jrandom> blx: मुझे भी :( 17:30 <+fox> <jme___> bar, जब आप NAT बॉक्स के व्यवहार का विश्लेषण करते हैं और उसे predict करने का कोई सूत्र निकालते हैं, तो क्या वह इस NAT बॉक्स के लिए हमेशा काम करता है? या बाद में कभी काम करता है, कभी नहीं? 17:30 <jrandom> blx: मुझे पता है वे अभी classpath के साथ कुछ मर्जिंग कर रहे हैं, तो उम्मीद है वह सुलझते ही 17:30 <+fox> <blx> शायद इसका मतलब है कि मैं पार्टी में शामिल नहीं हो पाऊँगा 17:30 <jrandom> blx: आप kaffe-विशेष हैं, या OSS/DFSG-विशेष? 17:31 <+fox> <blx> मुक्त सॉफ़्टवेयर 17:31 <+fox> <blx> कह सकते हैं DFSG 17:31 <jnymo> यदि कोई i2p उपयोगकर्ता i2p के लिए होस्टेड सर्वर इस्तेमाल करना चाहता है, तो कौन-सी उदार, सस्ती होस्टेड सेवाओं वाली कंपनी ठीक रहेगी? 17:31 <+bar> jme___: रिपोर्ट के मुताबिक Hamachi सभी कनेक्शन प्रयासों में से 97% को मध्यस्थता कर पाता है। मेरा खयाल है कुछ NATs ऐसे भी हैं जो पोर्ट असाइन करते समय लगभग रैंडम व्यवहार दिखाते हैं 17:32 <jrandom> ठीक है, यक़ीन है हम कुछ न कुछ कर लेंगे blx। kaffe काम करता था, और हम किसी Sun-विशिष्ट चीज़ पर निर्भर नहीं हैं 17:32 <jrandom> jnymo: मैं sagonet.net इस्तेमाल करता हूँ, पर उन्होंने अपनी कीमतें 65/माह से 99/माह कर दी हैं (पर तेज़ लिंक पर 1250GB/माह मिलता है) 17:32 <jrandom> मुझे पता है जर्मनी में भी कुछ सस्ते विकल्प हैं 17:33 <+fox> <jme___> bar, 97% शानदार होगा 17:33 <jrandom> redzara: आपको retransmission rate क्या दिख रहा है? 17:33 <+bar> jme___: हाँ, तो लगता है ज़्यादातर symmetric NATs भविष्यवाणी-योग्य हैं 17:33 <+fox> <blx> jrandom, उम्मीद है। मैं इस चीज़ में सचमुच दिलचस्पी रखता हूँ :) 17:33 <+fox> <jme___> bar, आप क्या करेंगे? रिले, UDP होल पंचिंग, cnx reversal.. क्या और भी टेक हैं? 17:33 <jnymo> 99 औसतन महँगा है? 17:34 <+redzara> jrandom: 3.8 और 4.2 के बीच 17:34 <jrandom> jme___: हम UDP हैं, connection reversal की ज़रूरत नहीं :) 17:35 <+bar> jme___: मैं विशेषज्ञ नहीं हूँ, शायद अगले हफ्ते की बैठक तक मेरे पास और जानकारी होगी (लेकिन मुझे तो profiling + UDP hole punching जैसी ही गंध आ रही है ;) 17:35 <jrandom> jnymo: 1250GB के लिए, नहीं। मैंने 50-100GB/माह के लिए 60-120 USD/माह देखे हैं 17:35 <jrandom> bar: शायद UPnP बेहतर रास्ता होगा? 17:35 <+fox> <jme___> jrandom, UDP के साथ भी यह उपयोगी है :) 17:35 <+redzara> jrandom : पर केवल कुछ nodes ने बड़ा असर किया, शायद कुछ पुराने 17:35 <+fox> <jme___> vulpine: ठीक है 17:35 <jrandom> हालांकि वह सिर्फ़ उन लोगों की मदद करेगा जो अपनी NAT नियंत्रित कर सकते हैं 17:36 <+fox> <jme___> UPnP का समर्थन होना चाहिए, पर यह अन्य तरीकों का विकल्प नहीं है 17:36 <jrandom> अच्छा, अभी हम जो कुछ कर रहे हैं वह बिना किसी UPnP के कर रहे हैं 17:36 <+fox> <jme___> क्योंकि सभी NAT में UPnP समर्थित नहीं है, उससे तो बहुत दूर है 17:36 <jrandom> सही, जैसे किसी ISP की NAT 17:36 <+bar> jrandom: यदि UPnP में सुरक्षा समस्याएँ नहीं हैं, तो शायद नुकसान नहीं होगा। हालांकि, Hamachi UPnP इस्तेमाल नहीं करता 17:36 <+fox> <jme___> यहाँ 'must' का मतलब = अधिकतम कनेक्टिविटी प्रदान करना 17:37 <+fox> <jme___> ठीक है, अपनी C++ पर लौटता हूँ :) 17:38 <jrandom> सही jme___, हालांकि अगर हम cone/restricted hole punching के अलावा symmetric hole punching भी कर सकें, तो हम बढ़िया स्थिति में होंगे 17:38 <jrandom> बाद में मिलते हैं jme___ 17:38 <jrandom> हाँ, अगर हमें उसकी ज़रूरत न पड़े तो आदर्श होगा 17:39 <jrandom> ठीक है, क्या किसी के पास बैठक में उठाने के लिए कुछ और है? 17:41 <jrandom> अगर नहीं... 17:41 * jrandom समेटता है 17:41 * jrandom *baf* करता है और बैठक बंद करता है