2018 के लिए उच्च-स्तरीय रोडमैप

34C3 में जिन कई बातों पर हमने चर्चा की, उनमें से एक यह थी कि आने वाले वर्ष में हमें किस पर ध्यान केंद्रित करना चाहिए। खास तौर पर, हम ऐसा रोडमैप चाहते थे जो यह स्पष्ट करे कि कौन‑सी चीज़ें हम हर हाल में पूरी करना चाहते हैं और कौन‑सी वे हैं जो हों तो बहुत अच्छा होगा, और जो दोनों श्रेणियों में नए लोगों को शामिल कराने में मदद कर सके। हम इस निष्कर्ष पर पहुँचे:

प्राथमिकता: नई क्रिप्टो(ग्राफी!)

वर्तमान के कई प्रिमिटिव्स और प्रोटोकॉल अब भी लगभग 2005 के अपने मूल डिज़ाइनों को बनाए हुए हैं, और उन्हें सुधार की आवश्यकता है। हमारे पास कई वर्षों से अनेक खुले प्रस्ताव और विचार रहे हैं, लेकिन आगे बढ़ने की गति धीमी रही है। हम सभी इस पर सहमत हुए कि यह 2018 के लिए हमारी सर्वोच्च प्राथमिकता होनी चाहिए। मुख्य घटक इस प्रकार हैं:

• New transport protocols (to replace NTCP and SSU). See Prop111.
• New onion-encryption protocol for building and using tunnels.
• New NetDB datatypes to enable enhanced Destinations. See Prop123.
• Upgraded end-to-end protocol (replacing ElGamal).

इस प्राथमिकता पर कार्य कई क्षेत्रों में विभाजित है:

• Writing proposals.
• Writing working implementations of them that we can test.
• Reviewing proposals.

हम इन सभी क्षेत्रों पर काम किए बिना पूरे नेटवर्क में नए प्रोटोकॉल विनिर्देश जारी नहीं कर सकते।

वांछनीय: कोड का पुनः उपयोग

ऊपर वर्णित कार्य को अभी शुरू करने का एक लाभ यह है कि पिछले कुछ वर्षों में सरल प्रोटोकॉल और प्रोटोकॉल फ्रेमवर्क बनाने के लिए स्वतंत्र प्रयास हुए हैं, जो हमारे अपने प्रोटोकॉल के लिए निर्धारित कई उद्देश्यों को पूरा करते हैं, और व्यापक समुदाय में स्वीकार्यता हासिल कर चुके हैं। इस कार्य का लाभ उठाकर, हमें एक “बल-गुणक” प्रभाव मिलता है:

• We benefit from protocol designs, security proofs, and code written by others, reducing the amount of work we need to do for the same level of feature-completeness and security assurances.

• Work we do can be leveraged by other communities, increasing their interest in collaborating with us, and thinking about I2P as a whole.

विशेष रूप से, मेरे प्रस्ताव Noise Protocol Framework और SPHINX packet format का लाभ उठाएँगे। इनके लिए I2P के बाहर कई लोगों के साथ मेरे सहयोग तय हो चुके हैं!

प्राथमिकता: Clearnet (सामान्य इंटरनेट) सहयोग

इसी विषय पर, हम पिछले लगभग छह महीनों से धीरे-धीरे रुचि बढ़ा रहे हैं। PETS2017, 34C3 और RWC2018 में, व्यापक समुदाय के साथ सहयोग को बेहतर बनाने के तरीकों पर मेरी कुछ बहुत अच्छी चर्चाएँ हुईं। यह बहुत महत्वपूर्ण है ताकि नए प्रोटोकॉल के लिए हम यथासंभव अधिक समीक्षा प्राप्त कर सकें। सबसे बड़ा अवरोध जो मैंने देखा है, वह यह है कि I2P विकास में होने वाला अधिकांश सहयोग वर्तमान में I2P के भीतर ही होता है, जिससे योगदान करने के लिए आवश्यक प्रयास में उल्लेखनीय वृद्धि हो जाती है।

इस क्षेत्र में दो प्राथमिकताएँ हैं:

• Set up a project-run development forum that is accessible both inside and outside I2P.

• Set up mailing lists for review and discussion of proposals (possibly connected to the above forum).

अन्य लक्ष्य जिन्हें वांछनीय के रूप में वर्गीकृत किया गया है:

• Set up a usable git-to-mtn pathway, to enable us to effectively solicit clearnet contributions on GitHub while keeping the canonical dev environment on Monotone.

• Write a “position paper” that accurately explains I2P to academic audiences, and puts it in context with existing literature.

मुझे उम्मीद है कि I2P के बाहर के लोगों के साथ सहयोग पूरी तरह GitHub पर किया जाएगा, ताकि न्यूनतम बाधा रहे।

प्राथमिकता: दीर्घकालिक रिलीज़ के लिए तैयारी

I2P अब Debian Sid (उनकी अस्थिर रिपॉज़िटरी) में है, जो लगभग डेढ़ साल में स्थिर हो जाएगी, और अप्रैल में आने वाली अगली LTS रिलीज़ में शामिल करने के लिए इसे Ubuntu रिपॉज़िटरी में भी जोड़ लिया गया है। हम ऐसे I2P संस्करण देखने लगेंगे जो वर्षों तक बने रहेंगे, और हमें यह सुनिश्चित करना होगा कि हम नेटवर्क में उनकी मौजूदगी को संभाल सकें।

