I2P डेवलपर बैठक - 29 नवंबर, 2005

15:25 <jrandom> 0) हाय 15:25 <jrandom> 1) नेट स्थिति और 0.6.1.6 15:25 <jrandom> 2) Syndie 15:25 <jrandom> 3) I2P Rufus 0.0.4 15:25 <jrandom> 4) ??? 15:25 <jrandom> 0) हाय 15:25 * jrandom हाथ हिलाता है 15:25 <jrandom> साप्ताहिक स्टेटस नोट्स यहाँ हैं @ http://dev.i2p.net/pipermail/i2p/2005-November/001234.html 15:26 * bar jrandom को एक baf थमाता है 15:26 <c3rvantes> अभी नहीं! 15:26 * jrandom तैयार होता है 15:26 <jrandom> उह... 15:26 <jrandom> चलो पहले एजेंडा के कुछ मदों पर चलते हैं :) 1) नेट स्थिति और 0.6.1.6 15:27 <jrandom> पिछली कुछ रिलीज़ में बहुत-सी चीज़ें अपडेट हुई हैं, लेकिन नेटवर्क अभी भी काफ़ी स्थिर लगता है। 15:28 <jrandom> कुछ routers पर router participation में काफ़ी तेज़ स्पाइक्स आए हैं, हालांकि वह काफ़ी हानिरहित है 15:28 <+legion> अच्छा, मैं सहमत हूँ net status बेहतर हो रहा है। और हाँ 0.6.1.7 के लिए tcp क्यों न हटा दें 15:28 <jrandom> (उह, मेरा मतलब tunnel participation में स्पाइक्स) 15:29 <@cervantes> तुम मज़ाक नहीं कर रहे 15:29 <jrandom> पक्का नहीं, legion। कुछ उपयोगकर्ता सिर्फ tcp तक सीमित हो सकते हैं, लेकिन मुझे याद है कि ऐसे बस एक या शायद दो ही थे 15:29 <+legion> अच्छा, मैंने नोट किया है कि 0.6.1.5 में कभी-कभी router खुद ही रीस्टार्ट हो जाता था। 15:29 <+Complication> मेरे यहाँ उचित सीमा के भीतर उतार-चढ़ाव रहा है, 100 से 250 participating tunnels 15:29 <jrandom> इसे रखने का कोई बड़ा कारण नहीं सूझता, और इसे हटाने के कुछ कारण ज़रूर सूझते हैं 15:30 <jrandom> बढ़िया, Complication 15:30 <jrandom> (stats.i2p/ के अनुसार ये संख्या काफ़ी औसत हैं, लेकिन याद रहे, ऐसी संख्याएँ anonymity को नुकसान पहुँचा सकती हैं, इसलिए इन्हें वास्तव में साझा नहीं करना चाहिए, खासकर लॉग होने वाली बैठकों में ;) 15:30 <+Complication> मेरा पुराना Celeron अभी भी लगभग हर 10 घंटे में ऑटो-रीस्टार्ट हो जाता है 15:30 <+Complication> वरना यह पहले से बेहतर कनेक्टेड है 15:30 <Pseudonym> इसे हटाने के कारण क्या हैं? 15:31 <+Complication> TCP महँगा पड़ता है 15:31 <@cervantes> मेरा router जवाब दे रहा है 15:31 <+Complication> threads प्रति connection के हिसाब से 15:31 <@cervantes> Complication: उसे 10 से गुणा करो, वही मेरे router की मौजूदा रेंज है ;-) 15:31 <+legion> मेरे यहाँ 200-400 participating tunnels के बीच उतार-चढ़ाव रहा है, तो पहले से बेहतर लगता है। 15:32 <+Complication> cervantes: आह, आह 15:32 <+Complication> मैंने एक अजीब हादसा देखा था जिसमें 2000 participating tunnels हो गए थे, लेकिन वह गर्मियों में था 15:32 <jrandom> Pseudonym: प्रदर्शन (cpu/memory, हमारी semireliable आवश्यकताओं के कारण बेहतर scheduling), रखरखाव-योग्यता, अधिक प्रभावी शिटलिस्टिंग 15:32 <+Complication> एक अकेला स्पाइक जो फिर कभी नहीं हुआ 15:32 <+legion> हाँ, पिछली कुछ versions में ऐसे स्पाइक्स थे 15:32 <jrandom> Complication: इस पिछली rev में हमारे पास > 2000 tunnel स्पाइक्स आए हैं 15:33 <jrandom> पर उम्मीद है 0.6.1.7 उसे संभाल लेगा 15:33 <+legion> हाँ, ये tcp हटाने के अच्छे कारण हैं :) 15:33 <jrandom> लेकिन फिर भी, tunnel participation में स्पाइक्स ठीक हैं, क्योंकि उनमें से ज़्यादातर उपयोग नहीं होते 15:34 <@cervantes> Pseudonym: नेटवर्क पर tcp इस्तेमाल करने वाले शायद बस एक-दो routers ही बचे हैं 15:34 <jrandom> इस rev में भी tcp हटाना अच्छा विचार हो सकता है, क्योंकि इसमें अन्य बड़े बदलाव नहीं हैं। इस तरह हम साफ़-साफ़ देख सकेंगे कि इसका क्या असर पड़ता है 15:34 <jrandom> (और आवश्यकता होने पर इसे फिर सक्षम कर सकते हैं) 15:35 <Pseudonym> यदि इसे सिर्फ दो routers ही उपयोग कर रहे हैं, तो मुझे नहीं लगता कि इससे किसी भी तरह अधिक असर पड़ेगा 15:35 <Pseudonym> (सिवाय इसके कि नेटवर्क पर दो routers कम हो जाएँगे) 15:35 <@cervantes> 2 नाखुश ग्राहक 15:35 <jrandom> खैर, यह transport कुछ अजीब स्थितियों में दिख जाता है, जो इसे अक्षम करने की मेरी वजहों में से एक है :) 15:35 <+Complication> आशा है वे इसे बहुत व्यक्तिगत नहीं लेंगे 15:36 <+Complication> कुछ ISP का UDP को फ़िल्टर करना वाकई बुरा है। 15:36 <+Complication> बुरा, और पूरी तरह बेमतलब। 15:36 <jrandom> (उदाहरण के लिए, जब कोई router खराब हो जाता है, लोग अपने SSU transport को failing चिह्नित कर देते हैं, और तब वे tcp transport पर लौट आते हैं) 15:36 * Pseudonym अपने ISP से प्यार करता है। कोई पाबंदियाँ नहीं 15:37 <+Complication> तो TCP के बिना, हम देख पाएँगे कि UDP इसे अकेले कैसे संभालता है? 15:37 <+Complication> "बिना सहायक पहियों के" :P 15:37 <+legion> अच्छा, तो tcp के बिना ऐसे बुरे फ़िल्टरिंग से कैसे निपटेंगे? 15:38 <jrandom> बिलकुल, Complication :) 15:38 <jrandom> legion: नहीं निपटते 15:38 <jrandom> (restricted routes (प्रतिबंधित रूट्स)) 15:38 <+Complication> खैर, फ़ाइल-शेयरिंग प्रोग्राम्स के अलावा भी कई उपयोगी apps नहीं हैं जो DNS packets से बड़े आकार वाले UDP packets का उपयोग करते हैं? 15:39 <+legion> :( अच्छा नहीं लगता 15:39 <+Complication> I2P द्वारा उपयोग किए जाने वाले सबसे छोटे packet size के समान आकार? 15:39 <jrandom> अरे legion, यह कोई समस्या नहीं है 15:39 <jrandom> Complication: streaming प्रोटोकॉल्स 15:39 <+Complication> DNS को पंगु किए बिना UDP को सीधे कभी भी ब्लॉक नहीं किया जा सकता। 15:39 <+Complication> पैकेट साइज सीमित किया जा सकता है। 15:40 <+legion> ठीक है, सुनने में लगा था कि हो सकती है 15:40 <+Complication> VoIP? 15:40 <jrandom> यह समस्या तब होती जब यह व्यापक होता - अगर इंटरनेट समुदाय आम तौर पर UDP को बैन कर देता 15:40 <+Complication> हम्म, क्या VoIP बड़े या छोटे पैकेट्स उपयोग करता है? 15:40 <jrandom> लेकिन अगर यह कुछ ISPs तक ही सीमित है, तो हम उन्हें restricted routes की तरह ट्रीट कर सकते हैं 15:40 <+Complication> या तुम कहना चाह रहे थे... वीडियो spreaming? 15:40 <+legion> मुझे लगता है यह दोनों का मिश्रण उपयोग करता होगा 15:41 <jrandom> दोनों, Complication, RTSP UDP पर चलता है, और real RTSP पर चलता है iirc 15:41 <+Complication> s/p/s 15:42 <+legion> तो अगले आइटम पर चलें? 15:42 <+Complication> cat /etc/services | grep -c udp 15:42 <+Complication> 227 15:43 <jrandom> मैं अभी पक्का नहीं हूँ कि हम 0.6.1.7 में tcp हटाएँगे, पर शायद। 15:43 <jrandom> हाँ, 1) पर किसी के पास कुछ और है? अगर नहीं, तो 2) Syndie पर चलते हैं 15:43 <+Complication> मतलब, कम से कम 227 apps (कुछ शायद पुराने या LAN apps) हैं जो UDP उपयोग करते हैं 15:44 <jrandom> अरे, यह तो intarweb है। आपको बस proxied HTTP access चाहिए 15:44 <jrandom> मेल (और Syndie पर) जो है उसके अलावा 2) में मेरे पास जोड़ने के लिए बहुत कुछ नहीं है 15:44 <+legion> मैं आश्वस्त हूँ, हाँ इसे हटा दें। :) 15:44 <jrandom> syndie के बारे में किसी को कुछ उठाना है? 15:45 <+legion> मेरे पास भी 2) पर कहने को कुछ नहीं। 15:45 * Complication "how Syndie works" पढ़ रहा है 15:46 <+Complication> एक छोटा-सा UI इफ़ेक्ट मुझे बार-बार चौंका देता है। :D 15:46 <+Complication> जब मैं संदेशों का कोई thread expand करता हूँ, तो यह देखकर हमेशा चौंक जाता हूँ कि active message सूची में सबसे ऊपर चला जाता है। :P 15:47 <+Complication> पर आप उसे सुरक्षित रूप से नज़रअंदाज़ कर सकते हैं। मैं बस बहुत चुस्त, और आदतों का गुलाम हूँ। :P 15:47 <@cervantes> threading मॉडल पर विस्तार से चर्चा हो रही है 15:47 <@cervantes> ;-) 15:47 <+Complication> मैं इसकी आदत डाल लूँगा। :) 15:48 <+Complication> cervantes: Syndie में? मुझे वह thread ढूँढना होगा। :) 15:48 <@cervantes> मुझे भी वह पसंद नहीं — पर यह बदल सकता है 15:48 <jrandom> हाँ, वह थोड़ा अटपटा है, मेरा ख्याल है 15:48 <+legion> हाँ 15:48 <@cervantes> "subject: syndie threading" 15:49 <+Complication> वैसे, अगर expanded message सबसे नीचे होता, तो उसे वैसे भी हिलना ही पड़ता। 15:49 <+Complication> क्योंकि नहीं तो वह वहीं अटका रहता। 15:50 <jrandom> देखो, नीचे की nav एक समय में 10 *threads* दिखाती है, 10 messages नहीं। तो वह नीचे वाले thread को expand कर सकती है 15:50 * cervantes इस समय कुछ अलग-अलग threading UI style implementations का परीक्षण कर रहा है 15:51 <jrandom> शानदार 15:51 <jrandom> हाँ, आदर्श रूप से हम उन्हें css में बदल-बदल कर देख पाएँगे, या नहीं तो server side पर 15:52 <@cervantes> या यूँ कहें "threading navigation styles" 15:53 <@cervantes> हम्म, मेरे tests डिफ़ॉल्ट रूप से pure html nested unnordered lists इस्तेमाल करते हैं 15:53 <@cervantes> आप जितनी चाहे css और javascript की लेयर लगा सकते हैं 15:53 <jrandom> कोई ETA है कि हम कुछ mockups कब देख पाएँगे? 15:53 <@cervantes> (हालाँकि यह सिर्फ़ proof of concept है, वास्तविक ui implementation नहीं) 15:54 <@cervantes> मैं अपना ज़्यादातर कोडिंग I2P मीटिंग्स के दौरान करता हूँ ;-) 15:54 <jrandom> हेह 15:54 <@cervantes> शायद पहला mockup आज शाम तक तैयार होगा 15:54 * jrandom रोज़ाना मीटिंग्स शेड्यूल कर देता है 15:54 <jrandom> शानदार 15:54 <@cervantes> धत्तेरे की :) 15:55 <jrandom> ठीक है, 2) syndie के लिए किसी के पास और कुछ है? 15:55 <jrandom> नहीं तो 3) I2P Rufus 0.0.4 पर चलते हैं 15:56 <jrandom> मेल में जो है उसके अलावा मेरे पास जोड़ने को ज़्यादा नहीं — Rawn/defnax, आप लोग यहाँ हैं? 15:56 <+legion> तो 0.0.4 कितना अच्छा है? अगर कोई, तो कौन-सी समस्याएँ बची हैं? 15:57 * jrandom को ज़रा भी अंदाज़ा नहीं है 15:58 <+legion> शायद इसके किसी उपयोगकर्ता के पास उत्तर हो। क्या यह अच्छा और स्थिर लगता है? 15:58 <jrandom> ठीक है, लगता है Rawn और defnax अभी away हैं। अगर किसी के पास I2P Rufus को लेकर कोई प्रश्न/टिप्पणी/चिंता है, तो फ़ोरम पर आएँ और पोस्ट कर दें 15:58 <+legion> धत्, लगता है हमें करना ही पड़ेगा। 15:59 <+legion> 4) पर चलें? 15:59 <jrandom> हाँ, लगता तो यही है। ठीक है, 4) ??? 15:59 <+Complication> दुर्भाग्य से मैंने I2P Rufus आज़माया नहीं है। 16:00 <jrandom> किसी को कुछ और उठाना है? 16:00 <jrandom> (चलो, इसे थोड़ा और खींचते हैं ताकि cervantes और काम कर सके!) 16:00 <+legion> हाँ, कौन-सी दिलचस्प चीज़ें पाइपलाइन में आ रही हैं? 16:00 <+bar> क्या कहीं मैं "restricted routes" के बारे में और पढ़ सकता हूँ? 16:00 <+bar> (मैंने *खोज* लिया है) 16:01 <+legion> शायद हम i2phex पर भी चर्चा कर सकें? 16:01 <jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD 16:01 * cervantes अपना माउस क्लोज़ बटन पर टिकाता है 16:01 <jrandom> उह, #future.restricted 16:02 <jrandom> और how_* पेजेज़ व todo 16:02 <jrandom> (वेब पर) 16:02 <+Complication> हेह, I2P ने लगता है एक build स्किप कर दिया :D 16:02 <+Complication> :D 16:02 <+bar> धन्यवाद 16:02 <+Complication> - public final static long BUILD = 1; 16:02 <+Complication> + public final static long BUILD = 3; 16:03 <jrandom> legion: netDb पर कुछ hacking, performance मॉड्स, restricted routes, streaming में सुधार, eepproxy में सुधार, tunnel में सुधार, आदि। बहुत कुछ, पर अभी कुछ तैयार नहीं 16:03 <+legion> हूँ, अजीब 16:03 <jrandom> i2phex के बारे में कुछ उठाना है, legion? 16:03 <jrandom> Complication: हाँ, जानबूझकर। मैं BUILD = 2 के लिए इसे बढ़ाना भूल गया था 16:03 <+Complication> (ऐसा नहीं कि इससे कुछ फर्क पड़ता है, बस सोच रहा था कि क्या मैंने पहले भी यह दुर्लभ अवसर देखा है :) 16:04 <+legion> वाह, बढ़िया लगता है, धन्यवाद! 16:04 <jrandom> ओह, इससे याद आया... अगर कोई हमारे वेबपेज को नया रूप देने में हाथ डालना चाहे तो बढ़िया होगा 16:05 * jrandom इसके बारे में सोचना नहीं चाहता, पर इसे कभी न कभी करना ही होगा 16:05 <+legion> हाँ, है 16:05 <+legion> क्या इस समय i2phex को नवीनतम phex cvs code पर अपडेट करना फ़ायदेमंद होगा? 16:06 <+Complication> पक्का नहीं, मैंने हाल में Redzara से नहीं सुना 16:06 <jrandom> आख़िरी बार याद है, redzara phex के लिए gregorz के अपडेट का इंतज़ार कर रहा था 16:06 <jrandom> (ताकि हमें काफ़ी साफ़-सुथरा update/extension मिल सके) 16:08 <+legion> अच्छा, फिर i2phex क्यों? 16:08 <+Complication> एहतियातन? 16:08 <jrandom> हम्म? 16:08 <jrandom> i2phex phex का एक extension है 16:08 <+legion> लगता है वे बस phex के साथ एक i2p extension चाहते थे 16:09 <jrandom> extension, मतलब, बहुत कम bits में बदलाव 16:09 <jrandom> उह, s/bits/components/. ताकि जब भी phex devs चीज़ें ठीक करें, हम आसानी से कोड अपडेट कर सकें 16:10 <+legion> अगर ऐसा है तो इसे नवीनतम cvs code पर अपडेट करने में मुझे ज़्यादा काम नहीं लगना चाहिए, हालांकि मुझे पता है लगेगा। 16:10 <jrandom> फ़ोरम में आख़िरी बार मैंने सुना था कि योजना I2Phex और Phex को अलग-अलग applications रखने की है, लेकिन वे अधिकांश कोड साझा करेंगे 16:10 <jrandom> हाँ legion, वह बढ़िया होगा, पर आख़िरी बार सुना था कि Gregor ने अभी Phex में संशोधन पूरे नहीं किए हैं 16:11 <jrandom> (जिसका ही redzara इंतज़ार कर रहा था) 16:11 <+legion> आह, समझ गया 16:11 <jrandom> तो विकल्प है या तो Gregor की मदद करें या मौजूदा I2Phex codebase में बदलाव जारी रखें 16:12 <+legion> फिर अगर मैं इंतज़ार न करूँ और बस नए कोड के साथ i2phex अपडेट कर दूँ, तो redzara के जारी रखने की ज़रूरत नहीं रहेगी 16:12 <jrandom> खैर, पूरी तरह नहीं। 16:12 <jrandom> I2Phex को मौजूदा Phex code पर अपडेट करना बढ़िया होगा, हाँ 16:13 <jrandom> लेकिन जैसे ही Phex developers अपना Phex code अपडेट करेंगे, हम फिर out of sync हो जाएँगे 16:13 <+legion> ठीक है, मैं शायद आज रात या एक-दो दिनों में इसे कर लूँगा। 16:13 <jrandom> शानदार 16:13 <+legion> ठीक है। 16:14 <+legion> सच कहूँ तो मैं i2phex को phex code के साथ हमेशा in sync रखने की नहीं सोच रहा; बस इतना कि cvs में कुछ fixes हैं जिनका i2phex निश्चित रूप से लाभ उठा सकता है। 16:15 <+legion> साथ ही, मैं phex के वे कोड और फीचर्स हटाने की सोच रहा हूँ जिनकी i2phex को ज़रूरत नहीं। 16:15 <jrandom> अच्छा 16:16 <+legion> जहाँ तक नए फ़ीचर्स और उन चीज़ों को ठीक करने का सवाल है जो अभी तक काम नहीं कर रहीं, जैसे upload queues... खैर, मैंने webcaches को काम में लाने पर नज़र डाली है, पर अभी बहुत कुछ करना है। 16:17 <jrandom> बिलकुल। हाँ, phex में पहले gwebcache सपोर्ट काम करता था, पर sirup ने उसे अक्षम कर दिया, क्योंकि शुरू में उसकी ज़रूरत नहीं थी 16:17 <+legion> मैं अंततः i2phex में jeti जोड़ने की योजना रखता हूँ। 16:17 <jrandom> अच्छा 16:18 * jrandom ने कभी jeti इस्तेमाल नहीं किया, और आशा है कि वह एक वैकल्पिक कंपोनेंट ही रहेगा, पर और चीज़ों का समर्थन करना अच्छा है 16:18 <+legion> हाँ, यह वैकल्पिक हो सकता है, उपयोगकर्ता एक jeti2phex डाउनलोड कर सकेंगे ;) 16:19 <jrandom> ठीक है 16:19 <+legion> i2phex के साथ करने को अभी भी बहुत कुछ है, भले ही यह अभी जैसा है वैसा ही बढ़िया काम कर रहा है। 16:20 <+legion> अब तक किसी client को 24/7 कनेक्टेड, अप और रनिंग रखना संभव और आसान है। 16:21 <jrandom> हाँ, मुझे इसके साथ काफ़ी अच्छी सफलता मिली है... "मेरी licensed recordings का बैकअप" 16:21 <+legion> हेह :) 16:22 <jrandom> ठीक है, मीटिंग के लिए किसी और के पास कुछ है? 16:23 * cervantes चीनी गोंग लुढ़काता हुआ लाता है 16:23 <+legion> लगता है मैं कुछ भूल रहा हूँ... हम्म 16:24 <+legion> ओह हाँ, कोई आइडिया कि i2p और i2phex का memory consumption कैसे घटाएँ? 16:25 <+Complication> देखो, TCP transport थोड़ा लेता है 16:25 <jrandom> दोनों को एक ही jvm में चलाया जा सकता है 16:25 <+Complication> अगर वह जाएगा, तो थोड़ा मुक्त होगा 16:26 <@cervantes> अपनी मशीन से कुछ RAM स्टिक्स निकाल दो 16:26 <cat-a-puss> क्या किसी को javolution का अनुभव है, पता है कि यह मदद करेगा? http://javolution.org/ 16:26 <jrandom> (i2p install dir में clients.config क्लाइंट्स लॉन्च करने के लिए main class और arguments परिभाषित करता है) 16:26 <+legion> तो अगर हम दोनों को एक ही jvm में चलाएँ और tcp हट जाए, तो क्या हम इसे 50mb से नीचे ला सकते हैं? 16:27 <jrandom> पता नहीं, legion। यह भी निर्भर करता है कि 50MB से आपका क्या मतलब है। RSS/VSS/आदि 16:27 <jrandom> मैं दोनों को एक JVM में चलाने की सिफारिश नहीं करूँगा, जब तक आप दोनों को हर समय चालू न रखें, क्योंकि एक को बंद करने से दूसरा भी बंद हो जाएगा 16:27 <@cervantes> legion: bandwidth सीमित करना और participants को कैप करना भी मदद कर सकता है 16:27 <jrandom> हाँ, cervantes ने जो कहा 16:28 <cat-a-puss> मुझे लगता है कि यदि हमें पता हो कि किसी प्रकार की वस्तुओं की कितनी संख्या अंततः हम उपयोग करेंगे, तो यह overzealous jvm allocation रोकने में मदद करेगा 16:28 <+Complication> ठीक, यह अलग-अलग allocations बनाता है, जिनका मतलब मैं कभी सच में समझ नहीं पाया 16:28 <jrandom> हाँ, हम उसका कुछ हिस्सा करते हैं, cat-a-puss (देखें net.i2p.util.ByteCache) 16:29 <+Complication> (पर जैसा कहा, Java मेरे लिए बहुत नई चीज़ है) 16:29 <jrandom> मैंने पहले javolution पर नज़र डाली थी, पर लगता है इसमें काफ़ी प्रगति हुई है। मैं इसे फिर देखूँगा 16:30 <cat-a-puss> jrandom:मेरे काम पर कुछ लोग इसे इस्तेमाल करते हैं और खुश हैं, भले ही वे memory allocation की परवाह नहीं करते 16:31 <jrandom> देखो, यह सच में memory नहीं बचाएगा, पर GC churn कम करने में मदद करेगा 16:31 <+legion> मैं व्यक्तिगत रूप से memory allocation की बहुत परवाह नहीं करता, लेकिन कई लोग करते हैं। 16:31 <jrandom> ओह, और यह BSD licensed भी है 16:31 <cat-a-puss> सही 16:31 <jrandom> legion: memory allocation का मतलब performance है 16:32 <+legion> उह, ओह, तो memory consumption 16:33 <+legion> कई लोग uTorrent से बहुत खुश हैं, क्योंकि उसका memory footprint बहुत छोटा है। 16:33 <jrandom> आह, ओह, हाँ। हम बाद में इसे ट्वीक कर सकते हैं, पर चूँकि i2p डिफ़ॉल्ट jvm sizes के भीतर चलता है, मैं बहुत चिंतित नहीं हूँ (क्योंकि हमारे पास ट्वीक करने की काफ़ी गुंजाइश है) 16:34 <jrandom> ठीक है, मीटिंग के लिए किसी के पास और कुछ है? 16:35 <+legion> नहीं, मैं ठीक हूँ... 16:37 * jrandom तैयार होता है 16:37 * jrandom *baf* के साथ मीटिंग बंद करता है