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).
अन्य लक्ष्य जिन्हें वांछनीय (nice-to-have) के रूप में वर्गीकृत किया गया है:
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 (उनका unstable repo) में है, जो लगभग डेढ़ साल में स्थिर हो जाएगा, और इसे Ubuntu repository में भी अप्रैल में होने वाली अगली LTS release में शामिल करने के लिए जोड़ लिया गया है। हम ऐसी I2P versions रखने जा रहे हैं जो कई वर्षों तक बनी रहेंगी, और हमें यह सुनिश्चित करना होगा कि नेटवर्क में उनकी उपस्थिति को हम संभाल सकें।
यहाँ हमारा प्राथमिक लक्ष्य यह है कि अगले वर्ष के भीतर जितने अधिक नए प्रोटोकॉल हम व्यावहारिक रूप से परिनियोजित कर सकें, उन्हें परिनियोजित करें, ताकि वे Debian की अगली स्थिर रिलीज़ में शामिल हो सकें। जिनके लिए बहुवर्षीय परिनियोजन आवश्यक है, उनके लिए हमें भविष्य-संगतता (forward-compatibility) संबंधी परिवर्तन जितनी जल्दी हो सके शामिल कर लेने चाहिए।
प्राथमिकता: वर्तमान ऐप्स का प्लग-इनकरण
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 और लाइब्रेरियों पर हमारे कार्य के बाद अब काफी आसान हो गया है)।
वांछनीय: ऐप सुधार
ऐप-स्तरीय कई सुधार हैं जिन पर हम काम करना चाहते हैं, लेकिन अन्य प्राथमिकताओं को देखते हुए हमारे पास अभी डेवलपर समय उपलब्ध नहीं है। यह ऐसा क्षेत्र है जहाँ हम नए योगदानकर्ताओं को देखना पसंद करेंगे! ऊपर वर्णित डिकप्लिंग (वियोजन) पूरा हो जाने के बाद, किसी के लिए मुख्य Java router से स्वतंत्र रूप से किसी विशिष्ट एप्लिकेशन पर काम करना काफी आसान हो जाएगा।
ऐसा ही एक अनुप्रयोग, जिसके लिए हम सहायता का स्वागत करेंगे, I2P Android है। हम इसे मुख्य I2P रिलीज़ों के साथ अद्यतन रखते रहेंगे और जहाँ तक संभव होगा बग्स को ठीक करते रहेंगे, लेकिन अंतर्निहित कोड तथा उपयोगिता में सुधार के लिए अभी भी बहुत कुछ किया जा सकता है।
प्राथमिकता: Susimail और I2P-Bote का स्थिरीकरण
इसके साथ ही, हम निकट भविष्य में विशेष रूप से Susimail और I2P-Bote के फ़िक्स पर काम करना चाहते हैं (जिनमें से कुछ 0.9.33 में शामिल हो चुके हैं)। पिछले कुछ वर्षों में इन पर अन्य I2P ऐप्स की तुलना में कम काम हुआ है, इसलिए हम थोड़ा समय लगाकर उनके कोडबेस को उचित मानक तक लाना चाहते हैं, और नए योगदानकर्ताओं के लिए उनमें शामिल होकर काम शुरू करना आसान बनाना चाहते हैं!
वांछनीय: टिकटों की छँटाई और प्राथमिकता निर्धारण
हमारे पास I2P की कई उप-प्रणालियों और ऐप्स में टिकटों का बड़ा बैकलॉग है। ऊपर बताए गए स्थिरीकरण प्रयास के हिस्से के रूप में, हम अपनी कुछ पुरानी, लंबे समय से लंबित समस्याओं को निपटाना चाहेंगे। और भी महत्वपूर्ण यह कि हम यह सुनिश्चित करना चाहते हैं कि हमारे टिकट सही ढंग से व्यवस्थित हों, ताकि नए योगदानकर्ता ऐसे अच्छे टिकट खोज सकें जिन पर वे काम कर सकें।
प्राथमिकता: उपयोगकर्ता समर्थन
उपरोक्त में से जिस एक पहलू पर हम विशेष ध्यान देंगे, वह है उन उपयोगकर्ताओं के साथ संपर्क बनाए रखना जो समय निकालकर समस्याओं की रिपोर्ट करते हैं। धन्यवाद! जितना छोटा हम प्रतिक्रिया चक्र बना पाएँगे, उतनी ही जल्दी हम वे समस्याएँ हल कर पाएँगे जिनका सामना नए उपयोगकर्ता करते हैं, और उतनी ही अधिक संभावना होगी कि वे समुदाय में भागीदारी जारी रखें।
हम आपके सहयोग का स्वागत करते हैं!
यह सब बहुत महत्वाकांक्षी लगता है, और है भी! लेकिन ऊपर दिए गए कई बिंदु एक-दूसरे से ओवरलैप करते हैं, और सावधानीपूर्वक योजना बनाकर हम उन्हें काफ़ी हद तक निपटा सकते हैं।
यदि आप ऊपर दिए गए किसी भी उद्देश्य में मदद करने में रुचि रखते हैं, तो आइए, हमसे बात करें! आप हमें OFTC और Freenode (#i2p-dev) तथा Twitter (@GetI2P) पर पा सकते हैं।