I2P डेवलपर बैठक - 17 जनवरी, 2006

15:40 <jrandom> 0) हाय 15:40 <jrandom> 1) नेट स्थिति और 0.6.1.9 15:40 <jrandom> 2) tunnel निर्माण क्रिप्टो 15:40 <jrandom> 3) Syndie ब्लॉग्स 15:40 <jrandom> 4) ??? 15:40 <jrandom> 0) हाय 15:40 * jrandom हाथ हिलाता है 15:40 <jrandom> साप्ताहिक स्थिति नोट्स पोस्ट किए गए हैं @ http://dev.i2p.net/pipermail/i2p/2006-January/001251.html 15:41 <@cervantes> प्फ्फ, अच्छा है कि I2P NASA से ज्यादा भरोसेमंद है 15:41 <jrandom> हेह 15:41 <tethra> हाहा 15:41 <jrandom> (हालाँकि मैं 20 मिनट लेट हूँ... ;) 15:41 <jrandom> खैर, चलो सीधे 1) नेट स्थिति और 0.6.1.9 पर चलते हैं 15:42 <wmpq> NSA या NASA, इतने अलग तो नहीं हैं, हैं क्या? 15:42 <@cervantes> मैंने I2P कहा था, jrandom नहीं ;-) 15:42 <jrandom> बढ़िया बात, cervantes ;) 15:42 <tethra> बेवकूफ़ी मत करो, jrandom ही I2P है! ;D 15:42 <@cervantes> ओह, मुझे लगा वो सोचने का एक तरीका है 15:42 <wmpq> [redact] 15:43 <jrandom> हेह ठीक है, खैर, 0.6.1.9 जारी हो चुका है, और नेट के 70% ने अपग्रेड कर लिया है (धन्यवाद सबको) 15:43 <Pseudonym> म्म्म्म, लाजवाब नया रिलीज़ 15:44 <+zzz> client tunnel build success <30% पर बना हुआ है 15:44 <jrandom> एंड-टू-एंड थ्रूपुट में बड़े इज़ाफे की बहुत रिपोर्टें नहीं मिलीं, हालाँकि कुछ router T1 लाइनों को पूरी तरह से, उससे भी ज़्यादा, सैचुरेट कर रहे हैं 15:44 <+zzz> ~40% से कम होकर 15:44 <+Complication> बैंडविड्थ सामान्य लग रही है, रिलीज़ से पहले वाले आखिरी CVS से थोड़ा ज़्यादा. Peer काउंट भी कुछ अधिक दिख रहे हैं. 15:45 <jrandom> हम्म, हाँ, zzz, मैं इसके बारे में ज्यादा चिंतित नहीं हूँ, क्योंकि 0.6.2 के लिए सबकुछ पूरी तरह फिर से बनाया जा रहा है 15:45 <+zzz> औसत BW ~12K से ~20K तक बढ़ी है 15:45 <jrandom> 0.6.1.9 को ऐसे peers नहीं चुनने चाहिए जो सहमत होने की अधिक संभावना रखते हों (माने, उच्च क्षमता वाले), बल्कि उन्हें चुनने पर ध्यान देना चाहिए जिनका थ्रूपुट अधिक है 15:46 <+Complication> री-ट्रांसमिशन प्रतिशत (रिलीज़ की रात 7% नोट किया गया था) घटकर 6-पॉइंट-सomething पर आ गया है 15:46 <jrandom> हाँ, जब router 1-300KBps तक पुश कर रहे हैं, तो स्क्यू होना तय है 15:46 <jrandom> हम्म, यह काफ़ी पागल-सी दर है Complication, मैंने तो सिर्फ 2-3% देखा है 15:46 <jrandom> (पर मैं तुम्हारे देखे पर शक नहीं करता) 15:47 <+Complication> मैं अपना आउटबाउंड लगभग पूरा भर रहा हूँ 15:47 <+Complication> (और मेरा मतलब लाइन की क्षमता पूरी तरह भरने से है) 15:47 <jrandom> आह, वही कारण होगा 15:47 <+zzz> GET से पहले अभी भी NULLs मिल रहे हैं जिससे 405 bad method होता है, दर शायद घट रही है, पक्का कहना मुश्किल है 15:48 <jrandom> हाँ zzz, streaming लाइब्रेरी में कुछ चीजें हैं जिन्हें ठीक करना है, लेकिन शायद मैं उस पर 0.6.2 के tunnel सुधारों के बाद ही काम करूँगा 15:48 <jrandom> (लेकिन अगर कोई उससे पहले गहराई से देखना चाहे, तो वह बढ़िया होगा, ज़ाहिर है) 15:49 <jrandom> Complication: अगर आप अपना BW लिमिटर लाइन क्षमता के लगभग 70% तक घटाते हैं, तो क्या फेल्यर रेट वापस किसी उचित स्तर पर आता है? 15:49 <+zzz> मुझे अब भी लगता है कि यह न्यू ईयर से ठीक पहले कोड में गया कुछ था, तो बेहतर होगा कि उस पर देखें, इससे पहले कि हालिया बदलाव भूल जाएँ :) 15:50 <+zzz> पहली बार 29 दिसम्बर को देखा गया 15:50 <jrandom> हाँ zzz, निश्चित रूप से ऐसा ही था। शायद इस बात से जुड़ा कि हम अब timeouts को कैसे मानते हैं। 15:51 <+Complication> jrandom: मैं अभी सच में वही कोशिश कर रहा हूँ :) 15:51 <+Complication> आपके पूछने से कुछ सेकंड पहले ही एडजस्ट किया, लेकिन जल्दी पता नहीं चलेगा, लगता है 15:51 <jrandom> लेकिन उसे साफ़-सुधरा करने के लिए काफी काम करना है, और नया tunnel creation कोड लागू करना अधिक महत्वपूर्ण है (जो tunnel build success दर में काफी सुधार करेगा, और गुमनामी में भी कई तरह के सुधार जोड़ेगा) 15:51 <jrandom> कूल Complication, हाँ, इसे 3-6 घंटे दीजिए 15:51 <jrandom> (पुराने वैल्यूज़ / connections क्लियर होने के लिए) 15:52 <+zzz> ~ 1% - 3% GETs इस समय corrupted हैं 15:54 <jrandom> तो क्या आप सुझाव देते हैं कि streaming लाइब्रेरी के बदलावों को रिवर्ट कर दें (ताकि i2psnark 12-48 घंटों में अपने सभी यूज़र्स को OOM कर दे) और 0.6.2 के tunnel काम के बाद तक streaming लाइब्रेरी के आगे के पुनर्निर्माण को टाल दें, या फिर streaming लाइब्रेरी को रिवैम्प करते हुए 0.6.2 के tunnel काम को एक-दो हफ्तों के लिए आगे खिसका दें? 15:55 <+zzz> बिलकुल रिवर्ट मत करें 15:56 <+zzz> आपकी मर्ज़ी 15:56 <+Complication> ये काफ़ी चालाक-सा बग है, इतना ही कह सकता हूँ 15:58 <jrandom> streaming लाइब्रेरी में और भी बग हैं, तो अगर मैं जुटने जा रहा हूँ, तो मैं सबको एक साथ निपटाना चाहूँगा (क्योंकि बाकी बग स्पष्ट नहीं हैं)। 15:59 <jrandom> दूसरी ओर, अगर पहले tunnel वाले काम पर जाते हैं, तो बैंडविड्थ उपयोग में बड़ा कमी, build success प्रतिशत में बढ़ोतरी, बेहतर गुमनामी, और लाइव नेट पर लोड बैलेंसिंग मॉनिटर करने की बेहतर क्षमता मिलेगी 15:59 <Pseudonym> अगर सर्फ़िंग पर फेल्यर रेट केवल 1-3% है, तो मैं कहूँगा यह इंतज़ार कर सकता है, पर यह सिर्फ मेरी राय है। 16:00 <jrandom> मैं पहले tunnel काम करने की ओर झुक रहा हूँ, क्योंकि उसे डिप्लॉय करने के बाद हम नेटवर्क को पैसिवली मॉनिटर कर सकते हैं जबकि एक्टिवली streaming लाइब्रेरी को रिवैम्प करेंगे 16:01 <jrandom> (मैं Syndie के लिए एडिट/पोस्ट करने हेतु एक GUI भी बनाना चाहूँगा, लेकिन वह दोनों चीज़ें सुलझने के बाद इंतज़ार कर सकता है ;) 16:01 <+Complication> यहाँ भी रेट कुछ ऐसा ही है 16:02 <+Complication> (मेरी eepsite पर) 16:04 <jrandom> ठीक है, अगर आप सब उन दरों में बदलाव पर नज़र रख सकें तो बढ़िया होगा, तब तक मैं tunnel रिवैम्प पर जारी रखूँगा, जिसके बाद streaming लाइब्रेरी रिवैम्प आएगा (दोनों 0.6.2 से पहले लागू होंगे) 16:05 <jrandom> (या, अगर कोई streaming लाइब्रेरी में गहराई से देखना चाहे [या i2ptunnel के साथ कोई अजीब इंटरैक्शन है या नहीं], तो बताइए!) 16:06 <+Complication> jrandom: जिज्ञासावश, क्या एक टेस्ट ऐप के जरिए i2ptunnel को बाहर रखा जा सकता है? 16:07 <+Complication> जैसे, अगर jnymo का sample app जैसी कोई चीज़ को भी nulls मिलें, तो i2ptunnel संदिग्ध कारणों की सूची से बाहर हो जाएगा? 16:07 <jrandom> ऐसा करने के लिए एक पतली (in-VM) I2PSocket implementation जोड़ी जा सकती है, निश्चित रूप से 16:07 <+Complication> क्योंकि, IIRC, उस sample ने streaming लाइब्रेरी को सीधे इस्तेमाल किया था... 16:08 <+Complication> (या लगभग सीधे) 16:08 <jrandom> हाँ, बेशक अगर streaming लाइब्रेरी इस्तेमाल करने वाली कोई चीज़ इसे दोहरा सके, तो i2ptunnel बरी हो जाएगा 16:10 <+Complication> हम्म, जब तक कोई और पहले न कर दे (मैं पहले webcache वाली चीज़ खत्म करने की कोशिश करूँगा) मैं शायद उस तरह HTTP को एमुलेट करने की कोशिश करूँ... 16:10 <jrandom> विक्ड, धन्यवाद Complication 16:10 <jrandom> ठीक है, 1) नेट स्थिति और 0.6.1.9 पर कुछ और? 16:11 <jrandom> अगर नहीं, तो 2) tunnel निर्माण क्रिप्टो पर धीरे-धीरे चलते हैं 16:11 <+Complication> नाह, इससे शायद कुछ उपयोगी न निकले, या मैं आधे रास्ते ही अटक जाऊँ... पर यह संभावना मुझे उत्साहित करती है 16:11 <jrandom> हाँ, Complication, निश्चित ही खोजने लायक है 16:12 <jrandom> (और खोजें उपयोगी होने के लिए हमेशा सकारात्मक परिणाम नहीं मांगतीं :) 16:12 * cervantes ने न्यू ईयर से पहले हुए सोर्स बदलावों में एक "moo" exception देखा....शायद वही मुद्दा है? :) 16:13 <jrandom> ठीक है, ईमेल में एक नया tunnel creation क्रिप्टो स्पेक का संदर्भ है, जो पिछले अक्टूबर में मेलिंग लिस्ट पर toad, Michael और मेरे बीच हुई चर्चा पर आधारित है 16:14 <jrandom> इसे देखिए और अपने विचार बताइए - इसे कुछ समय तक लाइव नेट पर डिप्लॉय नहीं किया जाएगा, क्योंकि पहले कुछ और चीज़ें लागू करनी हैं, लेकिन यह आने वाला है 16:14 <+Complication> "moo" क्या Java के लिए एक रिज़र्व्ड शब्द है? ;P 16:14 <+zzz> 2) पर, मैं स्टेटस मेल में रेफरेंसेज़ की समीक्षा में मदद करूँगा 16:14 <+Complication> tunnel क्रिप्टो विषय पर, क्या आप देखेंगे कि नीचे का पुनर्लेखन सही है या नहीं - मैं बस सुनिश्चित करना चाहता हूँ कि मैंने सही समझा है... 16:14 <jrandom> धन्यवाद zzz 16:15 <+Complication> "प्रत्येक hop अपने रिकॉर्ड से, अपने ElGamal private key का उपयोग करते हुए, reply key निकालकर सभी records को उसी reply key से एन्क्रिप्ट करता है, और इस तरह एन्क्रिप्ट करके tunnel owner द्वारा किए गए डिक्रिप्शन (या कहूँ एन्क्रिप्शन) की एक परत उलट देता है, जिससे अगले प्रतिभागी का record अगले प्रतिभागी के ElGamal private key से पढ़ने योग्य हो जाता है?" 16:15 <jrandom> Complication: हाँ 16:15 <+Complication> या मेरा पुनर्लेखन बिल्कुल ग़लत है? 16:16 <+fox> <jme___> और बहुत ज़्यादा जटिल है, अगर मैं कहूँ 16:16 <jrandom> मुझे लगता है यह सही है, पर हाँ, बहुत सारी उपवाक्य हैं :) 16:16 <+Complication> मुझे इसे समझाने का बेहतर तरीका नहीं सूझा। वैसे भी उस तरह करना काफ़ी मुश्किल था। :P 16:16 <jrandom> (या jme___, क्या आप कह रहे हैं कि एल्गोरिथ्म ही बहुत जटिल है?) 16:17 <+fox> <jme___> नहीं, मैंने डॉक तेज़ी से पढ़ने की कोशिश की और छोड़ दिया क्योंकि बहुत-सी चीज़ों के लिए पहले से ज्ञान चाहिए 16:17 <+fox> <jme___> दूसरी ओर मैंने बहुत कोशिश भी नहीं की :) और काम थे 16:17 <jrandom> Complication: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/java/src/net/i2p/router/tunnel/BuildMessageProcessor.java?rev=HEAD 16:18 <+fox> <jme___> क्या यह peer review औपचारिकता है, या आप वाकई चिंतित/आश्वस्त नहीं हैं ? 16:19 <+Complication> खैर, यह जानना हमेशा अच्छा होता है कि अंदरूनी मैकेनिज़्म क्या कर रहा है... 16:19 <jrandom> मुझे विश्वास है कि यह वही करता है जो मैं चाहता हूँ, लेकिन अगर कोई कोई समस्या देख सके तो मुझे सच में दिलचस्पी है 16:19 <+fox> <jme___> अगर दूसरा है तो मैं समय दे सकता हूँ, पर मेरा ज्ञान पुराना है और ताज़ा नहीं 16:20 <+fox> <jme___> यदि नहीं, तो मैं भरोसा करता हूँ :) 16:20 <jrandom> नोट्स सेक्शन में कुछ प्रश्न हैं - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.notes 16:22 <jrandom> कोई जल्दबाज़ी नहीं, इस नए क्रिप्टो का router में वास्तविक उपयोग होने में शायद एक-दो हफ्ते लगेंगे 16:22 <@cervantes> jrandom: उनमें, hops के बीच एक random delay डालने से प्रदर्शन पर बहुत असर पड़ेगा क्या? 16:22 <@cervantes> क्योंकि टाइमिंग अटैक्स रोकने के लिए वह सबसे समझदार विकल्प लगता है 16:23 <jrandom> यह tunnel creation है, तो देरी से नुकसान नहीं होगा, हालांकि विनाशकारी विफलताओं में lease set का समय से पहले समाप्त होना हो सकता है 16:25 <jrandom> खैर, मुझे नहीं पता वह देरी कितनी प्रभावी होगी। वे काफी मदद कर सकती हैं, या शायद नहीं। लेकिन लाइव tunnels तो वैसे भी उस tunnel पर मिलकर काम करने वाले peers को पकड़ने के लिए blending का इस्तेमाल कर सकती हैं, तो पता नहीं यह कितना मायने रखता है 16:25 <+fox> <jme___> ठीक है, फिर से पढ़ रहा हूँ 16:27 <jrandom> धन्यवाद। ठीक है, कोई जल्दबाज़ी नहीं, पर जब/अगर किसी के विचार हों, तो उन्हें मेरी ओर उछाल दें (या लिस्ट पर, या अपने ब्लॉग पर, आदि) 16:27 <jrandom> ठीक है, 2 पर कुछ और है, या हम 3) Syndie ब्लॉग्स पर बढ़ें? 16:29 <jrandom> (मान लीजिए हम बढ़ गए) 16:29 <jrandom> ठीक है, syndie में नई बढ़िया ब्लॉग्गी चीज़ें हैं, झट से देख डालिए ;) 16:29 <@cervantes> बहुत कूल 16:30 <jrandom> बाएँ तरफ़ के समूह मनमाने URLs के लिंक रख सकते हैं, साथ ही ब्लॉग्स, ब्लॉग्स के भीतर पोस्ट्स, या ब्लॉग पोस्ट्स के अटैचमेंट्स के लिंक भी 16:30 <jrandom> काफी सारे अन्य एन्हांसमेंट्स भी संभव हैं, जैसे प्रति-ब्लॉग या प्रति-टैग स्टाइलिंग, आइकन्स आदि जोड़ना। अगर कोई उस पर काम करना चाहे, तो बढ़िया होगा (और उसका असर बहुत स्पष्ट दिखेगा :) 16:31 <@cervantes> वैसे, comments में परिभाषित external links में भी target URL को title attribute के रूप में सेट होना चाहिए (जैसा आपने लेफ्ट पैनल पर किया है) 16:31 <@cervantes> comments/posts 16:32 <jrandom> आह, अच्छा विचार 16:33 <jrandom> (net.i2p.syndie.sml.BlogPostInfoRenderer method renderLinks(...) :) 16:34 <@cervantes> *scribble* 16:35 <jrandom> Syndie ब्लॉग्स को और क्या चाहिए ताकि वे सूचना-प्रधान eepsites का व्यावहारिक विकल्प दें? ज़ाहिर है, syndie स्थिर कंटेंट है, तो कुछ चीज़ें नहीं कर सकते, पर आप कंटेंट प्रकाशित कर सकते हैं और लोगों को टिप्पणी करने दे सकते हैं 16:36 <jrandom> क्या कोई विशेष कस्टमाइज़ेशन है जो आप करना चाहते हैं? अगर हाँ, तो बताइए 16:37 <DoubtfulSalmon> jrandom: मौजूदा कंटेंट को स्क्रिप्ट के ज़रिए अपडेट करना? 16:37 <@cervantes> तारीख़ के अनुसार आर्काइव 16:37 <jrandom> DoubtfulSalmon: स्क्रिप्ट के ज़रिए? 16:37 <jrandom> cervantes: आह, "5 older entries" लिंक के बजाय एक छोटा कैलेंडर विजेट जैसा? 16:38 <@cervantes> हाँ 16:38 <DoubtfulSalmon> jrandom: मान लीजिए मैं इस फ़ाइल/टेक्स्ट से उस फ़ाइल/टेक्स्ट को बदलना चाहता हूँ। यह कैसे करूँ? 16:38 <jrandom> ठीक है, कूल, हाँ, वह काफ़ी आसान होना चाहिए (अगर कोई HTML तैयार कर दे :) 16:38 <@cervantes> या और सरल, "पिछले महीने की पोस्ट देखें" 16:39 <@cervantes> jrandom: आपको बस 7x6 की एक टेबल चाहिए जिसमें कुछ नंबर हों ;-) 16:40 <jrandom> DoubtfulSalmon: प्रकाशित कंटेंट बदलना एक दिलचस्प दिशा है। यह हर जगह काम नहीं करेगा, क्योंकि इसे Usenet control messages की तरह काम करना पड़ेगा (पुरानी पोस्ट कैंसल करना, आदि) 16:40 <jrandom> DoubtfulSalmon: दूसरी ओर, आप बस नई फ़ाइल/एंट्री पोस्ट कर सकते हैं और बाएँ तरफ़ के लिंक नए फ़ाइल/एंट्री की ओर कर सकते हैं 16:40 <jrandom> (इस तरह, पुराना कंटेंट वहीं रहेगा, पर लोग नए कंटेंट पर जाएँगे) 16:41 <DoubtfulSalmon> jrandom: हाँ, यह ठीक है अगर पुराना कंटेंट वहीं रहे, बशर्ते सबके लिंक नए कंटेंट की ओर चले जाएँ, बिना उन्हें अपना कंटेंट बदलना पड़े। 16:41 <jrandom> इसे लेकर एक पूरा wiki बनाना, मूलतः diffs पोस्ट करके जिन्हें syndie रेंडर करे, संभव है, लेकिन शायद ज़रूरत से ज़्यादा हो 16:41 <jrandom> हम्म, ठीक है, मैं समझ रहा हूँ आप क्या कह रहे हैं 16:42 <jrandom> तो, आप ऐसे लिंक चाहते हैं जिन्हें redirect किया जा सके, न कि कंटेंट के सटीक वर्ज़न पर जाने वाले मौजूदा लिंक 16:43 <jrandom> शायद यह किसी ब्लॉग के bookmark से लिंक करके किया जा सकता है, और सटीक वर्ज़न उस ब्लॉग के मौजूदा bookmarks लोड करके और वे कहाँ इशारा करते हैं, यह देखकर निकाला जाए 16:44 <jrandom> दूसरी ओर, नए वर्ज़न को पुरानी पोस्ट के reply के रूप में चिह्नित किया जा सकता है, ताकि लोग लिंक फ़ॉलो करें तो उस reply तक पहुँचें जो कंटेंट को बदल देता है 16:44 <jrandom> (हालाँकि वह उतना निर्बाध नहीं होगा) 16:44 <DoubtfulSalmon> हाँ: मान लीजिए मैं किसी वर्तमान रडार इमेज का लिंक देना चाहता हूँ, या कुछ ऐसा जो हर 10 मिनट में अपडेट होगा। यह ठीक है अगर कंटेंट पूरे नेट पर नहीं फैलता, लेकिन अगर कोई और मेरी पेज से लिंक करे, तो यूज़र को वर्तमान इमेज दिखनी चाहिए। 16:45 <jrandom> खैर, यह इस पर निर्भर करता है कि वे क्या करना चाहते हैं - क्या वे उस इमेज से लिंक करना चाहते हैं जैसी वह तब थी जब उन्होंने संदर्भित किया, या वे उस सेवा से लिंक करना चाहते हैं जो रीडर के देखने पर इमेज रेंडर करती है 16:45 <+Complication> cervantes: दिन की अजीब चीज़ :D आखिरी पोस्ट यहाँ: http://forum.i2p/viewtopic.php?t=1199&start=15 16:46 <+Complication> ऐसा लगा जैसे वह हमारे किसी और रोबोटिक overlord की हो :P 16:46 <jrandom> लेकिन दोनों कांसेप्ट सपोर्ट करना अच्छा विचार है, और मुझे नहीं लगता इसमें ज़्यादा परेशानी होगी 16:46 <@cervantes> थैंक्स 16:46 <jrandom> हालाँकि इसके लिए SML में एक छोटा एक्सटेंशन चाहिए होगा (e.g. [blog bloghash="ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=" bookmark="radar.webp"]) 16:47 * cervantes फ़ोरम की सुरक्षा बढ़ाएंगे अगर ऐसे बहुत मिलना शुरू हो जाएँ 16:47 <@cervantes> (पहले से जानते हैं इसे कैसे रोकना है) 16:47 <DoubtfulSalmon> jrandom: उन्हें उस का static वर्ज़न (जब तक syndicator ने कंटेंट डिलीट न किया हो) और एक generic URL जो नवीनतम वर्ज़न की ओर इशारा करे, दोनों से लिंक करने में सक्षम होना चाहिए 16:47 <jrandom> (जो ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c= के current meta post में bookmarks देखेगा, और "radar.webp" नाम वाले से exact URI निकालेगा) 16:48 <DoubtfulSalmon> jrandom: क्या अभी इसे कुछ ऐसे किया जा सकता है: "टैग <weird string> में सबसे हालिया एक पोस्ट देखें" 16:48 <jrandom> आह, सही बात - हाँ, किया जा सकता है 16:49 <jrandom> इसे "View most recent post by $author with tag $tag" तक भी सीमित किया जा सकता है 16:49 <jrandom> (ताकि दूसरे लोग इसे स्पूफ न कर सकें) 16:49 <DoubtfulSalmon> तो शायद कोई UI दे दें ताकि यूज़र को अजीब टैग्स वगैरह न देखने पड़ें 16:50 <jrandom> ऊपर यह कैसा दिखता है इसका एक उदाहरण है, हालांकि मेरे पास अभी URI नहीं है... पर हाँ, लिंक्ड टेक्स्ट के चारों ओर एक लिंक है 16:50 <DoubtfulSalmon> मेरा मानना है वह सारी जानकारी URL के रूप में आ सकती है। 16:51 <jrandom> पर सोर्स SML लिखना निश्चित रूप से जटिल है, इसलिए SML बनाने के लिए GUI उपयोगी होगा 16:51 <jrandom> वे SML टैग्स पर attributes हैं, URLs नहीं 16:52 <@cervantes> और JavaScript के बिना SML GUI मुश्किल होगा 16:52 <DoubtfulSalmon> लेकिन आप एक सर्च रिज़ल्ट को बुकमार्क कर सकते हैं, सही? 16:52 <jrandom> सर्च रिज़ल्ट क्या है? 16:52 <jrandom> और बुकमार्क से आपका क्या मतलब है? 16:52 <@cervantes> (या एक ब्राउज़र एक्सटेंशन ;-) 16:52 <jrandom> ओह, ब्राउज़र-साइड बुकमार्क्स, हाँ 16:52 <+Complication> एक फ़िल्टर रिज़ल्ट? 16:53 <jrandom> लेकिन वे बुकमार्क्स आमतौर पर साझा नहीं किए जा सकते 16:53 <DoubtfulSalmon> उह: "get most resent 1 post by X with tag Y" 16:53 <jrandom> (वास्तव में, ज़्यादातर किए जा सकते हैं, पर यह सार्वभौमिक नहीं है, क्योंकि वे URLs हैं, URIs नहीं)) 16:53 <DoubtfulSalmon> हाँ, अच्छा होगा अगर दूसरे ब्लॉग्स भी उनसे लिंक कर सकें 16:54 <jrandom> DoubtfulSalmon: वे कर सकते हैं, SML के साथ 16:54 <jrandom> [blog tag="Y" bloghash="X"] 16:54 <DoubtfulSalmon> ओह गुडी 16:55 <jrandom> cervantes: JavaScript, या XUL, या Java, या कोई और OS-विशिष्ट क्लाइंट ऐप 16:57 <@cervantes> आह कूल, तो आपको स्क्रिप्टिंग या प्लगइन डिपेंडेंसी से परहेज़ नहीं 16:57 <jrandom> (जब हमारी वेबसाइट 0.6.2 के लिए रिवैम्प होगी, तो syndie को निश्चित रूप से एक वेबसाइट मिलेगी जो समझाएगी कि यह पूरा syndie क्या बला है, और यह बर्तन धोने को छोड़कर लगभग सब कुछ कैसे कर सकता है ;) 16:57 <@cervantes> (जब तक यह गरिमापूर्वक degrade करे) 16:57 <jrandom> cervantes: syndie को lynx के साथ functional होना चाहिए, पर rich clients के लिए काफी जगह है 16:58 <jrandom> (s/function/functional/) 16:58 <@cervantes> सही..तो lynx यूज़र्स को SML रेफ़रेंस चार्ट मिलेगा, पर उससे ज़्यादा नहीं 16:58 <jrandom> हाँ, जैसा अभी है 16:58 <jrandom> हालाँकि शायद एक सरल SML, पता नहीं। 17:01 <+Complication> jrandom: क्या यह थोड़ा भी संभव लगता है... कि null बग gzip एन्कोडिंग से जुड़ा हो? 17:01 <+Complication> मैं सोच रहा था कि अपनी eepsite tunnel के लिए gzipping कैसे बंद करूँ... 17:01 <+Complication> या वह पूरी तरह असंभाव्य है? 17:01 <@cervantes> new year से ठीक पहले i2ptunnel में कुछ HTTP compressor वाली चीज़ें जोड़ी गई थीं 17:03 <jrandom> हाँ, संभव है - आप client side पर i2ptunnel.gzip=false से इसे बंद कर सकते हैं (on /configadvanced.jsp)। अभी (atm) मुझे नहीं लगता कि आप i2ptunnelhttpserver में इसे बंद कर सकते हैं 17:03 <+zzz> यह request side पर है जहाँ कोई compression नहीं है 17:03 <+zzz> client के false सेट होने पर server compress नहीं करेगा 17:03 <+Complication> zzz: ओह, सही, वह भूल गया था 17:04 <jrandom> (लेकिन बहुत दिक्कत के बिना आप इसे I2PTunnelHTTPServer में जोड़ सकते हैं [line 310, आदि) 17:04 * Complication मूर्ख है, और इसके लिए माफ़ी चाहता है 17:04 <@cervantes> (या आप एक normal tunnel इस्तेमाल कर सकते हैं) 17:04 <+Complication> आहा, धन्यवाद... 17:05 <jrandom> हम्म, हालांकि जब तक i2ptunnelhttpserver को GET मिलता है, तब तक null पहले से मौजूद होता है 17:05 <+zzz> हाँ, मैंने orion को वापस HTTP tunnel पर करा लिया, जिससे उसके पेजों का लोड समय काफी बेहतर हुआ है क्योंकि अब फिर से compress हो रहे हैं 17:05 <+Complication> मैं किसी तरह पूरी तरह भूल गया कि gzipping तब शुरू होता है जब client और server इसे करने पर *सहमति* देते हैं 17:05 <jrandom> तो यह client side पर हो सकता है, पर निश्चित रूप से server side पर नहीं 17:05 <jrandom> हाँ zzz, अब यह काफ़ी पागलपन की हद तक तेज़ है :) 17:05 <+zzz> यह _request_ side पर है, _response_ side पर नहीं - client या server side में से किसी पर भी हो सकता है 17:06 <jrandom> सही 17:09 <jrandom> ठीक है, 3) Syndie ब्लॉग्स पर किसी और के पास कुछ है? 17:09 <jrandom> यदि नहीं, तो 4) ??? पर चलते हैं 17:09 <jrandom> किसी के पास मीटिंग के लिए और कुछ उठाने को है? 17:10 <cat-a-puss> Complication: Java का gzip stream + I2P tunnels. काम नहीं करता और यह Sun का बग है 17:10 <jrandom> हम्म cat-a-puss? सच में? 17:10 <+zzz> HTTP persistent connections अपडेट: client side लगभग हो गया, server side पर अच्छी प्रगति, बहुत सारा बुलेटप्रूफिंग और टेस्टिंग बाकी, अनुमानित पूर्णता 2-4 हफ्ते 17:10 <jrandom> नाइस1 zzz! 17:11 <cat-a-puss> jrandom: हाँ, मैंने आपसे इसके बारे में बहुत समय पहले बात की थी, मैं शायद इसका लंबा स्पष्टीकरण ढूँढ सकता हूँ कि क्यों, पर शायद बेहतर है कि कहीं दस्तावेज़ कर दें क्योंकि ऐसा करने का कोई कारण नहीं है। 17:12 <jrandom> हम्म, मैं संदर्भ से बाहर हूँ, ठीक-ठीक क्या काम नहीं करता? Sun का बग क्या है? 17:14 <dust> मुझे इस तरह के अजीब लॉग मिलते हैं: 21:21:59.816 WARN [%d0%a2%d1%4f] net.i2p.util.EepGet : ERR: status <html> 17:14 <jrandom> हम्म, दिलचस्प 17:15 <jrandom> कौन-सा ट्रैकर? 17:15 <cat-a-puss> jrandom: जहाँ तक मुझे याद है, Sun हेडरलेस ज़िप्स और एक मैजिक नंबर का उपयोग करता है यह बताने के लिए कि यह zip stream है। लेकिन वह नंबर निगेटिव होता है, तो अगर किसी वजह से आप एक zip stream के भीतर एक और zip stream बना बैठते हैं, तो वह स्ट्रीम से डेटा को unsigned bytes के क्रम के रूप में पढ़ता है और इस तरह मैजिक नंबर किसी और पॉज़िटिव नंबर में बदल जाता है। (शायद मैं कुछ विवरण छोड़ रहा हूँ, पर सार यह है) 17:16 <dust> उदाहरण के लिए OSDevWithCVS_3E.pdf.torrent 17:17 <dust> d8:announce540:http://YRgrgTLGnbTq2aZOZDJQ... 17:17 <jrandom> हम्म, मुझे उसके बारे में कुछ नहीं पता, और मुझे नहीं पता यह i2ptunnel पर gzip stream को कैसे प्रभावित करेगा (अगर ऐसा /होता/ तो सब फेल होते, क्योंकि हम सबकुछ gzip करते हैं) 17:19 <jrandom> ठीक है कूल dust, तो postman का ट्रैकर। हम्म, क्या आप 0.6.1.9 पर हैं dust? 17:20 <cat-a-puss> jrandom: हाँ, मुझे वह समस्या हुए लगभग एक साल हो गया है, तो मुझे अच्छी तरह याद नहीं, और नहीं जानता कि वह 1.5 में ठीक हुई है या नहीं, पर मुझे यह समझने में काफ़ी कठिन समय लगा कि क्यों हर सामान्य प्रकार की स्ट्रीम काम करती थी, लेकिन जैसे ही मैंने उन्हें compressed stream में लपेटा, वे सब फेल हो जाती थीं। 17:20 <dust> हाँ 17:20 <jrandom> cat-a-puss: पिछले साल में हमने I2P पर compression के लिए चीज़ें काफ़ी बदली हैं ;) 17:21 <jrandom> (और मैं व्यक्तिगत रूप से 1.5 इस्तेमाल नहीं करता) 17:21 <jrandom> लेकिन हम उनकी पैकेज्ड स्ट्रीम का इस्तेमाल करने की बजाय, अपना खुद का zip encoding स्पष्ट रूप से करते हैं (पर गुमनामी/कुशलता के कारण, कम्पैटिबिलिटी के लिए नहीं) 17:22 <@cervantes> zzz: रिक्वेस्ट में ठीक कहाँ null होता है? GET के तुरंत बाद? 17:22 <+Complication> उससे पहले, अगर मुझे याद है 17:23 <+fox> <lordalbert> हाय 17:23 <+Complication> साइडनोट: Celeron 300, Sempron की तुलना में retransmission प्रतिशत आधा दिखाता है 17:23 <jrandom> 'लो lordalbert 17:23 <jrandom> कूल Complication, 2-3% उचित है (हालाँकि मैं और कम पसंद करूँगा, ज़ाहिर है) 17:23 <@cervantes> काफी सारे HEAD रिक्वेस्ट वगैरह भेजना दिलचस्प होगा... 17:24 <jrandom> हाँ, लोकल टेस्ट्स का सेट बढ़िया रहेगा, हालांकि IIRC Complication ने कुछ समय पहले यह कोशिश की थी और कोई एरर नहीं आया था 17:24 <+fox> <lordalbert> क्या कोई anonymous ट्रैकर बना सकता है? मैंने कोशिश की पर मुझे समझ नहीं आता tunnel का उपयोग कैसे करें 17:24 <+Complication> cervantes: मैंने इसे उकसाने की कोशिश की थी, अपने 2 नोड्स के बीच रेकर्सिव wget से 17:24 <+Complication> वह होने से पहले मैं थक गया 17:25 <@cervantes> हेह 17:26 <+fox> <lordalbert> 'लो b0unc3 ;) 17:26 <+fox> <b0unc3> lordalbert, :D 17:26 <+Complication> lordalbert: किस हिस्से पर आपको सलाह चाहिए? 17:27 <+Complication> ट्रैकर सेटअप के बारे में, दुर्भाग्य से मुझे नहीं पता। 17:27 <+Complication> I2PTunnel के बारे में, मैं समझाने की कोशिश कर सकता हूँ... 17:27 <+fox> <lordalbert> मैंने BTtracker इंस्टॉल किया है, और वह perfectly काम करता है 17:28 <+Complication> यह भी ध्यान देने योग्य है कि ट्रैकर को *anonymous बने रहने* के लिए, उसे काफ़ी सावधानीपूर्वक config पर चलना होगा 17:28 <+fox> <lordalbert> अब, मैं इसे anonymise करना चाहता हूँ 17:28 <+fox> <lordalbert> तो 17:28 <jrandom> मुझे यक़ीन है कि मीटिंग के बाद हम इसे सुलझाने में मदद कर सकते हैं। आपको generic ट्रैकर्स नहीं इस्तेमाल करने चाहिए, आपको गुमनामी के लिए बने ट्रैकर की ज़रूरत है 17:28 <+fox> <lordalbert> मैंने अभी एक i2ptunnel बना लिया है 17:29 <jrandom> (उदा. bytemonsoon मॉडिफिकेशन, जो आपको किसी भी I2P ट्रैकर पर, या CVS में मिल जाएगा) 17:29 <+fox> <lordalbert> अब, मैं जानना चाहता हूँ कि इस tunnel का उपयोग कैसे करूँ। मैंने एक tunnel बना ली है 17:29 <jrandom> ठीक है, मीटिंग के लिए किसी के पास और कुछ है? 17:30 <jrandom> lordalbert: http://localhost:7657/i2ptunnel/ आपको अपने वेबसरवर/ट्रैकर की ओर इशारा करता हुआ 'http server tunnel' बनाने देगा, लेकिन आपका ट्रैकर तब तक काम नहीं करेगा जब तक उसे anonymous उपयोग के लिए मॉडिफाई न किया गया हो 17:30 <+fox> <lordalbert> jrandom, मुझे कौन-सा ट्रैकर इस्तेमाल करना चाहिए? 17:31 <+Complication> मुझे लगता है postman, ByteMonsoon का संशोधित वर्ज़न उपयोग करता है 17:32 <jrandom> i2p-bytemonsoon को anonymous उपयोग के लिए संशोधित किया गया है - http://i2p-bt.postman.i2p/ पर एक zip उपलब्ध है, और http://dev.i2p.net/cgi-bin/cvsweb.cgi/bytemonsoon/ में CVS है, पर मुझे इसके बारे में बहुत पता नहीं 17:32 <+fox> <lordalbert> क्या bytemonsoon पुराना/अप्रचलित नहीं है? 17:32 <jrandom> अगर यह काम करता है, तो यह obsolete नहीं है। यह काम करता है 17:33 <+fox> <lordalbert> ठीक है XD 17:33 <jrandom> बहुत से ट्रैकर्स मौजूद हैं, और अगर कोई डेवलपर उसे सुरक्षित और anonymous तरीके से काम करने के लिए संशोधित करना चाहे, तो बढ़िया होगा 17:33 <+Complication> शायद पुराना हो... पर निश्चित रूप से IPs की जगह destkeys के साथ काम करता है... 17:33 <+Complication> सुरक्षा और लीक-प्रूफनेस के बारे में नहीं कह सकता 17:34 <jrandom> (इसे duck आदि ने anonymity और सुरक्षा के लिए संशोधित किया था) 17:34 <+Complication> पर यह काफी समय से चल रहा है, और संभलता दिखता है... 17:35 <jrandom> ठीक है, अगर मीटिंग के लिए और कुछ नहीं है... 17:36 * jrandom समाप्त करता है 17:36 * jrandom *baf*S मीटिंग बंद करता है