من بين العديد من الأمور التي ناقشناها في 34C3 ما يجب أن نركز عليه في العام القادم. بوجه خاص، أردنا خارطة طريق تكون واضحة فيما نريد التأكد من إنجازه، مقابل ما سيكون من الجيد وجوده، وأن تكون قادرة على مساعدة المبتدئين الجدد على الانضمام إلى إحدى هاتين الفئتين. وإليك ما توصلنا إليه:
الأولوية: تشفير (وأو بروتوكولات) جديدة!
ما زالت العديد من البدائل والبروتوكولات الحالية تحتفظ بتصاميمها الأصلية من حوالي عام 2005، وهي بحاجة إلى تحسين. لدينا عدد من المقترحات المفتوحة منذ عدة سنوات تحتوي على أفكار، لكن التقدم كان بطيئًا. اتفقنا جميعًا على أن هذا يجب أن يكون أولويتنا القصوى لعام 2018. المكونات الأساسية هي:
- بروتوكولات نقل جديدة (لإحلال NTCP و SSU). انظر Prop111 .
- بروتوكول تشفير بصل جديد لبناء الأنفاق واستخدامها.
- أنواع بيانات جديدة في NetDB لتمكين Destinations محسّنة. انظر Prop123 .
- ترقية بروتوكول من طرف إلى طرف (لإحلال ElGamal).
ينقسم العمل على هذه الأولوية إلى عدة مجالات:
- كتابة المقترحات.
- كتابة تطبيقات عملية يمكننا اختبارها.
- مراجعة المقترحات.
لا يمكننا إصدار مواصفات بروتوكولات جديدة عبر الشبكة بأكملها دون العمل في كل هذه المجالات.
من الجيد وجودها: إعادة استخدام الكود
إحدى فوائد البدء في العمل المذكور أعلاه الآن هي أنه على مدار السنوات القليلة الماضية، كانت هناك جهود مستقلة لإنشاء بروتوكولات بسيطة وأطر عمل بروتوكولات تحقق العديد من الأهداف التي نسعى إليها في بروتوكولاتنا الخاصة، وحظيت بقبول واسع في المجتمع الأوسع. من خلال الاستفادة من هذا العمل، نحصل على تأثير “مضاعف القوة”:
نستفيد من تصاميم البروتوكولات، وإثباتات الأمان، والكود المكتوب من قبل آخرين، مما يقلل من كمية العمل المطلوبة للوصول إلى نفس مستوى اكتمال الميزات وضمانات الأمان.
يمكن للمجتمعات الأخرى الاستفادة من العمل الذي نقوم به، مما يزيد من اهتمامهم بالتعاون معنا، والتفكير في I2P ككل.
سأعتمد بشكل خاص في مقترحاتي على إطار عمل Noise Protocol وتنسيق الحزمة SPHINX . لدي تعاونات مقررة مع عدة أشخاص خارج I2P حول هذه المواضيع!
الأولوية: التعاون عبر الإنترنت المفتوح (Clearnet)
في هذا السياق، كنا نبني اهتمامًا تدريجيًا على مدار الستة أشهر الماضية أو نحو ذلك. عبر PETS2017 و 34C3 و RWC2018، أجريت مناقشات جيدة جدًا حول السبل التي يمكننا من خلالها تحسين التعاون مع المجتمع الأوسع. هذا مهم جدًا لضمان حصولنا على أكبر قدر ممكن من المراجعات للبروتوكولات الجديدة. أكبر عائق رأيته هو أن غالبية تعاون تطوير I2P يحدث حاليًا داخل I2P نفسه، مما يزيد بشكل كبير من الجهد المطلوب للمساهمة.
الأولويتان في هذا المجال هما:
إنشاء منتدى تطوير تابع للمشروع يمكن الوصول إليه من داخل وخارج I2P.
إنشاء قوائم بريدية لمراجعة ومناقشة المقترحات (ربما متصلة بالمنتدى أعلاه).
أهداف أخرى تُصنف على أنها “من الجيد وجودها”:
إنشاء مسار عملي من git إلى mtn، لتمكيننا من طلب مساهمات من الإنترنت المفتوح (Clearnet) على GitHub مع الحفاظ على بيئة التطوير الرسمية على Monotone.
كتابة “ورقة موقف” تشرح I2P بدقة للجمهور الأكاديمي، وتحدد موقعه في سياق الأدبيات الحالية.
أتوقع أن التعاون مع الأشخاص خارج I2P سيتم بالكامل على GitHub، لتقليل الاحتكاك قدر الإمكان.
الأولوية: التحضير لإصدارات طويلة العمر
أصبح I2P الآن في Debian Sid (مستودعهم غير المستقر) والذي سيُستقر في حوالي سنة ونصف، وقد تم أيضًا تضمينه في مستودع Ubuntu للإدراج في إصدار LTS القادم في أبريل. سنبدأ في رؤية إصدارات I2P تبقى لسنوات، وعلينا التأكد من قدرتنا على التعامل مع وجودها في الشبكة.
الهدف الأساسي هنا هو طرح أكبر عدد ممكن من البروتوكولات الجديدة عمليًا في العام القادم، للوصول إلى إصدار Debian المستقر القادم. بالنسبة لتلك التي تتطلب عمليات طرح تمتد لعدة سنوات، يجب أن نُدخل تغييرات التوافق الأمامي في أبكر وقت ممكن.
الأولوية: تحويل التطبيقات الحالية إلى إضافات (Pluginization)
يشجع نموذج Debian على وجود حزم منفصلة للمكونات المنفصلة. اتفقنا على أن فصل التطبيقات الحالية المكتوبة بلغة Java عن جوهر موجه Java سيكون مفيدًا لأسباب عديدة:
- يُثبّت الحدود بين التطبيقات والموجه.
- يجب أن يجعل تشغيل هذه التطبيقات مع موجهات غير Java أسهل.
- سيسمح للأطراف الثالثة بإنشاء “حزم I2P” تحتوي فقط على التطبيقات التي يرغبون بها.
بالاقتران مع الأولويات السابقة، يدفع هذا المشروع الرئيسي لـ I2P أكثر نحو نموذج مشابه لنواة لينكس. سنركز أكثر على الشبكة نفسها، ونترك المطورين من الأطراف الثالثة يركزون على التطبيقات التي تستخدم الشبكة (وهو أمر أصبح أسهل بكثير بعد عملنا في السنوات القليلة الماضية على واجهات برمجة التطبيقات والمكتبات).
من الجيد وجودها: تحسينات التطبيقات
توجد مجموعة من التحسينات على مستوى التطبيقات التي نرغب في العمل عليها، لكننا حاليًا لا نملك الوقت الكافي للمطورين للقيام بذلك، بالنظر إلى أولوياتنا الأخرى. هذا مجال نود جدًا رؤية مساهمات جديدة فيه! بمجرد اكتمال الفصل المذكور أعلاه، سيكون من الأسهل بكثير لأي شخص العمل على تطبيق معين بشكل مستقل عن الموجه الرئيسي بلغة Java.
إحدى هذه التطبيقات التي نود الحصول على مساعدة فيها هي I2P Android. سنواصل تحديثها مع إصدارات I2P الأساسية، وسنقوم بإصلاح الأخطاء قدر الإمكان، لكن هناك الكثير الذي يمكن فعله لتحسين الكود الأساسي وكذلك سهولة الاستخدام.
الأولوية: استقرار Susimail و I2P-Bote
مع ذلك، نريد العمل بشكل خاص على إصلاحات Susimail و I2P-Bote في المدى القريب (وقد تم تضمين بعضها بالفعل في الإصدار 0.9.33). لم يُبذل لهما الكثير من العمل في السنوات القليلة الماضية مقارنة بتطبيقات I2P الأخرى، لذا نريد قضاء بعض الوقت لرفع مستوى قواعد الكود الخاصة بهما، وجعلها أسهل على المساهمين الجدد للانخراط فيها!
من الجيد وجودها: تصنيف التذاكر (Ticket triage)
لدينا تراكم كبير من التذاكر في عدد من أنظمة فرعية وتطبيقات I2P. كجزء من جهد الاستقرار المذكور أعلاه، نود جدًا تنظيف بعض المشكلات القديمة الطويلة الأمد. والأهم من ذلك، نريد التأكد من تنظيم تذاكرنا بشكل صحيح، بحيث يمكن للمساهمين الجدد العثور على تذاكر جيدة للعمل عليها.
الأولوية: دعم المستخدمين
إحدى جوانب ما سبق التي سنركز عليها هي الحفاظ على التواصل مع المستخدمين الذين يبذلون الجهد للإبلاغ عن المشكلات. شكرًا لكم! كلما قللنا من دورة التغذية الراجعة، تمكنا أسرع من حل المشكلات التي يواجهها المستخدمون الجدد، وازداد احتمال استمرارهم في المشاركة في المجتمع.
نود مساعدتكم!
كل هذا يبدو طموحًا جدًا، وهو كذلك! لكن العديد من البنود المذكورة أعلاه تتداخل، ومع التخطيط الدقيق يمكننا تحقيق تقدم كبير فيها.
إذا كنت مهتمًا بالمساعدة في أي من الأهداف المذكورة أعلاه، فتعال للدردشة معنا! يمكنك العثور علينا على OFTC و Freenode (#i2p-dev)، وعلى تويتر (@GetI2P).