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

13:04 <jrandom> 0) हाय 13:04 <jrandom> 1) नेट स्थिति 13:04 <jrandom> 2) 0.5 13:04 <jrandom> 3) i2pmail.v2 13:04 <jrandom> 4) azneti2p_0.2 13:04 <jrandom> 5) ??? 13:04 <ant> <duck> (क्रिप्टो की बातें मेरे कानों के ऊपर से उड़ती हुई जाने की आवाज़) 13:04 <jrandom> :) 13:04 * jrandom हाथ हिलाता है 13:04 <cervantes> हैलो 13:04 <jrandom> आप भी अपने कानों के ऊपर से उड़ती क्रिप्टो बातों की आवाज़ सुन सकते हैं! साप्ताहिक स्थिति नोट पोस्ट किया गया है @ http://dev.i2p.net/pipermail/i2p/2005-January/000559.html 13:05 <bla> हाय 13:05 <jrandom> सीधे कूदते हैं, क्योंकि हम वैसे भी एक दिलचस्प चर्चा के बीच में घुस रहे हैं... 1) नेट स्थिति 13:05 <jrandom> मेल में जो है उससे आगे मुझे सच में कुछ जोड़ना नहीं है - क्या किसी के पास नेट स्थिति के संबंध में कुछ उठाने के लिए है? 13:06 <bla> इसके अलावा कि हमने पहली बार अंटार्कटिका को छोड़कर *सभी* महाद्वीपों पर नोड्स देखे हैं, नहीं। 13:06 <jrandom> w00t! 13:07 <jrandom> ठीक है, 2) 0.5 वाली चीज़ों पर चलते हैं 13:07 <mule> अरे, मेरे पिता अभी-अभी अंटार्कटिका जा रहे हैं, मुझे उन्हें एक नोड दे देना चाहिए था 13:07 <ant> <duck> कमबख्त अंटार्कटिका वाले 13:07 <Xan> कोई अंटार्कटिका निवासी नहीं? :( 13:07 <jrandom> हाहा, बढ़िया 13:07 <jrandom> हालाँकि मुझे नहीं लगता कि वहाँ कोई खास anonymity set (गुमनामी समूह) होगा 13:07 <Frooze> दोष अंटार्कटिका का है 13:08 * cervantes अंटार्कटिका में एक ऑयल रिग लगाता है ताकि वहाँ एक नोड का खर्च उठा सके 13:09 <jrandom> ठीक है ठीक है, 0.5 की बहुत सारी बातें हैं, तो हम इसे हिस्सों में लेंगे 13:09 <jrandom> सबसे पहले, उन लोगों का धन्यवाद जिन्होंने एक दिन भर के आँकड़े जुटाए - यहाँ बहुत-सा दिलचस्प डेटा है @ http://dev.i2p.net/~jrandom/messageSizes/ 13:09 <postman> मुझे खुशी हुई :) 13:10 <cervantes> नेट स्थिति के संबंध में... हाल ही में (फोरम आदि पर) कई लोगों को I2P चालू करके चलाने में दिक्कतें आती देखी हैं - पता नहीं यह केवल बढ़ती यूज़र संख्या की वजह से है या शायद ज़्यादा i2p आधारित ऐप्स होने से गड़बड़ियाँ बढ़ रही हैं 13:10 <+protokol> jrandom: झूठे! तुमने कहा था डेटा दिलचस्प है! 13:10 * jrandom protokol पर कीचड़ फेंकता है 13:11 <ant> <duck> cervantes: मैंने ऐसे रिपोर्ट भी देखे हैं कि लोग इसे कुछ ही मिनटों में चालू कर लेते हैं 13:11 <ant> <duck> NAT ज़्यादातर समस्याएँ पैदा कर रहा है, ऐसा मुझे लगता है 13:11 <cervantes> duck: सही... 13:11 <ant> <dmdm> NAT कौन है? 13:11 <jrandom> cervantes: कुछ बदसूरत समस्याएँ अभी भी हैं, निश्चित रूप से। NAT की समस्या और OSX ने हाल में थोड़ा सिरदर्द दिया है, पर Jhor की बाद वाली में मदद से स्थिति बेहतर होनी चाहिए 13:12 <cervantes> हां 13:12 <cervantes> *खाँसी* तो... 0.5 13:13 <Xan> dmdm: नेटवर्क एड्रेस ट्रांसलेशन 13:13 <jrandom> heh, ठीक। मूलतः उन मैसेज आकार के आँकड़ों का मकसद पैडिंग से जुड़ी समस्याओं की पड़ताल करना है 13:14 <jrandom> दुर्भाग्य से, जिस रणनीति को मैंने चुनिंदा नंबरों से बनाया था, वह बेकार निकली—सिर्फ पैडिंग डेटा से ही 25% ओवरहेड दे रही थी 13:14 <jrandom> अगर हम 0.5 एन्क्रिप्शन के प्रस्तावों में से एक (tunnels-alt.html) के साथ जाते हैं, तो वह समस्या नहीं रहेगी 13:15 <jrandom> (क्योंकि यह fragmentation के साथ छोटे निश्चित आकार लागू करेगा) 13:15 <mule> आप किस तरह के संदेशों को pad करना चाहते हैं—जो कोई router देखता है या जो कोई बाहरी पर्यवेक्षक देखता है? 13:15 <jrandom> mule: महत्वपूर्ण सवाल 13:15 <jrandom> यदि हम केवल बाहरी पर्यवेक्षक की चिंता कर रहे हैं, तो संदेशों को बिना पैड के छोड़ सकते हैं, और chaff जनरेशन transport layer पर कर सकते हैं 13:16 <Teal`c> http://microsoft.i2p/david_hasselhoff_05_christmas_album__silent_night.mp3 13:16 <jrandom> दूसरी ओर, अगर हमें tunnel प्रतिभागियों द्वारा flow analysis की चिंता है, तो हमें tunnel के भीतर पैडिंग पर ध्यान देना होगा 13:16 <@duck> 5-6 hops होने पर, किसी router द्वारा traffic analysis करने का कितना बड़ा खतरा है? 13:16 <cervantes> Teal`c: मीटिंग चल रही है... क्या mp3 की घोषणा के लिए #i2p-chat इस्तेमाल कर सकते हो ;-) 13:17 <Teal`c> माफ़ कीजिए 13:17 <cervantes> :) डेविड हैस्लहॉफ के लिए? 13:18 <jrandom> यह इस पर निर्भर करता है कि विश्लेषण का स्तर क्या है, duck। यदि उन्होंने किसी तरह यह पता लगा लिया कि वे किस tunnel में हैं (उदा. वे inbound tunnel gateway हैं और उन्होंने netDb इकट्ठा कर लिया है, उसे किसी destination से सहसंबंधित कर रहे हैं), तो वह साधारण बात नहीं है। दूसरी ओर, यह सीधा खुलासा नहीं है, पर कुछ जानकारी तो देता है 13:18 <jrandom> tunnel पैडिंग से भी अधिक महत्वपूर्ण end-to-end पैडिंग है, जो gateways और endpoints से संदेश प्रवाह का डेटा छिपाती है। 13:19 <jrandom> अगर हम पूरी तरह पागल/मूर्ख हों, तो हम हर जगह constant bitrate का उपयोग करते हुए pipenet तक जा सकते हैं 13:19 <+polecat> मुझे समझ आया! 13:19 <jrandom> (और नतीजे में I2P चलाने वाले कोई यूज़र न बचें) 13:19 <+polecat> हमें करना यह चाहिए कि I2P को email के ऊपर tunnel करें! 13:19 <cervantes> काफी बड़े नेटवर्क पर सांठगांठ करने वाले router के एक ही tunnel में आ जाने की कितनी संभावना है? 13:19 <+polecat> कोई भी ISP इतना बेवकूफ़ नहीं होगा कि email रोक दे! 13:20 * jrandom net.i2p.router.transport.gmail इम्प्लीमेंटेशन का इंतज़ार करता है 13:20 <postman> polecat: अरे, यह तो बेवकूफ़ी है 13:20 <postman> :) 13:20 <bla> cervantes: N^(-h) (N = तेज नोड्स की संख्या, h = hops की संख्या)। लगता है 13:20 <+polecat> =3 मैं जानता हूँ। 13:21 <cervantes> क्या वह बहुत है? :) 13:21 <jrandom> तेज़ नोड्स की संख्या नहीं, क्योंकि बाहरी लोग आपके प्रोफाइल नहीं जानेंगे 13:21 <+polecat> गंभीरता से कहूँ, मौजूदा IP सेवाओं का बेधड़क दुरुपयोग करके हम I2P को अनगिनत चतुर तरीकों से tunnel कर सकते हैं। 13:21 <jrandom> दो peers को एक ही tunnel में लाने की संभावना c^2/N^h 13:21 <jrandom> सहमत, polecat। यही कारणों में से एक है कि हमारे पास bidirectional tunnels नहीं हैं 13:22 <jrandom> कुछ transport (उदा. email) bidirectional संचार के लिए बेकार हैं 13:22 <bla> jrandom: c = ? 13:22 <jrandom> c == सांठगांठ करने वाले peers की संख्या 13:23 <+polecat> हम्म, दिलचस्प बात। 13:23 <ant> <duck> रोडमैप की दृष्टि से, अगर I2P गलत दिशा में चला गया और गलत crypto समाधान चुन लिया तो उसका प्रभाव क्या होगा? 13:23 <+polecat> या कबूतर प्रोटोकॉल, ज़रा भी bidi नहीं। 13:23 <+polecat> crypto पहले से modular है, है न? 13:23 <jrandom> duck: यह 0.5 में बस एक बुलेट प्वाइंट है, और tunnels*.html डॉक की एक उपधारा। टनल रूटिंग में केवल डेटा को कैसे लपेटते हैं, उससे कहीं ज़्यादा बातें हैं 13:24 <bla> jrandom: फिर भी, यह उन्हें अभी के लिए एक ही tunnel में मिलने की समस्या है। हालाँकि, T बार tunnel refresh (हर इतने मिनट में) पर, यह P = 1 - (1 - c^2/N^h)^T हो जाता है 13:24 <jrandom> दूसरी ओर, 'fixed 1KB blocks' और '0-40KB blocks' के बीच का फर्क काफ़ी असर डालता है 13:24 <+polecat> मैं नहीं चाहूँगा कि यह नेटवर्क Entropy की तरह McEliece में फँस जाए। 13:24 <jrandom> polecat: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD पढ़ो 13:24 <bla> jrandom: और इस तरह पर्याप्त लंबे समय पर यह शून्य की ओर बढ़ता है। यानी, पर्याप्त लंबे समय में, हमलावर कम-से-कम एक बार एक ही tunnel में होंगे 13:25 <jrandom> योजना standard AES256/CBC है 13:25 <+protokol> मैंने सुना है DNS चीज़ों को tunnel करने के लिए अच्छा है, ज़्यादातर लोग इसे ब्लॉक नहीं करते 13:25 <jrandom> निश्चित रूप से, bla, हालांकि यह इतना सीधा नहीं है (exploratory tunnels के लिए है, पर client tunnels के लिए नहीं) 13:26 <+polecat> और अगर किसी तरह AES भी टूट जाए, तो कोई समकक्ष symmetric cipher। 13:27 <jrandom> bla: मुझे नहीं लगता कि अधिकांश मामलों में यह उस हद तक व्यावहारिक चिंता है, पर जब इसे predecessor attack के हिस्से के रूप में अंजाम दिया जाता है, तो मुद्दा काफी हद तक बेमायने हो जाता है 13:28 <jrandom> (क्योंकि हम बाकी tunnel routing जिस तरह करते हैं) 13:28 <bla> jrandom: ठीक 13:28 <jrandom> सही, polecat 13:29 <jrandom> duck: अगर हम दूसरे विकल्प के साथ जाएँ, तो बाद में दूसरे में बदलना संभवतः आसान होगा। 13:29 <jrandom> दूसरी ओर, दूसरे विकल्प में ढेर सारा performance tuning चाहिए होगा ताकि यह बेकार न लगे 13:29 <jrandom> पर मुझे यक़ीन है कि हम इसे कर लेंगे 13:31 <jrandom> खैर, मुझे लगता है ऊपर की बातें बताती हैं कि 0.5 के काम के संबंध में हम अभी कहाँ हैं 13:31 <jrandom> क्या किसी और के पास कोई सवाल/टिप्पणी/चिंता है? 13:31 <bla> jrandom: एक 13:32 <bla> jrandom: मुझे लगता है कि अभी के लिए हमें गुमनामी को प्रदर्शन से थोड़ा ऊपर रखना चाहिए; तो हाँ, PRNG (छद्म-यादृच्छिक संख्या जनक) वाला विकल्प अच्छा लगता है 13:33 <jrandom> सहमत। प्रदर्शन बाद में ट्यून किया जा सकता है, पर बेहतर गुमनामी को बाद में 'जोड़ना' काफ़ी मुश्किल होता है 13:33 <jrandom> (लेकिन, बेशक, प्रदर्शन /एक/ सुरक्षा पैरामीटर है। अगर यह बेकार है, तो कोई इसका उपयोग नहीं करेगा) 13:33 <bla> हाँ। 13:33 <bla> jrandom: 13:33 <bla> माफ़ कीजिए 13:33 <@duck> right, /me flips the magical Freenet-performance bit 13:33 <cervantes> शायद इससे वे सारे टोरेंट लहराते leechers कुछ देर और दूर ही रहें ;-) 13:34 <jrandom> heh 13:34 <cervantes> <-- कनेक्शन रीसेट 13:34 <bla> cervantes: नहीं, मैं नहीं हूँ! :) 13:34 <cervantes> :) 13:35 <jrandom> मुझे लगता है कि हम कुछ बहुत अच्छे अनुकूलन कर सकते हैं, और लगता है कि हमारी कई बाधाएँ peer selection से नहीं, बल्कि (heh) jobqueue में बग्स के कारण हैं 13:36 <jrandom> लेकिन, खैर, 2) 0.5 के लिए और कुछ? 13:36 <ant> <BS314159> क्या आप इस loop attack की एक व्याख्या पोस्ट कर सकते हैं? 13:37 <ant> <BS314159> यह आपकी व्याख्या से ज़्यादा ख़तरनाक लगता है 13:37 <jrandom> लूप: A-->B-->C-->D-->C वाला एक tunnel बनाइए, उसमें 10 संदेश भेजिए। 13:37 <jrandom> PRNGs के बिना, आप उस C<-->D लूप में जितने चाहें उतने संदेश जोड़ सकते हैं 13:38 <ant> <BS314159> ठीक 13:38 <jrandom> व्यवहार में कुछ ही संदेशों से किसी भी router पर DoS (सेवा-अस्वीकरण हमला) कर देना 13:38 <ant> <BS314159> लेकिन यह केवल A कर सकता है 13:38 <jrandom> PRNGs के साथ, लूप में जा सकने वाले संदेशों की संख्या सीमित हो जाती है 13:38 <ant> <BS314159> तो हमलावर लूप डालकर मेरे tunnels को छोटा करने का कोई खतरा नहीं है 13:38 <jrandom> नहीं, कोई भी आपके tunnels छोटा नहीं कर सकता 13:39 <jrandom> यह बस DoS के लिए ही उपयोगी है 13:39 <jrandom> (बहुत सस्ता DoS) 13:39 <jrandom> (लेकिन जब आप कम लागत में चुने हुए peers पर DoS कर सकते हैं, तो आप बहुत बुरा काम कर सकते हैं) 13:40 <ant> <BS314159> समझ गया 13:40 <+protokol> और hashcash certs इससे मदद करेंगी? 13:40 <jrandom> protokol: hashcash इस समस्या को संबोधित करता है कि कोई peer बहुत अधिक tunnels बना रहा है, और शायद बहुत अधिक hops बना रहा है 13:41 <jrandom> protokol: यह loops में मदद नहीं करता। दो तरीके जो मुझे /वास्तव में/ कारगर लगे, वे थे PRNGs (tunnel-alt.html) या हर चरण पर सत्यापन करना (tunnel.html) 13:42 <jrandom> हर चरण पर सत्यापन करने में जोखिम हैं, इसलिए अभी झुकाव PRNGs की ओर है 13:42 <+Ragnarok> PRNG विधि कितनी प्रभावी होगी? 13:42 <Xan> A-->B-->C-->D-->C - क्या हर hop को अलग id वगैरह नहीं मिलनी चाहिए, ताकि संदेश C पर दूसरी बार पहुँचने पर tunnel से बाहर निकल जाएँ, बजाय लूप करने के? 13:43 <jrandom> Xan: मिलती है, पर हर चरण पर सत्यापन किए बिना आप नहीं बता सकते कि यह गलत है या नहीं 13:44 <jrandom> Ragnarok: मुझे लगता है यह होने वाले नुकसान को न्यूनतम करने में बहुत प्रभावी होगा 13:45 <jrandom> कम से कम, अभी तक जो मैं देख पा रहा हूँ उससे 13:45 <jrandom> अगर किसी को इसमें कोई समस्या/मुद्दा दिखे, या सुधार के सुझाव हों, तो कृपया संपर्क करें :) 13:46 <Xan> या शायद मैं बात समझ नहीं रहा 13:46 <Xan> bbl 13:46 <jrandom> 'k l8r, मैं दस्तावेज़ को और स्पष्ट करने के लिए अपडेट करूँगा 13:47 <jrandom> ठीक है, अगर और कुछ नहीं है, तो क्या हम 3) i2pmail.v2 पर चलें? 13:47 <jrandom> postman: तुम आसपास हो? 13:48 <postman> हाँ 13:49 <postman> :) 13:49 <jrandom> फोरम पर तुम्हारी पोस्ट में जो था, उससे कुछ जोड़ना है? वह काफ़ी बढ़िया लगती है 13:49 <postman> खैर, आप में से कुछ लोग शायद i2pmail.v2 का ड्राफ्ट पहले ही पढ़ चुके होंगे 13:50 <bla> क्या हो रहा है? भारी डिस्कनेक्ट्स। मुझे यहाँ भी साइट्स (जैसे orion, library) तक पहुँचने में दिक्कत हो रही है 13:50 <postman> यह भविष्य में पूरी तरह decentralized मेल इन्फ्रास्ट्रक्चर का लक्ष्य रखता है 13:50 <postman> लेकिन इसे नोड्स पर प्रॉक्सी सॉफ़्टवेयर और कई dedicated relays की ज़रूरत होगी 13:51 <postman> सभी को विचार/कॉन्सेप्ट/रैंट्स योगदान देने के लिए आमंत्रित किया जाता है 13:51 <postman> डेवलपमेंट शुरू हो चुका है - देर से आने वाली वसंत ऋतु से पहले कुछ उम्मीद न करें :) 13:51 <jrandom> w00t 13:51 <kaji> हूँ, पुलिस अभी मेरे दरवाज़े पर आ गई 13:52 <bla> kaji: ? 13:52 <jrandom> जल्दी, अपना हार्ड ड्राइव उड़ा दो 13:52 <postman> jrandom: खैर, अभी के लिए मेरे पास कहने को बस इतना ही है :) 13:52 <cervantes> ब्लैकजैक टेबल छिपा दो! 13:52 <jrandom> शानदार, धन्यवाद postman 13:52 <kaji> उन्होंने कहा कि मैंने 911 डायल किया, पर मुझे पूरा यक़ीन है कि न तो मैंने और न ही मेरे भाई ने किया 13:53 <+protokol> kaji: वे बस I2P की जाँच कर रहे हैं 13:53 <jrandom> ठीक है, अगर 3) i2pmail पर और कुछ नहीं है, तो 4) azneti2p_0.2 पर चलते हैं 13:53 <+protokol> <creepy music> 13:53 <jrandom> जैसा ईमेल में कहा था, हाल में कुछ महत्वपूर्ण प्रगति हुई है 13:53 <kaji> फिर उन्होंने कहा कि कॉर्डलेस फोन ऑफ-द-हुक होने पर गड़बड़ा सकते हैं, पर मेरे सारे कॉर्डलेस फोन अपने चार्जर पर हैं -> #i2p-chat 13:55 <jrandom> azureus वाले अपडेट तैयार करने में काफी responsive रहे हैं (वाह!), पर लोगों को समस्याओं के लिए भी चौकन्ना रहना चाहिए 13:55 <jrandom> (यदि आप I2P मेलिंग लिस्ट नहीं पढ़ते और azneti2p इस्तेमाल करते हैं, तो I2P मेलिंग लिस्ट पढ़ें) 13:55 <jrandom> ((या भले ही आप azneti2p इस्तेमाल न करते हों, लिस्ट पढ़ें, क्योंकि हम वहीं महत्वपूर्ण बातें घोषित करते हैं ;) 13:56 <jrandom> duck और orion भी नए bt क्लाइंट और फ़ॉर्मैटिंग के अनुरूप ढेरों अपडेट कर रहे हैं 13:56 <jrandom> (वाह!) 13:56 * orion मुस्कुराता है 13:57 <orion> अभी भी काफी रास्ता तय करना है, पर फिलहाल, यह काम करता है। 13:57 <jrandom> (जितना I2P उसे करने देता है ;) 13:58 <orion> हेहे, हाँ। ;) 13:58 <jrandom> क्या किसी और के पास azneti2p या i2p-bt के संबंध में कुछ उठाने के लिए है? 13:58 <jrandom> (या bytemonsoon2p ;) 14:00 <jrandom> ठीक है, अगर नहीं, तो सीधे 5) ??? पर चलते हैं 14:00 <jrandom> खुला मंच - क्या किसी और के पास कुछ उठाने के लिए है? 14:00 <postman> jrandom: addressbook userhosts प्रविष्टियाँ प्रकाशित क्यों करता है? 14:01 <jrandom> postman: बग। 14:01 <postman> तो यह नियोजित व्यवहार नहीं था और बदला जाएगा? 14:01 <cervantes> बस एक बात... 14:01 <jrandom> postman: सही, और इसे बदला जाएगा 14:02 <jrandom> (है न, Ragnarok? :) 14:02 <+Ragnarok> यह इस पर निर्भर करता है कि postman का मतलब ठीक-ठीक क्या है... 14:03 <jrandom> Ragnarok: स्थानीय यूज़र द्वारा उनके निजी hosts में जो नई प्रविष्टियाँ जोड़ी जाती हैं, उन्हें प्रकाशित hosts में propagate नहीं होना चाहिए 14:03 <jrandom> (उदा. userhosts.txt निजी है, hosts.txt अन्य लोगों के साथ synchronized है और सार्वजनिक है) 14:03 <cervantes> फोरम पर एक अर्ध-नियमित स्लॉट के तहत, उन लोगों के लिए सराहना और पुरस्कार होंगे जिन्होंने I2P में हाल में या परियोजना के जीवनकाल में अच्छी चीज़ें योगदान की हैं 14:03 <postman> Ragnarok: 0.4.2.6 में अपडेट करने के बाद मैंने अपने eepsite फ़ोल्डर में प्रकाशित addressbook में userhosts.txt की प्रविष्टियाँ पाईं 14:03 <ant> <BS314159> हम्म 14:04 <postman> Ragnarok: वे manually जोड़ी गई keys थीं, जिन्हें प्रकाशित नहीं होना चाहिए था 14:04 <cervantes> इस सप्ताह हम duck को समुदाय के लिए सेवा प्रदाता के रूप में सामान्य उत्कृष्टता और सर्वांगीण महान idler होने के लिए मान्यता देते हैं: http://forum.i2p/viewtopic.php?t=275 14:04 <jrandom> w00t! 14:04 <jrandom> (go duck go, go duck go) 14:05 <Teal`c> डोमेन नाम हाईजैकिंग का क्या? 14:05 * brachtus तालियाँ बजाता है 14:05 * orion सम्मान के रूप में बत्तख चाल चलता है। 14:05 <cervantes> भविष्य के लिए एक महत्वपूर्ण बात... प्रशंसा पाने के लिए आपको क्रिप्टोग्राफ़ी का जीनियस होने की ज़रूरत नहीं! 14:06 <+Ragnarok> नहीं, वह अपेक्षित व्यवहार है। मैं इसे बदल सकता हूँ, पर पहले मुझे file locking लागू करना पूरा करना होगा ताकि आप hosts.txt सीधे बदल सकें 14:06 <orion> (लेकिन इससे मदद मिलती है) 14:06 <cervantes> आपने बस कोई जबरदस्त eepsite वगैरह योगदान की हो सकती है... 14:06 <cervantes> या फोरम आदि पर सहायक व्यक्ति रहे हों 14:07 <ant> <BS314159> हम्म 14:07 <cervantes> (वरना, सच बोलें, तो jrandom हर हफ्ते जीत जाएगा) 14:07 <jrandom> अरे, तुम सब मेरे बीयर फंड के लिए भुगतान कर रहे हो, यह सब मुफ़्त नहीं है ;) 14:07 <ant> <BS314159> क्या आप बस एक नई फ़ाइल "publichosts.txt" बना सकते हैं? 14:07 <ant> <BS314159> फिर addressbook userhosts.txt को नज़रअंदाज़ करे, लेकिन यूज़र अपने publichosts.txt को subscribe कर सकें? 14:08 <jrandom> Teal`c: डोमेन नाम हाईजैक करने का कोई तरीका नहीं है, कोई प्रविष्टि ओवरराइट नहीं होती, और userhosts हमेशा hosts को override करता है 14:09 <jrandom> Ragnarok: शायद web interface लॉकिंग की समस्या संभाल सकता है, क्योंकि यूज़र फ़ाइलों में मैन्युअली नहीं जोड़ेंगे 14:09 <+Ragnarok> एक बार locking हो जाने के बाद, userhosts.txt से addresses खींचने का कोई वास्तविक कारण नहीं बचेगा (वर्तमान में रेस कंडीशन से बचने का यही एक तरीका है), इसलिए तीसरी फ़ाइल जोड़ने का भी कोई वास्तविक अर्थ नहीं 14:10 <+Ragnarok> jrandom: खैर, मैं Java file locking API इस्तेमाल करने की योजना बना रहा था 14:10 <jrandom> यदि तुम्हें लगता है यह ज़रूरी है, तो बॉस तुम ही हो :) 14:10 <ant> <BS314159> इससे आप दूसरों से मिले सभी नाम हटा सकेंगे, जबकि अपने बनाए हुए रख सकेंगे 14:10 <ant> <BS314159> सिर्फ hosts.txt साफ़ करके और अपनी subscriptions बदलकर 14:11 <ant> <BS314159> पर मेरा ख्याल है यह name-signing तक इंतज़ार कर सकता है 14:11 <orion> metadata यह समस्या हल कर देगा। क्या कोई स्पेक तैयार हुआ है? 14:11 <jrandom> सिर्फ दो फ़ाइलें इस्तेमाल करना ठीक रहेगा - एक addressbook द्वारा प्रबंधित, एक नहीं 14:12 <jrandom> (आप addressbook को userhosts.txt को पूरी तरह नज़रअंदाज़ करने दे सकते हैं - वैसे भी userhosts.txt, hosts.txt को override करता है) 14:12 <+Ragnarok> jrandom: वही योजना होगी, जैसे ही locking हो जाए (जो सच में बहुत काम नहीं होना चाहिए, बस मैं अभी तक कर नहीं पाया :) 14:13 <+Ragnarok> और मैं वर्तमान में इतना XML Schema सीखने पर काम कर रहा हूँ कि namerecords के लिए एक लिख सकूँ 14:13 <ant> <dr_kavra> क्या यह kenosis के लिए चैनल है? दूसरे चैनल ने मुझे यहाँ आने को कहा :D 14:13 <jrandom> lol 14:13 <jrandom> नहीं, माफ़ करना, यह I2P है 14:14 <jrandom> (जब तक कि आप कोई anonymous comm layer नहीं ढूँढ रहे) 14:14 <jrandom> शानदार, Ragnarok 14:14 <ant> <BS314159> मुझे अब भी लगता है कि YAML की तुलना में XML इसके लिए बहुत verbose और गैर-मानवीय-पठनीय है, लेकिन कोड मैं नहीं लिख रहा 14:14 <jrandom> Ragnarok: कठिन हिस्सा होगा XML के साथ crypto करना, बिना बदसूरत CDATA पर लौटे 14:14 <orion> metadata स्पेक के लिए किसी ने कोई working draft लिखा है? 14:15 <jrandom> (व्यक्तिगत रूप से, मुझे लगता है XML बेकार है, पर मैं तो बस नकारात्मक सोच वाला हूँ) 14:15 <jrandom> orion: http://dev.i2p.net/pipermail/i2p/2004-February/000135.html पर एक बुनियादी सेटअप है 14:15 <orion> (name/key metadata) 14:15 <dox> क्या addressbook और उसकी सुविधाओं की कहीं घोषणा हुई है? मुझे नहीं पता था कि मेरा hosts.txt प्रकाशित होता है 14:15 <jrandom> (NameReference और LocalEntry elements देखें) 14:16 <jrandom> dox: इसे addressbook/config.txt में निर्दिष्ट स्थान पर लिखा जाता है 14:16 <jrandom> (डिफ़ॉल्ट रूप से, ./eepsite/docroot/hosts.txt) 14:17 <orion> इसमें public/private (यानी बाँटो/मत बाँटो) फ्लैग नहीं है। 14:17 <ant> <cervantes> XML की अच्छी बात (और यह बड़ा + प्वाइंट है) सिर्फ यह है कि यह व्यापक रूप से स्वीकार किया गया मानक है 14:17 <jrandom> सही, orion, उस पोस्ट के बाद से बहुत से अच्छे विचार आए हैं 14:17 <+Ragnarok> XML बेकार हो सकता है, पर साफ़ कहूँ तो जो मैं कर रहा हूँ उसके लिए यह बाकी विकल्पों से बेहतर है 14:17 <jrandom> cervantes: EDI भी 14:17 <orion> क्या उन्हें संक्षेप में रखने की कोई जगह है? यानी फोरम एरिया? 14:18 <orion> या शायद कोई विकि पेज? 14:18 <jrandom> orion: susi या ugha का विकि 14:18 <orion> मैं bytemonsoon और orion.i2p के लिए विकि सेट करने जा रहा हूँ ताकि दोनों के भविष्य के विकास लक्ष्यों पर सामुदायिक सहमति बन सके। 14:18 <BrockSamson> XML + crypto CDATA के बिना = MIME, है न? 14:19 <jrandom> शानदार, orion 14:19 <jrandom> BrockSamson: S/MIME, अलग-अलग parsers के साथ ;) 14:19 <orion> (name metadata के लिए भी एक) 14:21 <jrandom> metadata करने के कई तरीके हैं; महत्वपूर्ण है लचीलापन और 'सहीपन', ताकि यह समय के साथ बढ़/बदल सके 14:21 * jrandom आश्वस्त है कि Ragnarok आदि कुछ अच्छा लेकर आएँगे :) 14:21 <orion> इसीलिए मुझे लगता है कि एक सार्वजनिक ड्राफ्ट होना चाहिए। 14:22 <ant> <cervantes> I2P consortium :P 14:22 <jrandom> खैर, लोग पिछली कुछ बैठकों से कह रहे हैं "किसी को अपने विचार विकि पर डालने चाहिए", पर विकि पेज बहुत नहीं बढ़ रहे ;) जो ठीक है, हम अपनी गति से चलेंगे 14:23 * orion वादा करता है कि एक दिन में तीन विकि खड़े कर देगा और सबको उनके पते ईमेल करेगा 14:23 <BrockSamson> मुझे आलसी कहो, पर ANSI 850 Purchase Order EDI की किसी भी XML आधारित Purchase Order से तुलना करो, तो मैं XML संस्करण के लिए डिकोड, कोड और डिबग करना पसंद करूँगा। भले ही वह EDI से 5 गुना बड़ा हो 14:23 <jrandom> w00t 14:23 <jrandom> heh, BrockSamson 14:24 <BrockSamson> पोजीशन 10 ST है? ओह तो पोजीशन 310 नाम होना चाहिए 14:24 <BrockSamson> ओह, मेरी गलती 14:24 <jrandom> BrockSamson: नहीं लगता कि POs के लिए XML स्कीमा कुछ ज़्यादा अच्छे हैं ;) 14:24 <jrandom> (पर हाँ, वह सब तो पूरी तरह भयानक आपदा है) 14:25 <BrockSamson> सुबह 4:30 बजे तो वे अच्छे लगते हैं 14:25 <BrockSamson> जब तक कि... 14:25 <jrandom> heh 14:25 <BrockSamson> उन्हें किसी पूर्व EDI प्रोग्रामर ने लिखा हो 14:25 <BrockSamson> और XML कुछ ऐसा दिखता है: <p1><po><q>1</q></po></p1> 14:26 <BrockSamson> मैं शर्त लगाता हूँ, अगर आप यह जोड़ें कि ओपन सोर्स प्रोजेक्ट्स 'XML' हो या 'नो XML' पर बात करते हुए कितने घंटे खर्च करते हैं, तो आप Linux को 10x बार फिर से कोड कर सकते थे। 14:26 <BrockSamson> हर प्रोजेक्ट जिसका मैं हिस्सा रहा हूँ, उसमें इस पर भारी बहसें हुई हैं 14:27 <orion> बहसें प्रोजेक्ट के लिए अच्छी होती हैं, यह इस पर निर्भर करता है कि बहस कौन कर रहा है ;) 14:27 <jrandom> अच्छा, यह जो करता है वही करता है, पर यह रामबाण नहीं है। नामकरण वगैरह के लिए यह अच्छा काम कर सकता है 14:28 <BrockSamson> बहुत से लोग तो प्रोजेक्ट्स में केवल बहस करने के लिए ही होते हैं। 14:28 <jrandom> यहाँ नहीं। मैं तो मुफ्त बीयर के लिए हूँ 14:28 <ant> <cervantes> यह बहस योग्य है 14:28 <orion> ड्राफ्ट स्पेक अधिक ठोस होने पर इम्प्लीमेंटेशन विवरण अधिक स्पष्ट होंगे। 14:28 <orion> इसलिए विकि/पीयर रिव्यू की ज़रूरत है। 14:29 <BrockSamson> सुना है यह प्रोजेक्ट मुफ्त Garlic देता है 14:29 <jrandom> काफ़ी सारा 14:30 <jrandom> ठीक है, मीटिंग के लिए किसी और के पास कुछ उठाने के लिए है? 14:30 <ant> * cervantes घंटी वाली औपचारिक गाय को बाहर लाता है 14:30 <ant> <cervantes> call =cow 14:30 * jrandom तैयार होता है 14:31 * jrandom गाय की घंटी पर *baf* करता है, मीटिंग समाप्त करता है