اجتماع مطوري I2P - 04 مارس 2016

15:00:05 <zzz> 0) مرحباً 15:00:23 <zzz> 1) هيكلية هذه الاجتماعات 15:00:32 <zzz> 2) مناقشة خارطة الطريق 15:00:37 <zzz> 0) مرحباً 15:00:41 <zzz> مرحباً 15:00:54 <str4d> مرحباً 15:01:02 <xcps_> مرحباً! 15:01:27 <orignal_> ما الأخبار؟ 15:02:18 <zzz> يرجى مراجعة الموضوع في http://zzz.i2p/topics/2021 وخارطة الطريق الحالية في http://i2p-projekt.i2p/en/get-involved/roadmap 15:02:27 <zzz> 1) هيكلية هذه الاجتماعات 15:03:22 <zzz> هل ننتقل مباشرةً إلى خارطة الطريق أم نتحدث أولاً عن الأولويات عالية المستوى؟ 15:03:53 <str4d> أفضّل البدء بالخيار الثاني أولاً 15:04:41 <zzz> حسناً، في الموضوع طرحتُ أولويتين: توسيع الشبكة وزيادة الأمان 15:04:55 <zzz> كيف تبدوان كمبادئ عالية المستوى؟ 15:05:25 <zzz> فلنقرر أولاً ما هو المهم 15:05:32 <EinMByte> تبدوان كما هو متوقع، برأيي 15:05:48 <EinMByte> لكن "توسيع الشبكة" يجب أن يكون بالمعنى الواسع 15:05:57 <str4d> أعتقد أنهما رائعان كعناوين عريضة 15:06:03 <zzz> anonimal طرح الكثير غيرها في الموضوع، لكن هذا لم يكن ما أقصده حقاً 15:06:13 <xcps_> زيادة الأمان يجب أن تكون دائماً الأهم برأيي المتواضع 15:06:28 <zzz> هل هناك مبادئ أخرى علينا أخذها بالاعتبار أثناء مراجعة خارطة الطريق؟ 15:06:28 <str4d> برأيي المتواضع ما نحتاج إليه هنا هو تحديد ما الذي تعنيه فعلياً من ناحية المخرجات الممكنة 15:06:40 <EinMByte> إذن "توسيع الشبكة" يجب أن يعني أيضاً "زيادة اهتمام الباحثين" 15:07:00 <zzz> توسيع الشبكة يعني مجموعة كبيرة جداً من الأمور — راجعوا الموضوع 15:07:09 <str4d> نعم، أظن أنني ذكرت ذلك في الموضوع 15:07:36 <zzz> سنحدّد ما تعنيه هذه قريباً. في هذه اللحظة فلنتفق على ما هو مهم. 15:07:58 <str4d> سهولة الاستخدام مهمة جداً بالنسبة لي، وبرأيي المتواضع تُغذّي المجالين أعلاه 15:07:58 <zzz> كل شيء ممكن إذا واصلنا النمو. بمجرد أن نتوقف عن النمو نموت 15:08:05 <zzz> متفق يا str4d 15:08:41 <str4d> على المدى القريب لزيادة قاعدة مستخدمينا، وعلى المدى الطويل لزيادة حضورنا العام، وسهولة الاستخدام للباحثين، إلخ. 15:09:11 <EinMByte> لاحظ أيضاً أن النمو هو الطريقة الوحيدة لجذب الباحثين 15:09:25 <zzz> المزيد من المستخدمين يجلب مزيداً من المطورين ومزيداً من الباحثين ومزيداً من المحتوى و و و 15:09:37 <EinMByte> الشبكات الكبيرة تكون عموماً أكثر إثارة للاهتمام للدراسة 15:10:05 <EinMByte> إذن أظن أننا جميعاً متفقون على هاتين الأولويتين 15:10:16 <zzz> معظم نمونا في العام الماضي كان من Vuze. وهذا رائع لكنني سأحب أن نحصل على مزيد من النمو "الأصيلي" أيضاً 15:10:43 <zzz> لكن ربما يكون النمو في التطبيقات المدمجة، أو التركيز على التطبيقات عموماً، هو المسار الأسهل للنمو 15:10:48 <str4d> نعم 15:11:04 <EinMByte> zzz: بالنسبة لكثيرين، من الأسهل استخدام تطبيق يشغّل I2P في الخلفية ويتولى تهيئته نيابةً عنهم 15:11:12 <sadie> مرحباً - تأخرت قليلاً 15:11:20 <zzz> مرحباً sadie سعدتُ بوصولك 15:11:23 <str4d> وهذا، برأيي المتواضع، سيأتي من تحسينات سهولة الاستخدام لكل من واجهة المستخدم UI وواجهات البرمجة APIs 15:11:42 <str4d> وقد بدأنا بالفعل العمل على الأخيرة في مواضيع مختلفة 15:11:48 <zzz> بوجهٍ ما، التطبيقات هي خبراء واجهة المستخدم؛ دعوها تُضمّن i2p وتُظهره (أو تُخفيه) كما تراه أنسب 15:11:58 <str4d> ممم 15:12:08 <EinMByte> str4d: هذا حل مختلف للمشكلة نفسها، نعم. وأنا أحبّه أكثر لأن تضمين I2P مع كل شيء لا يتوسع جيداً برأيي المتواضع 15:12:30 <str4d> هذا تقريباً النهج الذي اتبعته مع Android 15:13:04 <EinMByte> يجب أن تكون هناك طريقة لضمان ألا يمتلك الناس نسخة I2P منفصلة لكل تطبيق 15:13:12 <zzz> حسناً، أي شيء آخر في 1) أم ننتقل إلى النظر في خارطة الطريق نفسها؟ 15:14:00 <str4d> أظن أن الجميع هنا يبدو في اتفاق تقريبي 15:14:08 <str4d> (لا معارضة على الأقل :P) 15:14:14 <zzz> دعوني أنسخ الأسطر من الموضوع. ليست نصوصاً مقدسة، فقط للمرجع 15:14:25 <zzz> توسيع الشبكة 15:14:25 <zzz> يشمل: التسويق، المشاريع المشتركة، تضمين مزيد من الأشياء، مساعدة الآخرين على تضمين i2p، سهولة الاستخدام، تحسينات الموقع، المزيد من الترجمات، محاضرات وعروض، مقالات وقصص، UI، Android، تطبيقات Android، تحسين التحايل على الجدار الناري العظيم (GFW)، orchid، مزيد من المكتبات والأدوات لمطوري العملاء، دعم أفضل للمواقع الضخمة، دعم تطوير router بديل، تحالفات، تسريعات وكفاءة، السعة، زيادة الحدود، الدخول 15:14:25 <zzz> إلى Debian، ... 15:14:25 <zzz> زيادة الأمان 15:14:25 <zzz> يشمل: ترحيل التشفير، بروتوكول الاشتراك، بروتوكولات نقل جديدة، نقلات قابلة للإضافة (pluggable transports)، LS2، NTCP2، DH جديد، إلغاء المفاتيح، تخزين المفاتيح، مراجعة الشفرة، Sybil، إصلاحات علل، التسمية، SSL، ... 15:14:46 <zzz> حسناً، لننتقل إلى 2) خارطة الطريق نفسها 15:15:10 <zzz> الرابط هو http://i2p-projekt.i2p/en/get-involved/roadmap 15:15:50 <zzz> .25 شبه منتهٍ، الإصدار خلال نحو 10 أيام، فلننظر إلى الإصدارات الأربعة التالية 26-29 لهذه السنة 15:16:00 <zzz> والتي ينبغي أن تأخذنا حتى ccc 15:16:15 <EinMByte> إذا كان شيء ما تحت 2017 مثلاً، هل يعني ذلك أننا سنبدأ النظر فيه حينها فقط، أم يعني أننا سنبدأ التنفيذ عند تلك النقطة؟ 15:16:41 <str4d> من حيث الأشياء التي نحتاج فعلاً إلى القيام بها، سأضع ترحيل التشفير وعمل Sybil في مرتبة عالية 15:16:42 <zzz> 1mb، بالتأكيد نريد البدء بأمور 2017 الكبيرة الآن، مثل تشفير/‏DH جديد، ntcp2، إلخ 15:17:04 <EinMByte> أيضاً، هجمات Eclipse مشكلة حالياً، برأيي المتواضع 15:17:05 <zzz> لذا يمكن أن تتضمن خارطة الطريق أعمالاً تحضيرية لذلك 15:17:23 <str4d> EinMByte، نعم، كنت أضمّن ذلك تحت Sybil 15:17:36 <EinMByte> فكرة التدوير عند منتصف الليل لا تعمل وينبغي أن تكون هناك بدائل أفضل، على ما أظن 15:17:52 <zzz> متفق 15:18:05 <EinMByte> str4d: بالتأكيد، من المعقول تصنيفها كنوع الهجوم نفسه 15:18:44 <str4d> EinMByte، ناقشت هذا مع بضعة أشخاص في RWC 15:18:48 <str4d> لدي بعض الأفكار، لكن يصعب مناقشتها هنا 15:18:51 <EinMByte> zzz: إذا أردنا البدء بـ NTCP2/‏... بحلول 2017 فسنحتاج لتخطيط أعمال تمهيدية 15:18:58 <zzz> صحيح يا 1mb 15:19:02 <str4d> نعم 15:19:20 <str4d> أريد أن يكون التخطيط والبحث على خارطة الطريق :) 15:19:28 <zzz> المشكلة هي أنني يفترض أن أعمل على 26 الآن ولا أعرف ما الذي فيه 15:19:39 <orignal_> هل يمكن إضافة حشو عشوائي إلى NTCP الحالي؟ 15:20:01 <str4d> orignal_، لا أذكر ذلك، لكن تحقق من موضوع NTCP2 15:20:02 <zzz> لذا فلنقضِ 10 دقائق في التخطيط لـ 26، ثم ننتقل إلى المدى الأطول 15:20:13 <str4d> حسناً 15:20:14 <zzz> أخبروني ما الذي ينبغي أن أفعله اليوم 15:20:30 <EinMByte> صحيح، لنركّز على ذلك أولاً 15:20:34 <zzz> حسناً لنرَ ما الموجود في قائمة 25 ولم يحدث 15:20:50 <zzz> الـ wrapper لم يحدث، kytv غائب 15:20:54 <EinMByte> "تحسينات التشفير" عامة جداً 15:21:12 <zzz> ما حدث فعلياً ضمن تحسينات التشفير كان بعض التسريعات لـ 25519 15:21:34 <zzz> لذا قائمة .25 كلها موجودة فعلياً باستثناء الـ wrapper 15:22:00 <zzz> لكن هناك المزيد لفعله بخصوص Sybil فلنبقِ ذلك على قائمة 26 15:22:08 <str4d> رائع 15:22:25 <str4d> أرجأنا GMP 6 إلى .26 بسبب الحاجة إلى مزيد من الاختبارات 15:22:35 <zzz> ما الذي يجب إبقاؤه في قائمة 26 الآن وما الذي ينبغي نقله 15:23:05 <EinMByte> منع Sybil في النهاية سيستغرق على الأرجح الكثير من العمل، لذا يبدو لي أمراً طويل الأمد 15:23:10 <EinMByte> (بالمعنى أننا نحتاج مراجعة أدبيات جيدة أولاً) 15:23:15 <zzz> orignal، نعم، ntcp مع حشو هو ntcp2 15:23:21 <str4d> EinMByte، أداة كشف Sybil لا تُستخدم لأي شيء بعد، وهنا نحتاج مزيداً من التخطيط :) 15:23:49 <zzz> hottuna4 غير متاح لمدة شهر، لست متأكداً متى ينتهي هذا الشهر، لذا gmp6 قد يدخل أو لا يدخل 26 15:24:02 <str4d> حسناً 15:24:37 <str4d> تحسينات بروتوكول الاشتراك لـ addressbook: سيكون من الجيد جداً إضافتها بأسرع ما يمكن، بحيث يتمكن مالكو الـ Dest القديمة من الانتقال إلى Ed25519 15:24:37 <EinMByte> أعتقد أن CRLs لا تحتاج في الواقع إلى علامة استفهام 15:24:47 <str4d> لكن كم سيستغرق تنفيذ ذلك فعلياً؟ 15:25:14 <zzz> سنحتاج إلى تحديث حالة من tuna قريباً، أتوقع أن الموعد النهائي لدفع الأشياء الكبيرة لـ 26 سيكون أواخر مارس/الأسبوع الأول من أبريل 15:26:10 * str4d لا يزال لا يفهم تماماً موضوع CRL، هل يمكن لـ zzz التوسّع؟ 15:26:14 <zzz> سيتضمن .25 القدرة على قراءة قوائم إلغاء الشهادات (CRLs) من القرص، لذا يمكننا تضمينها في التحديث 15:26:35 <zzz> لكن هذا ليس مفيداً جداً لأننا في تحديث يمكننا ببساطة إزالة الشهادة وهذا يفعل الشيء نفسه 15:26:56 <zzz> لذا لإيصال CRLs إلى الناس دون الحاجة إلى تحديث، سنضعها في الخلاصة 15:26:57 <str4d> أحاول فقط فهم حالة الاستخدام 15:27:09 <zzz> حالة الاستخدام هي عندما يتعرض أحدهم للاختراق 15:27:20 <str4d> ألا نزال لا نستخدم تثبيت الشهادات (certificate pinning)؟ 15:27:30 <zzz> لا 15:27:56 <zzz> لقد أنجزت 90% منها وبقي أن أُدرج الـ CRL داخل مساحة الأسماء 15:28:46 <zzz> تثبيت الشهادات أمر معقد وخطِر 15:29:05 <zzz> قام CryptoCat بما يشبه "الانتحار بالتثبيت" 15:29:17 <zzz> حيث كانت الشهادات مُثبّتة لكن تغيّر وسيطٌ معتمد 15:30:49 <zzz> لا أظن أن التثبيت يحل محل cls 15:30:51 <zzz> crls 15:31:21 <zzz> CRLs ليست فقط لأجل SSL، هناك مفاتيح reseed والتحديث 15:31:58 <zzz> هل يمكن إبقاء CRLs على قائمة 26 إذن؟ إنها شبه منتهية 15:32:20 <str4d> ما يقلقني بخصوص التثبيت هو أن أحدهم قد ينفّذ شيئاً شبيهاً بـ Quantum Insert لإعادة توجيه اسم نطاق reseed، ويضع أي شهادة SSL صالحة تُلبّي متطلبات اسم النطاق، وستقبلها routers 15:33:05 <str4d> وبخصوص CRLs، إذا استخدمناها لتعطيل شهادة معيّنة، بماذا ستُستبدل تلك الشهادة؟ 15:33:25 <zzz> لا شيء. في الإصدار التالي سيكون هناك على الأرجح بديل 15:33:45 <str4d> نحن نخوض في التفاصيل الدقيقة هنا 15:34:07 <str4d> أظن المقصود أننا بحاجة إلى مزيد من التفكير بهذا 15:34:24 <zzz> حسناً، لنُبقِ CRLs لـ 26 لكن لنتناقش التفاصيل خلال الأسبوع أو الأسبوعين المقبلين 15:34:30 <zzz> لأنه ليس واضحاً 100% 15:34:38 <zzz> ننتقل 15:34:42 <zzz> ما الذي بقي في قائمة 26 15:34:43 <str4d> حسناً 15:34:50 <EinMByte> حسناً 15:35:08 <zzz> بروتوكول الاشتراك 15:35:28 <zzz> هذا مفتاح ترحيل التشفير للمواقع 15:35:40 <EinMByte> بديل لـ hosts.txt أم ماذا تقصد؟ 15:36:22 <zzz> نعم، هذا جعل hosts.txt على شكل خلاصة، مع شيء مثل foo.i2p=b64#sig=b64#cmd=alt ... 15:36:26 <str4d> EinMByte، تعديل بروتوكول اشتراك addressbook ببيانات وصفية موقّعة من نوع مفتاح-قيمة 15:36:49 <zzz> المقترح شبه مُحدد، لكنه مُعلّق منذ نحو 18 شهراً 15:37:07 <EinMByte> بالتأكيد، ألا يكبر حجم ملف hosts كثيراً؟ 15:38:02 <EinMByte> ربما نضيف معلمة since، لاستبعاد كل المضيفين المُدرجين قبل وقت معيّن 15:38:07 <EinMByte> (لتفادي تنزيل القائمة كاملة حتى إن لم يكن ذلك مطلوباً) 15:38:22 <zzz> كان هذا أصلاً جزءاً من خطة ترحيل التشفير لكنه كان صعباً ولم يكن الجزء الأهم 15:38:49 <zzz> لكنه الأمر الرئيسي المتبقي في ترحيل التشفير للتواقيع 15:39:26 <str4d> EinMByte، لدينا ذلك نوعاً ما عبر etag 15:39:28 <zzz> هذا أيضاً من تلك الأمور المُقترَحة مع الكثير من التفاصيل، لكن لم نحصل على اتفاق لذا لم نبدأ 15:39:42 <EinMByte> str4d: لكن هل يُستخدَم؟ 15:39:46 <str4d> EinMByte، نعم 15:40:00 <EinMByte> أوه، لا بأس. في هذه الحالة 15:40:03 <str4d> لن يختلف هذا عن الإعداد الحالي 15:40:20 <zzz> إذن سنضعه على قائمة 26 وسنبدأ به بأسرع ما يمكن. لست متأكداً إن كنا سنمضي فيه بعيداً بما يكفي لـ 26 لكنني سأحاول. نحتاج إلى مراجعة الموضوع على zzz.i2p 15:40:22 <str4d> لكن بدلاً من عدم تكرار إدخالات أسماء النطاقات، ستتكرر الآن في "stream" 15:40:42 <EinMByte> هل هناك سبب محدد للاحتفاظ بالتنسيق الغريب؟ 15:41:05 <EinMByte> يبدو أسهل لي لو استخدمنا شيئاً معيارياً 15:41:06 <zzz> ربما. التوافق مع العملاء القدامى. لكن علينا المراجعة والحسم إن كان ذلك مهماً 15:41:20 <zzz> لم ينظر أحد منا إلى هذا منذ نحو عام 15:41:28 <zzz> إذاً سننفض الغبار عنه ونلقي نظرة 15:41:32 <EinMByte> zzz: يمكن التعامل مع التوافق عبر توفير ملف hosts.txt القديم لفترة أيضاً 15:41:41 <str4d> هناك أيضاً قضية أوسع: ماذا نفعل مثلاً بكل الأسماء "الضائعة" 15:41:53 <str4d> لكن هذا خارج النقاش الحالي 15:41:57 <zzz> صحيح. سنحتاج أيضاً لإشراك التطبيقات الأخرى 15:42:18 <EinMByte> str4d: أعتقد أن هذا شيء نقرره عندما نحصل على نظام تسمية جديد (إن حصل) 15:42:26 <str4d> حالياً، أريد طريقة تُتيح للنطاقات النشطة حالياً تحديث dests الخاصة بهم 15:42:26 <zzz> حسناً، سيبقى في قائمة 26 حالياً. التالي في القائمة — أمور Sybil 15:42:45 <zzz> هل يمكن جعل Sybil تلقائياً؟ آمل أنكم جميعاً قرأتم ورقة Philip Winter؟؟؟؟ 15:42:50 <str4d> وكلما أسرعنا في إدخال الشيفرة الأساسية، تمكنا من تشغيلها خلال عام أو نحو ذلك 15:43:50 <EinMByte> zzz: أي ورقة؟ فاتني شيء بوضوح 15:44:27 <zzz> تحقق من @__phw على تويتر للحصول على الرابط 15:45:02 <zzz> نحن نعمل معه بفضل تعريف من sadie في ccc 15:45:03 <EinMByte> zzz: هذا: http://arxiv.org/pdf/1602.07787v1.pdf? 15:45:27 <zzz> إذا نُشرت خلال الأسبوعين الأخيرين، فهي المقصودة 15:45:59 <EinMByte> حسناً، إنها نسخة إلكترونية من فبراير هذا العام 15:46:09 <zzz> لا أعتقد أننا جاهزون للتلقائي. وهم أيضاً ليسوا كذلك فعلياً 15:46:22 <zzz> هم فقط يرسلون بريداً إلكترونياً مرةً يومياً إلى الـ dirauths 15:46:36 <zzz> الأمر كله حدسي وسحري من الجانبين 15:46:49 <EinMByte> إذًا ربما وضع النسخة الإلكترونية على الإنترنت بعد نشرها 15:46:57 <zzz> لذا أود تأجيل الأمور التلقائية إلى وقت لاحق هذا العام 15:47:07 <str4d> EinMByte، 25 فبراير هي النسخة التي لدي 15:47:14 <EinMByte> zzz: فكيف سيعمل ذلك تحديداً في بيئة لا مركزية؟ 15:47:44 <str4d> نحتاج للانطلاق من الأسفل إلى الأعلى بدلاً من العكس 15:48:06 <str4d> أي أن كل router سيحتاج لإدراج "مرشحي Sybil المحتملين" ضمن ملفات تعريف النظراء 15:48:13 <zzz> EinMByte، لا أعلم. الأمر صعب 15:48:20 <str4d> استناداً إلى مثلاً أوقات الاتصال، إلخ. 15:48:30 <EinMByte> أعتقد أن كشف هجمات سيبيل (Sybil) ممكن، لكن منعها بناءً على ذلك الكشف صعب جداً في شبكة لا مركزية 15:48:30 <EinMByte> لكني أحب التحدّي 15:48:34 <zzz> نحتاج أيضاً إلى gravy الذي يعمل على إعادة تصميم مركزي لإعداده 15:48:43 <str4d> هناك أيضاً إمكانية وجود نوع من الإعداد الأكثر مركزية 15:48:45 <str4d> نعم، هذا 15:48:45 <EinMByte> str4d: في تلك المرحلة ستحتاج لبدء إسناد الثقة لكل router 15:48:52 <EinMByte> وهو بحد ذاته سيكون نظاماً كاملاً مضاداً لـ Sybil 15:49:07 <str4d> وجعل routers تشترك بقائمة Sybil المحتملة 15:49:07 <zzz> أشبه بمقترحات dagon 15:49:09 <str4d> EinMByte، هذا في الأساس ما تمثله ملفات تعريف النظراء الآن 15:49:31 <str4d> حيث تُعرّف "الثقة" حالياً بأنها "مرّر لي جيداً بشكل موثوق في الماضي" 15:49:42 <EinMByte> str4d: نعم، وقد تسببت ببعض الهجمات حتى الآن :) 15:50:15 <str4d> نعم 15:50:23 <EinMByte> أيضاً، ملفات تعريف النظراء لا تتيح لك حقاً استبعاد نظير من الشبكة 15:50:31 <EinMByte> منع Sybil سيسمح بذلك نوعاً ما 15:50:35 <str4d> تصنيف/نمذجة النظراء واختيار النظراء من الأمور التي أرى أنها تحتاج أولوية 15:50:46 <str4d> EinMByte، يمكنها ذلك 15:51:01 <zzz> لذا أقترح تغيير بند Sybil في 26 إلى "تحسين مستمر" لكن نقل الجزء "التلقائي" إلى وقت لاحق 15:51:01 <str4d> ليس الآن 15:51:11 <str4d> أقول فقط أن هذا هو المكان الذي سنضعه فيه 15:51:34 <EinMByte> str4d: نعم، هذا ممكن. 15:51:37 <str4d> (من حيث إدخال كشف Sybil وتقنيات أكثر تقدماً في قاموس I2P وبنيته) 15:51:53 <EinMByte> على أي حال، لن أتخلى عن اللامركزية. إنها أجمل ما في I2P برأيي المتواضع 15:52:14 <str4d> نعم 15:52:27 <EinMByte> (كما أن المركزية تؤدي أيضاً إلى شتى الهجمات العملية على أي حال) 15:52:43 <zzz> لننتقل. تحسينات streaming؟ لست متأكداً مماهية ذلك، ربما هو بند دائم "لجعله أفضل" 15:52:49 <str4d> zzz، نعم، يمكننا مواصلة العمل على تلك صفحة routerconsole، ثم ربطها بملفات تعريف النظراء والاختيار بعد أن نقرر استراتيجية 15:53:00 <zzz> لا يخطر ببالي شيء محدد لفعله في streaming. أحد لديه اقتراح؟ 15:53:01 <EinMByte> أحياناً إضافة سلطة مركزية قد تجعل برهان الأمان أسهل، لكنها تتسبب بفشل أمني عملياً 15:53:20 <str4d> البحث والتحسينات سيكونان جيدين 15:53:28 <EinMByte> zzz: أي تحسينات واضحة يمكننا القيام بها هناك؟ 15:53:30 <str4d> سيكون ذلك مرشحاً جيداً لبحث خارجي 15:53:46 <zzz> نحتاج فعلاً إلى بيئة اختبار أفضل 15:53:51 <EinMByte> str4d: أتفق. 15:53:55 <zzz> إضافة تأخير/فقد حزم، إعادة ترتيب، إلخ. 15:54:04 <EinMByte> ربما ينبغي توسيع صفحة "أسئلة البحث المفتوحة" لدينا بذلك وبأمور أخرى 15:54:40 <zzz> ليس لدي أفكار "طموحة" كثيرة على قائمة أمور streaming. يجب أن تكون مدفوعة بنتائج الاختبارات 15:54:50 <EinMByte> قد يكون هناك المزيد من التحسين في تخصيص tunnels؟ 15:55:05 <str4d> zzz، هناك مشروع على GH يحاكي "الإنترنت" عبر حاويات يمكنها فعل ذلك إن لم تخنّي الذاكرة 15:55:08 <zzz> ما رأيكم أن نجعل هذا البند "منظومة اختبار streaming" 15:55:17 <str4d> لا أعرف مدى سهولته، سنحتاج إلى JVM جديدة لكل حاوية :P 15:55:25 <str4d> EinMByte، ممم 15:55:48 <EinMByte> str4d: يمكن استخدام shadow، على ما أظن. لست متأكداً إن كان يمكن دمجه مع Java لكنه على قائمة TODO الخاصة بـ kovri 15:55:52 <str4d> هذا ليس streaming حقاً، هذا على مستوى datagram 15:56:22 <zzz> موضوع تخصيص tunnel هو فكرة psi بأن يقوم الـ client باختيار tunnels 15:56:34 <EinMByte> str4d: نعم، أظن أن هناك المزيد لتحسين هذا 15:56:46 <EinMByte> zzz: لا أظن أن المستخدمين هم أفضل خوارزميات تحسين، لكن ربما 15:57:10 <zzz> إنه فساد عنيف لطبقاتنا، ولا أرى طريقة لفعل ذلك. لكن هذا ما يقترحه psi 15:57:19 <EinMByte> ... أو ربما "client" لا يعني المستخدم 15:57:32 <zzz> client == الجانب العميل من I2CP 15:57:44 <str4d> الأمر هناك هو 15:57:54 <str4d> Tor يوفّر هذه القدرة عبر Control Socket الخاص بهم 15:57:58 <EinMByte> حسناً إذاً هو يعني ذلك 15:57:59 <str4d> وهو مفيد جداً للباحثين 15:58:10 <str4d> لكن لديهم أيضاً بنية أكثر تسطيحاً بكثير 15:58:19 <str4d> بينما نعزل العملاء المختلفين عن بعضهم عبر I2CP 15:58:31 <EinMByte> zzz: أتوقع أن يمتلك router معلومات أكثر صلة. يمكن للـ client تمرير أي متطلبات إضافية 15:58:41 <zzz> لدينا أيضاً hooks بـ Lua من psi للباحثين، لم تُدمج أبداً (لا في Java ولا في kovri)، لكنها ما تزال خياراً 15:59:14 <zzz> حالياً، الجانب العميل لا يعرف حتى عن tunnels، لذا بالتأكيد ليست لديه القدرة على اختيارها 15:59:16 <str4d> بالحديث مع nickm في RWC، قال إن من الأسهل بكثير على Tor الحفاظ على واجهة Control Socket من نظام إضافات 15:59:17 <EinMByte> أعلم أن shadow يُستخدم عملياً من قبل الباحثين 15:59:22 <EinMByte> Lua، لا أدري 15:59:55 <EinMByte> zzz: ربما يمكن تحقيق الشيء نفسه بتمرير المعلومات ذات الصلة عبر I2CP؟ 16:00:17 <zzz> 1mb، نعم، لكن سيكون قبيحاً حقاً 16:00:44 <str4d> يمكننا دائماً تقييده بعَلم ‎-research أو ما شابه 16:00:54 <str4d> (في router.config) 16:01:06 <str4d> وبهذا لن يتعرّض معظم المستخدمين لتلك القباحة 16:01:13 <zzz> kovri/i2pd لا يمتلكان بعد تلك الحواجز الصارمة في API بين client/router، الأمر أسهل لـ 16:01:20 <zzz> *them 16:01:28 <str4d> ويمكننا تعريف ".research" منذ البداية ليعني "نحتفظ بحق تغيير هذه الـ APIs" 16:01:44 <str4d> أي سيحتاج الباحثون لاستخدام علم .research مع نسخة معينة 16:01:57 <str4d> عودةً إلى موضوع النقاش الفعلي: 16:01:59 <EinMByte> zzz: بخصوص tunnels. يعتمد الأمر. أظن أنه سيكون من المنطقي تمرير معلومات عن الاستخدام المقصود للـ tunnel. 16:02:20 <zzz> (للعلم هذا الاجتماع سيستمر 25 دقيقة كحد أقصى، على أن يُستكمل الأحد) 16:02:33 <EinMByte> zzz: هو أسهل لنا أساساً لأن shadow مكتوب بلغة C، على ما أظن 16:02:42 <str4d> أرى أنه ينبغي دفع هذا إلى فئة "يحتاج إلى المزيد من البحث" 16:02:44 <zzz> المشكلة أنه ليس فقط tunnels الخاصة بك التي تحتاج اختياراً بل أيضاً tunnels للطرف البعيد 16:02:48 <EinMByte> حسناً. دعونا نتابع إذاً. 16:03:08 <zzz> حسناً هذا كل ما في قائمة 26 الآن. ماذا ينبغي إضافته؟ 16:03:11 <EinMByte> zzz: ألا يتولى الطرف البعيد ذلك؟ 16:03:36 <zzz> لا، نحن نقوم بالـ source-route (أي نختار الـ lease للطرف البعيد من الـ leaseSet لديه لجهة inbound) 16:04:08 <zzz> انظروا إلى قائمة 27-29. ما الذي يجب سحبه إلى 26 إن وُجد؟ 16:04:44 <str4d> أريد البدء بإنجاز الأعمال التحضيرية لـ LSs جديدة و netDb 16:04:46 <zzz> هنا حيث يوجد كل "العمل الأولي على xxx لعام 2017"، ولكن أيضاً الكثير من أمور 2016 16:05:23 <EinMByte> zzz: أسأتُ فهم قصدك بـ far-end، لا بأس 16:05:31 <str4d> كلما أسرعنا في تثبيت ذلك وإدخاله في قاعدة الشيفرة، حصلت الشبكة على دعم واسع له أسرع 16:06:42 <EinMByte> لاحظ أننا (kovri) نريد مواصفات 16:06:52 <EinMByte> وإلا فسيصعب مواكبة التنفيذ 16:07:31 <zzz> بالتأكيد. أي شيء هو مواصفة جديدة، نحتاج جميعاً للعمل عليه معاً 16:07:36 <EinMByte> str4d: لنبدأ بسرد ما الذي ينبغي أن يدعمه LS2 فعلياً 16:07:53 <EinMByte> (إن لم يكن ذلك قد تم بالفعل) 16:09:40 <zzz> أساساً LS2 هو مجرد بضعة أمور 16:09:59 <zzz> إضافة بعض الحقول للأعلام (flags) 16:10:09 <zzz> وتمكين التشفير المستقبلي 16:10:52 <zzz> لكن لدي كل تلك المقترحات حول multihoming أفضل، إضافةً إلى آلية استعلام عن الخدمات على طريقة Grothoff 16:11:00 <zzz> Anycast 16:11:01 <EinMByte> هل لدينا قائمة محددة في مكان ما للرجوع إليها؟ 16:11:11 <zzz> هي مُجمّعة على zzz، لحظة 16:11:23 <str4d> أعمل ببطء على جمع كل ذلك على الموقع 16:11:41 <zzz> هل يمكننا تسريع ذلك يا str4d؟ خلال الأسبوع القادم أو الذي يليه؟ 16:11:47 <str4d> يجب أن يدخل ذلك في قائمة .26 16:11:50 <str4d> همم 16:11:53 <str4d> ربما 16:11:59 <str4d> أحتاج لمزيد من العيون عليه 16:11:59 <zzz> بدون المقترحات على قائمة بسيطة سيصير هذا صعباً جداً 16:12:08 <EinMByte> str4d: رائع. فعلياً، لبعض هذه الأمور ستكون وظيفة ويكي مفيدة 16:12:24 <EinMByte> (الفكرة أنها ستُسرّع العمل) 16:12:48 <zzz> للبدء نحتاج إلى قائمة 16:12:50 <str4d> EinMByte، بالضبط 16:12:56 <zzz> لا نحاول حل كل شيء دفعة واحدة 16:13:11 <str4d> أحاول الانتقال من الحاجة إلى HTML في الخلفية إلى rST (حالياً) 16:13:31 <str4d> أحتاج أن يطّلع الناس على ما لدي للتحقق من: أ) أنه قابل للاستخدام وب) أنه لا يفقد أي شيء نمتلكه حالياً 16:13:39 <str4d> حالياً يُطبَّق على وثائق المواصفات فقط 16:13:40 <zzz> لنضع موضوع المقترحات على قائمة 26 وسنتحدث لاحقاً عما يعنيه ذلك. لكننا بحاجة إلى تقدم فيه بأسرع وقت. 16:13:55 <str4d> وبمجرد أن يترسخ ذلك، سيكون توسيعه ليشمل المقترحات تافهاً 16:13:56 <zzz> أريدها على الموقع. لا أهتم بالشكل. 16:14:46 <EinMByte> أنا مستعد لمراجعة المقترحات، لكن يحدث أحياناً أني لا أجد أي نص 16:15:10 <EinMByte> (أعتقد أن بعض الأشياء على الموقع مخفية نوعاً ما) 16:15:37 <zzz> صحيح 16:16:05 <zzz> نحتاج لنقل الأشياء من zzz.i2p إلى الموقع بتنظيم ما 16:16:13 <EinMByte> str4d: الانتقال من HTML إلى شيء يمكن تحويله بسهولة إلى صيغ متعددة أمر جيد 16:16:28 <EinMByte> zzz: نعم، بالتأكيد 16:16:35 <str4d> ما أحتاج مراجعته موجود في i2p.www.str4d 16:16:36 <EinMByte> ربما عملية ثابتة لجميع المقترحات 16:16:57 <zzz> حسناً. هو على قائمة 26. التفاصيل ستأتي. str4d ابدأ العمل. لا أتوقع الكثير من التغذية الراجعة. فقط ابتكر نظاماً جديداً وسنلتزم به جميعاً 16:17:02 <str4d> وأيضاً على http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/ 16:17:04 <str4d> EinMByte، إن أردت العمل معي على إحكام ذلك، قد أتمكن من إنهائه ربما بحلول .25 16:17:23 <zzz> ماذا أيضاً لـ 26؟ علينا إنهاء هذا 16:17:36 <str4d> ( EinMByte، http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec بالتحديد) 16:18:14 <zzz> هذه أمور قصيرة المدى جداً. أحتاج أن أعرف ما الذي سأفعله يوم الاثنين 16:18:27 <zzz> النداء الأخير لـ 26 16:18:41 <str4d> أظن أن أمور الاشتراكات ستستغرق وقتاً 16:18:49 <str4d> لذا سأكون راضياً بأن يكون ذلك هو الشيء الرئيسي 16:18:52 <zzz> متفق. 16:19:54 <zzz> حسناً. الاجتماع يوم الأحد في نفس الوقت. سنبدأ بـ vrp/h1. يرجى مراجعة التذكرة 1119 مسبقاً. بعد ذلك سنتحدث عن 27-29 إن سمح الوقت. 16:20:06 <EinMByte> str4d: أي من هذه تعتقد أنها تتطلب أكبر قدر من الاهتمام؟ 16:20:27 <zzz> يمكننا أيضاً العودة بإيجاز إلى 26 يوم الأحد إذا لزم الأمر 16:20:43 <str4d> EinMByte، الخلاصة: تقرير ما إذا كان تنسيق كتابة المقترحات قابلاً للاستخدام، وهل يحد مما ينتهي على الموقع (بصيغة HTML أو TXT) 16:20:45 <zzz> إذن جدول الأحد سيكون: 1) vrp/h1/1119؛ 2) 26؛ 3) 27-29 16:20:57 <zzz> شكراً للجميع 16:21:25 * zzz *bafs* أُغلِق الاجتماع 16:27:50 <EinMByte> str4d: ربما يكون مناسباً طالما يمكن تحويله إلى معظم الصيغ الأخرى :)