I2P डेवलपर बैठक - 30 दिसंबर, 2003

<jrandom> 0) हाय <jrandom> 1) router की स्थिति <jrandom> 2) i2ptunnel <jrandom> 3) im <jrandom> 4) 0.3 योजनाएँ <jrandom> 5) समय समकालिकरण <jrandom> 6) ??? <jrandom> हेलो mihi, polo <polo> हेलो ! <mihi> हाय jrandom <jrandom> 0) हाय <jrandom> :) <rsk> हाय <i2p> <duck> हाय <jrandom> 1) router की स्थिति <jrandom> 0.2.3.3 आ गया है, और लगता है कि यह काम कर रहा है <jrandom> अभी बहुत कुछ करना बाकी है, ज़ाहिर है <jrandom> पर यह 0.2 की आख़िरी रिलीज़ होनी चाहिए <jrandom> 0.3 में peer profiling जोड़ रहे हैं ताकि routers खराब routers से बच सकें <jrandom> (और 0.3.1 में transports (परिवहन प्रोटोकॉल) का एक रिवैम्प है) <jrandom> hola Ophite1 <Ophite1> हेया. <rsk> तो 0.3 के लिए और ओवरहेड? <jrandom> हाँ और नहीं <jrandom> इसमें peer testing होगा, पर यह ज़्यादा फोकस्ड होगा <rsk> क्या path selection के साथ गति बढ़ेगी? <jrandom> हाँ <jrandom> वे 'liveliness' कैलकुलेटर हैं, और नए latency और throughput कैलकुलेटर भी जोड़े जाएंगे <jrandom> साथ ही लोग अपने विशेष peers के लिए अपनी पसंद को ट्वीक कर पाएँगे <jrandom> जैसे, अगर आप जानते हैं कि आप peer X को peer Y पर प्राथमिकता देना चाहते हैं, तो आप उन्हें कुछ रैंडम पॉइंट्स का वेटिंग बोनस दे पाएँगे <mihi> क्या एक clean shutdown होगा? *g* <jrandom> यह वाकई अच्छा सवाल है mihi <jrandom> i2p उस बिंदु पर आ रहा है जहाँ उसे एक admin interface चाहिए। <jrandom> सबसे लंबा Job जो इसके संचालन को रोक रहा है वह GenerateStatusConsoleJob है <jrandom> जो अब 4-6 सेकंड तक ले सकता है <jrandom> (बाकी सबको रोकते हुए) <jrandom> उसे async और on-demand करना होगा। <jrandom> पर मैं web listener / आदि नहीं लिखना चाहता। <jrandom> शायद उल्टा - एक servlet जो router शुरू करे और उससे संवाद करे <mihi> आपको पूरा web server नहीं चाहिए। बस जब आपको GET दिखे, तो अपना डेटा लौटाएँ। <jrandom> सही <jrandom> आप सही हैं, वह चीज़ 0.3 में भी होनी चाहिए। <mihi> और जब कुछ और दिखे (जैसे SHUTDOWN), जो ठीक लगे वह करें। बेशक सिर्फ localhost से ;) <jrandom> अरे, चलो ना <mihi> तब कोई एक अच्छा admin प्रोग्राम बना सकता है <jrandom> सही <mihi> आपके पास कुछ triggers by files थे, है न? क्या वे कहीं डॉक्युमेंटेड हैं? >>> mihi [~mihi@ags9-d9ba536a.pool.mediaWays.net] ने jrandom से PING 1072820995 का अनुरोध किया <jrandom> वे IDN में थे, खुद router में नहीं <jrandom> पर वह एक अच्छा तरीका हो सकता है <jrandom> यह बेहद्द आसान सिस्टम है <jrandom> अच्छा आइडिया, उसी रास्ते चलते हैं <jrandom> (और मैं बस वही code reuse कर सकता हूँ :) <i2p> <duck> यह जादुई filestuff plan9 जैसा लगने लगा है <jrandom> lol <mihi> पर file triggers के लिए polling चाहिए <jrandom> सही mihi, हर 30s में एक डायरेक्टरी पढ़ना इतना बुरा नहीं है <mihi> पर एक ServerSocket#accept सस्ता है। <mihi> क्योंकि यह समय नहीं खाएगा। (मान लें एक अच्छा OS) <mihi> ठीक है, file triggers कुछ न होने से बेहतर हैं, ज़रूर। <jrandom> server socket remote admin की अनुमति देगा <jrandom> (जहाँ उचित हो) <jrandom> पता नहीं। <jrandom> सोचने की बात है। <jrandom> (या अगर कोई इस पर कूद कर कोड करना चाहे... :) <mihi> और server socket routerConsole भी डिलीवर कर सकता है। <jrandom> सही <jrandom> ठीक, 2) i2ptunnel <jrandom> :) <jrandom> i2ptunnel अभी भी शानदार है, और लगता है कि हम इसे नियंत्रित करने के लिए एक socket आधारित API जोड़ना चाहते हैं <i2p> <anon> aum की ic2cp2pc योजनाएँ अभी बंद हैं? <jrandom> हाँ, ci2cp पानी में डूब गया है, उसे I2PTunnel को नियंत्रित करने के लिए socket आधारित API से बदल दिया गया है <jrandom> मुझे लगता है मैं अगले कुछ दिनों में वह API लगा पाऊँगा, ताकि वह impl पर churn करना शुरू कर सके <mihi> बस एक socket इस्तेमाल करो, in.readLine() बनाओ और उस लाइन को runCommand() में फीड करो ;) <rsk> API i2p को क्या देती है? <jrandom> लगभग वही, mihi (सिवाय इसके कि यह परिणामों को फॉर्मैट करता है और मानक तरीके से उन्हें वापस भेजता है) <mihi> एक उचित "logger" के साथ ताकि commands वापस भेजे जा सकें। <mihi> s/commands/results/ <jrandom> rsk> यह application डेवलपर्स को i2p पर client और server sockets बनाने देता है, बिना I2CP's encryption आवश्यकताओं से निपटे <jrandom> सही सही <jrandom> i2ptunnel में /does/ एक ओवरहेड होता है उन स्थितियों में जहाँ बहुत सारे i2ptunnels हैं <jrandom> JVM चाहे कुछ भी हो <jrandom> i2ptunnel clients जिनसे संपर्क किया जाता है, प्रति client एक नया destination (गंतव्य पहचान) बनाते हैं, और जैसे-जैसे local destinations की संख्या बढ़ती है, router का प्रदर्शन बहुत खराब हो जाता है। <rsk> आह <jrandom> यह हमारे एन्क्रिप्शन के काम करने के तरीके से जुड़ी नेटवर्क की anonymity की जरूरतों के कारण है <jrandom> उन applications के लिए जो सिर्फ़ किसी peer तक एक-दो tunnel खोलना चाहते हैं, यह नया API जबर्दस्त होगी <jrandom> पर उन applications के लिए जिन्हें बहुत सारे peers से बात करनी है, I2CP ही सही रास्ता है। <jrandom> (क्योंकि वह एक single destination है, i2cp द्वारा multiplexed) <jrandom> मुझे लगता है यह पुराने TCP बनाम UDP संतुलन जैसा है, एक तरह से <jrandom> mihi> क्या आपके पास कोई विचार हैं, या i2ptunnel के भविष्य के लिए कुछ आइडियाज? <rsk> IP over i2p, या VPN वाला काम कैसा चल रहा है? <mihi> jrandom: कोई एक अच्छी streaming API लिखे, और फिर i2ptunnel उसे इस्तेमाल करे। <mihi> naming server के लिए भी वही। <mihi> अगर ऊपर की चीजें कोई नहीं करता, तो शायद कुछ sequence numbers जोड़ दें। <mihi> जिसका मतलब एक incompatible बदलाव होगा। <jrandom> incompatible बदलाव बुरे नहीं हैं, हम अभी विकास के शुरुआती दौर में हैं <jrandom> (अगर हम IDs का आकार भी प्रति साइड दो या चार bytes तक बढ़ा सकें?) <mihi> streaming API फिर भी एक incompatible बदलाव होगी। और अगर i2p काम करता, तो हमें sequence numbers की ज़रूरत नहीं। <jrandom> rsk> होल्ड पर, जब तक कोई उसके साथ भागने का समय निकाल पाए? ≡ rsk/#i2p सोचते हैं incompatible chages सबसे अच्छी किस्म हैं <jrandom> सही mihi <mihi> ID अभी 3 byte होना चाहिए, तो 2 bytes तक क्यों *increase* करें? <jrandom> mihi> दरअसल, मैं धीरे-धीरे mode=GUARANTEED को deprecate करना चाहूँगा और उसे streaming API में लागू करना चाहूँगा ≡ mihi/#i2p भी <jrandom> i2p = IP छोड़ते हुए, न कि TCP या UDP <jrandom> कसम, काश दिन में 14 घंटे और होते। <mihi> सिर्फ़ 14? ;) <jrandom> ;) <jrandom> क्या 3 byte ids कनेक्शन के दोनों तरफ से derived नहीं होते? या शायद मैं बस कन्फ़्यूज़ हूँ <mihi> हर साइड के पास 3 bytes का एक ID होता है, हालांकि, एक समय में केवल एक ही भेजा जाना चाहिए। <jrandom> शायद मैं streaming API लागू करूँ, GUARANTEED निकाल दूँ, और अगला वही socket controller जोड़ूँ। <jrandom> आह ठीक <mihi> देखें /apps/i2p/i2ptunnel/java/src/protocol.txt <jrandom> सही सही <mihi> btw, वह फ़ाइल *वहीं* किसने misplace की? ≡ jrandom दोष eco पर डालते हैं ;) <jrandom> रुको, नहीं, तुमने ही उन्हें वहाँ रखा था <jrandom> है न? <jrandom> ओह रुको, नहीं मैंने उन्हें import किया था ≡ jrandom खुद को बेवकूफ होने के लिए दोष देते हैं। <jrandom> (ला ला ला) <jrandom> धत्। ठीक है, हाँ, streaming API और socket controller पर काम करने से मुझे peer testing / profiling / selection मैनिफ़ेस्टो पर सोचने का समय मिलेगा <jrandom> मैं उसे कुछ दिनों में comments के लिए पोस्ट कर दूँगा <jrandom> (और यह मेरा सिर router से बाहर ले आएगा। variety++) <jrandom> mihi> i2ptunnel पर और कुछ? <mihi> मुझे नहीं पता <jrandom> कूल <jrandom> (इन बातों पर समय देकर शामिल होने के लिए फिर से धन्यवाद, मुझे पता है आप fiw और बाक़ी में व्यस्त हैं) <jrandom> ठीक है, thecrypto यहाँ नहीं है, पर वह IM app पर प्रगति कर रहा है। <jrandom> (वह एजेंडा आइटम 3 है) <jrandom> 4) 0.3 योजनाएँ <jrandom> 0.3.0 ~= peer profiling वाली चीज़ें, और अब इसमें i2ptunnel के लिए streaming API और वह socket controller भी शामिल होगा <jrandom> लेकिन, अगर आप अंदाज़ा नहीं लगा पाए, तो यह 1 जनवरी को रिलीज़ नहीं होने वाला <jrandom> 15 जनवरी एक बाहरी संभावना है। देखते हैं चीज़ें कैसे चलती हैं। <jrandom> 0.3.1 एक पूरे महीने का काम नहीं है, तो शायद उसे टालने की ज़रूरत नहीं पड़ेगी। <jrandom> इसके अलावा, roadmap अभी भी काफ़ी हद तक ट्रैक पर है और दर्शाता है कि हम कहाँ जा रहे हैं <jrandom> 5) समय समकालिकरण <jrandom> एक नया faq http://wiki.invisiblenet.net/iip-wiki?I2PTiming पर पोस्ट किया गया है <jrandom> mihi, वहाँ चौथे विकल्प (i2p के अंदर अपना टाइमिंग बनाना) के बारे में आपका एक सुझाव था? <jrandom> हाय brawl <mihi> हाँ। ∙φ∙ brawl अब eco_ के नाम से जाना जाता है <eco_> हाय दोस्तों <jrandom> ओह हेया eco <mihi> आपको 3 random नोड्स से कनेक्ट करना चाहिए और avg time और local time के बीच का diff याद रखना चाहिए। <jrandom> हमने अभी streaming API / tunnel API पर चर्चा की <mihi> और फिर अपना खुद का getTimeMillis hack करें जो उसे सही करे। <Ophite1> mihi: नहीं, ऐसा नहीं करना चाहिए। <jrandom> mihi> तो अगर एक अटैकर गलत समय वाले 1000 नोड्स बनाता है, तो सब मुश्किल में पड़ जाते हैं <jrandom> (क्योंकि avg बीच में रैंडमली skew हो जाएगा) <mihi> अगर एक अटैकर 1000 नोड्स बनाता है, तो वैसे भी सब मुश्किल में पड़ जाते हैं...? <rsk> क्या वह स्वयं-संशोधित नहीं होगा? <Ophite1> mihi: ठीक है, 3। <jrandom> नहीं, हमें उसे संभालने में सक्षम होना चाहिए mihi। <mihi> ठीक है, तो केवल avg तभी उपयोग करें, जब मानक विचलन 1sec से कम हो। <rsk> अगर सबके पास एक जैसा समय है तो आप ठीक हैं, भले ही वह समय गलत हो, है न? <jrandom> rsk> अगर सारे 1000 नोड्स सिंक में हों, पर क्या हो अगर वे सब रैंडम हों <mihi> केवल वे समय उपयोग करें जो काफ़ी पास-पास हों। अगर नहीं, तो 3 नए नोड्स लें। <jrandom> mihi> सही, हम NTP लागू कर सकते हैं (जो मूलत: वही करता है जो आप कहते हैं, candidate averages की एक शृंखला उपयोग कर क्रमशः सही समय के करीब पहुंचना <mihi> पर हमें हर चीज़ (जैसे ping latencies) की परवाह करने की ज़रूरत नहीं, जैसा ntp करता है। <Ophite1> अगर हम ऐसा नहीं करें, mihi, तो समय धीरे-धीरे पीछे की ओर रेंगता रहेगा। ≡ mihi/#i2p सोचते हैं कि यह उपयोगकर्ताओं को अपना समय अलग-अलग सेट करने देने से बेहतर है। <jrandom> तो जो भी उन skewed नोड्स में से 3 को रैंडमली चुनता है, उसे अपने ही private नेटवर्क पर भेज दिया जाएगा? <jrandom> उस तीसरे विकल्प का क्या - <jrandom> i2p में एक कॉम्पोनेंट हो जो किसी वास्तविक NTP सर्वर से NTP या SNTP के जरिए जाँच करे <mihi> अगर आपके netDB में सिर्फ़ skewed notes हैं, तो आप भी उस private net पर ही हैं... <jrandom> पहिया फिर से आविष्कार करने के बजाय <Ophite1> मुझे वह कुछ हद तक पसंद है... <Ophite1> NTP साइन नहीं होता, यह MITM अटैक के अधीन है। <Ophite1> या, मान लीजिए, time.nist.gov के लिए DNS cache poisoning <jrandom> सही Ophite1, हालांकि 200,000+ SNTP या NTP hosts के साथ, वह हमला करने के लिए बड़ा सेट है। <jrandom> हम निश्चित रूप से time.nist.gov से sync नहीं करेंगे। <Ophite1> i2p से NSA के time server तक कनेक्शन कुछ भौहें उठा सकते हैं, हैं ना? :) <jrandom> और अगर कोई time.nist.gov पर हमला करता है, तो हर जगह सब प्रभावित होते हैं <jrandom> हेह <mihi> तब हम दोनों को मिलाएँ। एक "वास्तविक" ntp server और अपने पड़ोसी से पूछें। अगर दोनों वही कहें, तो ठीक है। <jrandom> तो और भी /more/ code ;) <jrandom> पर हाँ, वह वाजिब है। <Ophite1> यह दिलचस्प है। और अगर वे नहीं मिलते? <Ophite1> कोई और ntp server चुनें? <jrandom> उस peer को अस्वीकार करें। <mihi> दूसरा ntp server और दूसरा peer आज़माएँ। <mihi> जब तक मैच न हो जाए। फिर सभी prev peers को अस्वीकार करें। ≡ mihi/#i2p jrandom से धीमा टाइप करते हैं :( <Ophite1> एक निश्चित threshold के भीतर मैच, मान लें 1sec? <jrandom> 1s अच्छा रहेगा। <jrandom> peers को ~30s तक स्वीकार करना (lag से निपटने के लिए) <Ophite1> HEAVILY LADEN connections पर 1 sec ठीक है? <jrandom> syncing के लिए 1s, comm के लिए 30s। <Ophite1> मैंने देखा है कि DSL पर latency 5 सेकंड तक पहुँच जाती है जब आप उस पर बुरी चीजें करते हैं। <jrandom> tcp या udp के साथ? <Ophite1> लेकिन तब, उस स्थिति में, वह host वैसा नहीं होगा जिससे आप समय sync करना चाहेंगे ;) <jrandom> सही <Ophite1> udp. <jrandom> हम्म 'k <Ophite1> आपने सोचा होगा कि वह drop हो जाता :) <i2p> <duck> मुझे लगता है समस्या ज़्यादा यह बताने की है कि कोई समस्या है <jrandom> duck> यह सही है। <i2p> <duck> बड़े logs देखने के बाद ही उन्हें दिखता है कि उनकी clock off है (अगर उन्हें मिले तो) <Ophite1> शायद। कुछ हद तक। <i2p> <duck> या कि port पहले से bound है <jrandom> एक admin interface अच्छा रहेगा। <i2p> <duck> दुनिया बेहतर है जब सब NTP इस्तेमाल करते हैं जो उनके local stantrum (sp) 2 server से connected है CTCP Cloaking is now [On] <jrandom> शायद हम 1.0 से पहले ढेर सारी cleanups और end user चीज़ों के साथ 0.4 रिलीज़ करें? <jrandom> सही (stratum) <i2p> <duck> सिर्फ़ windows clients में वह होने की संभावना कम है <i2p> <duck> पर वे भी स्थिर होने की संभावना कम हैं <jrandom> Windows में NTP है <i2p> <duck> तो किसे परवाह है <Ophite1> duck: Windows XP और Windows Server 2003 में NTP शामिल है। <jrandom> Unix की तुलना में भी बहुत आसान <Ophite1> डिफ़ॉल्ट रूप से time.windows.com से sync'ed (iirc). <jrandom> दूसरों के लिए drop down विकल्पों के साथ <Ophite1> यह Windows Product Activation का आवश्यक भाग है। <Ophite1> समय पता न हो तो expire नहीं हो सकता :) <jrandom> हेह <mihi> मेरी यूनिवर्सिटी में कोई विकल्प नहीं... सारी clocks 1 घंटे से 5 घंटे तक गलत हैं। पर मुझे वहाँ i2p चलाने की अनुमति शायद नहीं भी हो... <Ophite1> mihi: i2p को ऐसे हालात में खास तौर पर कड़ी कोशिश करनी चाहिए कि वह काम करे... <jrandom> mihi> शानदार! आप hidden operation टेस्ट करने में मदद कर सकते हैं :) <jrandom> एक बात और, मैं इस गर्मियों में कुछ यात्रा करने वाला हूँ <jrandom> मैं शायद ऑफलाइन रहूँगा, अपने लैपटॉप के बिना। <i2p> <duck> sidethought: ntp.duck.i2p :) <Ophite1> इसे ऐसे देखो: Brianna Kazaa एक कूल नया anonymous filesharing client डाउनलोड करती है जो उसकी सबसे अच्छी दोस्त ने बताया कि बहुत कूल है और आपको लोगों से चुपके से चैट करने देता है वगैरह। क्या हम उसे बताएँगे कि उसे अपनी clock 30 सेकंड के भीतर set करनी होगी (वह कहाँ से लाएगी?)? या हम चाहते हैं कि यह बस काम करे? <jrandom> पर मैं सुनिश्चित करूँगा कि मैं सिर्फ public terminals के साथ भी I2P पर रह सकूँ। CTCP Cloaking is now [Off] <jrandom> सीधी बात Ophite1. बस काम करे (गीक्स के लिए docs के साथ) <jrandom> duck> bootstrap ;) <jrandom> और i2p को root की /not/ ज़रूरत होगी। <Ophite1> यही मेरी बात है। <Ophite1> jrandom: क्या आप ऐसे बॉक्स पर router चलाएँगे जहाँ आपके पास root न हो? <jrandom> तो हाँ, विकल्प 3 और 4 का मिश्रण <Ophite1> विकल्प 3.5 मुझे कूल लगता है ;) <jrandom> Ophite1> मैं तो सौ चलाऊँगा :) <mihi> विकल्प 3.1415926... <jrandom> (और अगले लैब में जाऊँगा, सौ और चलाऊँगा) <Ophite1> ओहो। Pie. स्वादिष्ट.;) <Ophite1> jrandom: मैंने कहा जहाँ आपके पास root नहीं है। Amateur. :) <jrandom> lol <jrandom> तो हम मूलतः वहीं देख रहे हैं। <jrandom> जब तक time वाली चीजें लागू नहीं होतीं, सबको विकल्प 1 या 2 इस्तेमाल करना चाहिए। <jrandom> विकल्प 2 के लिए, अगर कोई कुछ docs लिख दे, तो आभारी रहूँगा <Ophite1> फ़िलहाल यह स्वीकार्य है क्योंकि हम अभी Brianna Kazaa इत्यादि के लिए Not Yet Ready हैं ;) <mihi> jftr: मैं "hidden operation" टेस्ट नहीं करूँगा। मेरा univ अकाउंट पहले ही एक बार disabled हो चुका है और मैं नहीं चाहता कि वह फिर से ब्लॉक हो... <Ophite1> mihi: आप वह सबसे अच्छा टेस्ट हैं जो हमारे पास हो सकता है। <jrandom> Ophite1 > टेस्ट के लिए नहीं। <jrandom> 'k mihi, हम कोई रास्ता निकालेंगे, और जैसे ही यह तैयार होगा आप इसे इस्तेमाल कर पाएँगे। <Ophite1> ठीक है, शायद टेस्ट नहीं। कुछ यूनिवर्सिटीज़ इतनी सख़्त होती हैं कि सिर्फ ब्लॉक करने के बजाय निकाल भी देती हैं। <Ophite1> मैं USA की सबसे anti-filesharing pro-RIAA यूनिवर्सिटी में किसी को जानता हूँ। वह 2gbit dumpsite चलाता है। <jrandom> lol nice <Ophite1> मैं समझता हूँ कि बहुत, बहुत कम लोग इतने हिम्मती होते हैं। <jrandom> ठीक है, समय समकालिकरण के लिए इतना ही। <jrandom> eco_> हाय। कोई bt वाली चीज़ जिस पर बात करना चाहते हो? {या अगले हफ्ते तक रख लें} <Ophite1> पर ध्यान रहे भविष्य में इंटरनेट का ज़्यादातर हिस्सा शायद यूनिवर्सिटी/कॉर्पोरेट बनने जा रहा है। i2p बैन हो सकता है। i2p को बड़े ISPs द्वारा वाकई abuse माना जा सकता है। i2p को फिर भी काम करना होगा। <Ophite1> उस कोण पर मेरे पास कुछ दिलचस्प आइडियाज हैं जो मैं भविष्य में पेश करूँगा। <jrandom> word <Ophite1> (transport) <rsk> i2p को बड़े ISPs abuse मानते हैं, अपना कॉन्ट्रैक्ट पढ़ो <Ophite1> rsk: एक distributed proxy cache चलाना? <rsk> कोई भी 'server' चलाना <Ophite1> rsk: जब तक कि वह SMTP या WWW को relay न करे, नहीं। <jrandom> किसी भी तरह की services चलाना <jrandom> सही <Ophite1> rsk: hehe, मेरे पास उसका एक समाधान है ;) <eco_> jrandom: संक्षिप्त अपडेट दे सकता हूँ <jrandom> मंच आपका :) <eco_> मैं java-based bittorrent client snark (www.klomp.org/snark) को i2p से परिचित होने के लिए पोर्ट कर रहा हूँ <eco_> पहला पोर्ट i2ptunnel के ऊपर चलता है, सीधे java classes को कॉल करता हुआ <eco_> वर्तमान स्थिति: 2 peers के साथ काम करता है, > 2 के साथ चीजें गड़बड़ा जाती हैं, tunnels साफ़ नहीं होते, तो रीस्टार्ट करना दर्दनाक है <eco_> ETA: इस वीकेंड ≡ eco_/#i2p महसूस करते हैं कि इसे > 2003 माना जा सकता है <jrandom> w00t! ≡ jrandom time.nist.gov को hack करते हैं <eco_> एक "वास्तविक" पोर्ट शायद tunnels का ओवरहेड कम कर देगा, पर वह अगला कदम है <jrandom> कूल ≡ eco_/#i2p mc jrandom को मंच वापस देते हैं <jrandom> 'k, मुझे लगता है बस इतना ही था <jrandom> 6) ??? <jrandom> किसी के पास और कुछ है? ≡ eco_/#i2p अब तक jrandom cs द्वारा किए गए अच्छे काम के लिए धन्यवाद व्यक्त करना चाहेंगे <eco_> और कि sleep का homo sapiens के लिए कुछ उपयोग है, हालांकि jrandom इसे गलत साबित करते दिखते हैं <jrandom> ;) <jrandom> i2p काफ़ी भरोसेमंद होने तक यहाँ मीटिंग करने के बारे में आप लोगों के क्या विचार हैं, iip के बजाय? <jrandom> व्यक्तिगत रूप से, मैं हर हफ्ते बैठकों के तहस-नहस होने से थक गया हूँ। <i2p> <anon> lilo बेकार है! <eco_> यहाँ आने से हम शायद कुछ लोगों को बाहर कर रहे हैं <jrandom> कर रहे हैं, मुझे पता है। <jrandom> अगर हम iip<-->यहाँ एक bridge पा सकें <i2p> <duck> IIP हर दिन ppl को बाहर कर रहा है <jrandom> वह अच्छा होगा। <jrandom> सही। <jrandom> iip, दुर्भाग्य से, एक भरोसेमंद development community के लिए अनुपयोगी है। <i2p> <duck> http://banaan.zeelandnet.nl/open/changate.html <i2p> <duck> यही वह code है जिस पर eyeKon आदि आधारित है <jrandom> और जबकि मुझे अकेले कोडिंग करने जाना अच्छा लगता है, आप सब वाकई अच्छे आइडियाज लेकर आते हैं और अच्छा काम करते हैं जो आवश्यक है ≡ rsk/#i2p एक windows update script लिख रहे हैं <i2p> <duck> सैद्धांतिक रूप से यह 3 servers से कनेक्ट हो सकता है और हर एक का mirror कर सकता है <jrandom> word duck, शायद मैं i2p.dnsalias.net पर एक चलाने की कोशिश करूँगा <jrandom> नर्क जैसी ping flood ;) <eco_> duck.i2p पर irc आज काफ़ी अच्छा था, iip से बेहतर <jrandom> सहमत <jrandom> हालांकि उसने मुझे कुछ बार drop किया। <jrandom> शायद अगले हफ्ते यह ज़्यादा भरोसेमंद होगा <eco_> यह आपके हाथ में है :-) <jrandom> भरोसेमंदी शायद 0.3 तक नहीं सुधरेगी, जो ~2 हफ्ते दूर है <jrandom> (1 हफ्ता tunnel/streaming चीज़ों के लिए, 1 हफ्ता peer profiling / testing के लिए) <jrandom> फिर जो भी बग्स वह लाएगा :) <jrandom> हालांकि मुझे कहना चाहिए कि मैं कल रात aum से audio stream करने के लिए वाकई उत्साहित था <jrandom> और ardvark 42 मिनट तक बिना buffering के stream कर पाया! <jrandom> तो शायद हम पर्याप्त भरोसेमंद हो सकें <jrandom> (मेरा local router सिर्फ phttp है, जो शायद थोड़ा कारण है) <jrandom> ठीक है, किसी के पास और कुछ है? <i2p> <duck> कुछ सूझ नहीं रहा ≡ eco_/#i2p को भी नहीं ≡ jrandom समेटते हैं... ≡ jrandom मीटिंग को *baf* करके बंद करते हैं