यहाँ हमारा प्राथमिक लक्ष्य है कि अगले वर्ष के भीतर जितने अधिक नए प्रोटोकॉल हम व्यावहारिक रूप से परिनियोजित कर सकते हैं, उन्हें परिनियोजित किया जाए, ताकि वे अगली Debian stable रिलीज़ में शामिल हो सकें। जो प्रोटोकॉल बहुवर्षीय परिनियोजन की आवश्यकता रखते हैं, उनके लिए हमें भविष्य-संगतता (forward-compatibility) के बदलावों को जितना जल्दी हो सके समेकित कर लेना चाहिए।

प्राथमिकता: वर्तमान ऐप्स का Pluginization (उन्हें प्लगइन के रूप में रूपांतरित करना)

Debian मॉडल अलग-अलग घटकों के लिए अलग-अलग पैकेज रखने के लिए प्रोत्साहित करता है। हम इस पर सहमत हुए कि वर्तमान में बंडल की गई Java एप्लिकेशनों को मुख्य Java router से अलग करना कई कारणों से लाभकारी होगा:

• It codifies the boundary between the applications and the router.

• It should make it easier to get these apps running with non-Java routers.

• It would enable third parties to create “I2P bundles” containing just the applications they want.

पहले की प्राथमिकताओं के साथ मिलकर, यह मुख्य I2P प्रोजेक्ट को, उदाहरण के लिए Linux kernel, की दिशा में अधिक आगे बढ़ाता है। हम स्वयं नेटवर्क पर ध्यान केंद्रित करने में अधिक समय लगाएंगे, और थर्ड-पार्टी डेवलपर्स को उन एप्लिकेशन पर ध्यान केंद्रित करने के लिए छोड़ेंगे जो नेटवर्क का उपयोग करते हैं (जो कि पिछले कुछ वर्षों में APIs और लाइब्रेरियों पर हमारे काम के बाद अब काफी आसान हो गया है)।

वांछनीय: ऐप सुधार

हम कई एप्लिकेशन-स्तर के सुधारों पर काम करना चाहते हैं, लेकिन हमारी अन्य प्राथमिकताओं को देखते हुए, वर्तमान में इसके लिए हमारे पास पर्याप्त डेवलपर समय नहीं है। यह ऐसा क्षेत्र है जहाँ हम नए योगदानकर्ताओं को आगे आते देखना पसंद करेंगे! ऊपर उल्लिखित decoupling (अलगाव) पूरा हो जाने पर, मुख्य Java router से स्वतंत्र होकर किसी विशिष्ट एप्लिकेशन पर काम करना किसी के लिए काफी आसान हो जाएगा।

ऐसा ही एक अनुप्रयोग, जिसमें आपकी मदद का स्वागत होगा, I2P Android है। हम इसे कोर I2P रिलीज़ के साथ अद्यतन रखते रहेंगे और जहाँ तक संभव हो बग्स को ठीक करते रहेंगे, लेकिन आधारभूत कोड और उपयोगिता में सुधार के लिए अभी बहुत कुछ किया जा सकता है।

प्राथमिकता: Susimail और I2P-Bote का स्थिरीकरण

इसके साथ ही, हम निकट भविष्य में विशेष रूप से Susimail और I2P-Bote के सुधारों पर काम करना चाहते हैं (जिनमें से कुछ 0.9.33 में शामिल हो चुके हैं)। पिछले कुछ वर्षों में इन पर अन्य I2P ऐप्स की तुलना में कम काम हुआ है, इसलिए हम कुछ समय लगाकर उनके कोडबेस को मानक के अनुरूप लाना चाहते हैं और नए योगदानकर्ताओं के लिए इन पर काम शुरू करना आसान बनाना चाहते हैं!

वांछनीय: Ticket triage (टिकट की प्राथमिकता-आधारित छंटाई)

हमारे पास I2P की कई उप-प्रणालियों और ऐप्स में टिकटों का बड़ा बैकलॉग है। उपरोक्त स्थिरीकरण प्रयास के हिस्से के रूप में, हम अपनी कुछ पुरानी, लंबे समय से लंबित समस्याओं को सुलझाना चाहेंगे। और भी महत्वपूर्ण यह है कि हम यह सुनिश्चित करना चाहते हैं कि हमारे टिकट सही तरह से व्यवस्थित हों, ताकि नए योगदानकर्ता काम करने के लिए उपयुक्त टिकट आसानी से ढूंढ सकें।

प्राथमिकता: उपयोगकर्ता समर्थन

उपरोक्त में से जिस एक पहलू पर हम विशेष ध्यान देंगे, वह है उन उपयोगकर्ताओं से संपर्क बनाए रखना जो समय निकालकर समस्याएँ रिपोर्ट करते हैं। धन्यवाद! जितना छोटा हम फीडबैक लूप बना पाएँगे, उतनी ही जल्दी हम नए उपयोगकर्ताओं द्वारा सामना की जाने वाली समस्याओं को सुलझा सकेंगे, और उतनी ही अधिक संभावना होगी कि वे समुदाय में भाग लेते रहें।

हमें आपकी मदद पाकर खुशी होगी!

केवल अनुवाद ही दें, और कुछ नहीं:

यह सब बहुत महत्वाकांक्षी लगता है, और है भी! लेकिन ऊपर दिए गए कई बिंदु एक-दूसरे से ओवरलैप करते हैं, और सावधानीपूर्वक योजना बनाकर हम उनमें ठोस प्रगति कर सकते हैं।

यदि आप ऊपर दिए गए किसी भी लक्ष्य में मदद करने में रुचि रखते हैं, तो हमसे आकर बातचीत करें! आप हमें OFTC और Freenode (#i2p-dev), तथा Twitter (@GetI2P) पर पा सकते हैं।