اجتماع مطوري 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> مع أني لا أظن أن هناك مجموعة إخفاء هوية كبيرة هناك 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> هه، حسناً. أساساً الدافع وراء إحصائيات حجم الرسائل تلك هو استكشاف مسائل padding (حشو البيانات) 13:14 <jrandom> للأسف، الاستراتيجية التي بنيتها بانتقاء أرقام عشوائياً كانت سيئة، إذ أعطت حملاً إضافياً بنسبة 25% بسبب padding فقط 13:14 <jrandom> إذا أخذنا بأحد المقترحات لتشفير 0.5 (tunnels-alt.html)، فلن تكون لدينا تلك المشكلة 13:15 <jrandom> (لأنه سيفرض أحجاماً ثابتة صغيرة مع التجزئة) 13:15 <mule> أي نوع من الرسائل تريد عمل padding له، تلك التي يراها الـrouter أم تلك التي يراها مراقب خارجي؟ 13:15 <jrandom> mule: سؤال مهم 13:15 <jrandom> إن كنا نقلق فقط من المراقب الخارجي، يمكننا ترك الرسائل دون padding، وإجراء أي توليد للتشويش في طبقة النقل 13:16 <Teal`c> http://microsoft.i2p/david_hasselhoff_05_christmas_album__silent_night.mp3 13:16 <jrandom> ومن ناحية أخرى، إن كنا نقلق من قيام مشاركي الـtunnel بتحليل التدفق، فعلينا أن نهتم بالـpadding داخل الـtunnel 13:16 <@duck> مع 5-6 قفزات، ما مدى خطورة قيام router بتحليل المرور؟ 13:16 <cervantes> Teal`c: اجتماع الآن... هل يمكنك استخدام #i2p-chat للإعلان عن mp3 ;-) 13:17 <Teal`c> آسف 13:17 <cervantes> :) من أجل ديفيد هاسلهوف؟ 13:18 <jrandom> يعتمد على مستوى التحليل يا duck. إذا كانوا قد تتبّعوا بطريقة ما أي tunnel هم فيه (مثلاً هم بوابة الـtunnel الوارد وقد جمعوا الـnetDb وقرنوه بوجهة)، فهذه بيانات غير بسيطة. ومن ناحية أخرى، ليست كشفاً مباشراً، لكنها تعطي بعض المعلومات 13:18 <jrandom> وأكثر من padding الـtunnel هو الـpadding طرفاً لطرف، لإخفاء بيانات تدفق الرسائل عن البوابات ونقاط النهاية. 13:19 <jrandom> لو كنا مجانين/حمقى، يمكن أن نذهب إلى حد pipenet (شبكة بمعدل بت ثابت)، باستخدام معدل ثابت في كل مكان 13:19 <+polecat> فهمت! 13:19 <jrandom> (وننتهي بلا أي مستخدمين يشغّلون i2p) 13:19 <+polecat> ما نحتاج لفعله هو تمرير i2p عبر email! 13:19 <cervantes> ما احتمال أن ينتهي routers متواطئون في الـtunnel نفسه على شبكة كبيرة بما يكفي؟ 13:19 <+polecat> لن يكون هناك مزوّد إنترنت غبي بما يكفي ليحجب البريد الإلكتروني! 13:20 * jrandom ينتظر تنفيذ net.i2p.router.transport.gmail 13:20 <postman> polecat: يا رجل ، هذا سخيف 13:20 <postman> :) 13:20 <bla> cervantes: N^(-h) (‏N هو عدد العُقَد السريعة، ‏h = عدد القفزات). هكذا يبدو 13:20 <+polecat> =3 أعلم. 13:21 <cervantes> هل هذا كثير؟ :) 13:21 <jrandom> ليس عدد العُقَد السريعة، إذ إن الأشخاص الخارجيين لن يعرفوا ملفاتك التعريفية 13:21 <+polecat> لكن بجدية، في إساءة سافرة لخدمات IP القائمة، يمكننا تمرير i2p بطرق مبتكرة عديدة. 13:21 <jrandom> c^2/N^h لوضع نظيرين في الـtunnel نفسه 13:21 <jrandom> مُتّفق يا polecat. هذا أحد أسباب عدم وجود tunnels ثنائية الاتجاه لدينا 13:22 <jrandom> بعض وسائل النقل (مثلاً البريد الإلكتروني) سيئة للاتصال ثنائي الاتجاه 13:22 <bla> jrandom: ‏c = ؟ 13:22 <jrandom> c== عدد النظراء المتواطئين 13:23 <+polecat> همم، نقطة مثيرة. 13:23 <ant> <duck> من ناحية خارطة الطريق، ما أثر ذهاب i2p في اتجاه خاطئ واختيار حل تشفير خاطئ؟ 13:23 <+polecat> أو بروتوكول الحمام الزاجل، ليس ثنائي الاتجاه أبداً. 13:23 <+polecat> التشفير معياري بالفعل، أليس كذلك؟ 13:23 <jrandom> duck: إنه مجرد بند واحد ضمن 0.5، وقسم فرعي واحد من مستند tunnels*.html. هناك الكثير في توجيه الـtunnel أكثر من مجرد كيفية تغليفنا للبيانات 13:24 <bla> jrandom: مرة أخرى، هذه هي المشكلة لإدخالهم في الـtunnel الآن. ومع ذلك، عبر T من تجديدات الـtunnel (كل عدد من الدقائق)، تصبح على الشكل 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> الخطة هي AES256/CBC القياسي 13:25 <+protokol> سمعتُ أن DNS جيد لتمرير الأشياء، معظم الناس لا يحجبونه 13:25 <jrandom> بالتأكيد يا bla، وإن لم يكن مباشراً تماماً (هو كذلك لـtunnels الاستكشافية، لكن ليس لـtunnels العملاء) 13:26 <+polecat> وإن تم كسر AES بطريقة ما، فسنستخدم خوارزمية تناظرية معادلة. 13:27 <jrandom> bla: لا أظنها مصدر قلق عملي كبير في معظم الحالات إلى ذلك الحد، لكن عندما تُركِّبها كجزء من هجوم السَّلَف (predecessor attack)، تصبح المسألة إلى حد كبير غير ذات صلة 13:28 <jrandom> (بسبب الطريقة التي ننفّذ بها باقي توجيه الـtunnel) 13:28 <bla> jrandom: تمام 13:28 <jrandom> صحيح يا polecat 13:29 <jrandom> duck: إن أخذنا بالخيار الثاني، فالتبديل إلى آخر لاحقاً سيكون على الأرجح سهلاً. 13:29 <jrandom> ومن ناحية أخرى، سيتطلب الخيار الثاني بعض ضبط الأداء الجاد كي لا يكون سيئاً 13:29 <jrandom> لكنني واثق أننا سننجح 13:31 <jrandom> على أي حال، أظن أن ما سبق يغطي أين نحن الآن بخصوص عمل 0.5 13:31 <jrandom> هل لدى أحد مزيد من الأسئلة/التعليقات/المخاوف؟ 13:31 <bla> jrandom: واحد 13:32 <bla> jrandom: أظن أننا ينبغي أن نقدّر الإخفاء (anon.) أكثر بقليل من الأداء حالياً (atm): لذا نعم، تبدو خيارات PRNG (مولِّد أعداد شبه عشوائية) جيدة 13:33 <jrandom> مُتّفق. يمكن ضبط الأداء لاحقاً، أما «إضافة» مزيد من الإخفاء فذلك أصعب بكثير 13:33 <jrandom> (لكن، بالطبع، الأداء عامل أمني بحد ذاته. إن كان سيئاً، فلن يستخدمه أحد) 13:33 <bla> نعم. 13:33 <bla> jrandom: 13:33 <bla> عذراً 13:33 <@duck> حسناً، /me يقلب بِت أداء Freenet السحري 13:33 <cervantes> ربما سيُثني ذلك كل أولئك الملوّحين بالتورنت من المُتطفّلين عن الاقتراب فترة أطول ;-) 13:34 <jrandom> هه 13:34 <cervantes> <-- تمت إعادة تعيين الاتصال 13:34 <bla> cervantes: لا، لستُ كذلك! :) 13:34 <cervantes> :) 13:35 <jrandom> أعتقد أننا نستطيع إنجاز تحسينات رائعة فعلاً، ويبدو أن الكثير من عنق الزجاجة لدينا ليس مرتبطاً باختيار النظراء، بل مجرد (هه) علل في jobqueue 13:36 <jrandom> لكن، على أية حال، أي شيء آخر لـ 2) 0.5؟ 13:36 <ant> <BS314159> هل يمكنك نشر شرح لهذا هجوم الحلقة (loop attack)؟ 13:37 <ant> <BS314159> يبدو أخطر مما يوحي به طرحك له 13:37 <jrandom> حلقة: ابنِ tunnel يحتوي على A-->B-->C-->D-->C، وأرسل 10 رسائل. 13:37 <jrandom> من دون PRNGs، يمكنك إضافة ما تشاء من الرسائل إلى تلك الحلقة C<-->D 13:38 <ant> <BS314159> حسناً 13:38 <jrandom> وبفعالية تنفيذ DoS (هجوم حجب الخدمة) على أي routers ببضع رسائل فقط 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> (لكن عندما تستطيع تنفيذ DoS انتقائياً على نظراء بتكلفة قليلة، يمكنك فعل أمور قذرة جداً) 13:40 <ant> <BS314159> فهمت 13:40 <+protokol> وهل ستساعد شهادات hashcash في هذا؟ 13:40 <jrandom> protokol: ‏hashcash تعالج مسألة قيام نظير ببناء عدد كبير جداً من الـtunnels، وربما عدد كبير جداً من القفزات 13:41 <jrandom> protokol: لا تساعد مع الحلقات. الطريقتان اللتان وجدتهما تعملان هما PRNGs (tunnel-alt.html) أو التحقق عند كل خطوة (tunnel.html) 13:42 <jrandom> التحقق عند كل خطوة فيه مخاطر، لذا الميل الحالي هو نحو PRNGs 13:42 <+Ragnarok> إلى أي حد ستكون طريقة PRNG فعّالة؟ 13:42 <Xan> A-->B-->C-->D-->C - ألا ينبغي أن تحصل كل قفزة على معرّف مختلف أو ما شابه، بحيث تغادر الرسائل الـtunnel في المرة الثانية التي تصل فيها إلى C بدلاً من الدوران في حلقة؟ 13:43 <jrandom> Xan: هذا ما يحدث، لكن من دون التحقق عند كل خطوة، لا يمكنك أن تعرف إن كان ذلك سيئاً أم لا 13:44 <jrandom> Ragnarok: أظن أنها ستكون فعّالة جداً في تقليل الضرر الواقع 13:45 <jrandom> على الأقل، مما أراه حتى الآن 13:45 <jrandom> إن رأى أحد أي مشاكل/قضايا فيها، أو اقتراحات لتحسينها، فرجاء التواصل :) 13:46 <Xan> أو ربما فاتتني الفكرة 13:46 <Xan> سأعود لاحقاً 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> يهدف إلى بنية بريد لا مركزية بالكامل في المستقبل 13:50 <postman> لكن يحتاج إلى برنامج وكيل على العُقَد إضافة إلى مجموعة من المرحلات المخصصة 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> <موسيقى مخيفة> 13:53 <jrandom> كما ذُكر في البريد، حصل تقدّم مهم مؤخراً 13:53 <kaji> ثم قالوا إن الهواتف اللاسلكية قد تختل عندما تكون السماعة مرفوعة، لكن كل هواتفي اللاسلكية على الشاحن -> #i2p-chat 13:55 <jrandom> فريق Azureus كان متعاوناً جداً في تجهيز تحديث (يا سلام!)، لكن ينبغي للناس أيضاً ترقّب المشاكل 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 المنشور 14:03 <jrandom> (مثلاً userhosts.txt خاص، وhosts.txt متزامن مع الآخرين وهو عام) 14:03 <cervantes> كجزء من فقرة شبه منتظمة في المنتدى، سيكون هناك تقدير وجوائز لمن قدّموا أشياء جيدة إلى I2P سواء مؤخراً أو على مدار عمر المشروع 14:03 <postman> Ragnarok: بعد التحديث إلى 0.4.2.6 وجدتُ إدخالات من userhosts.txt الخاص بي في addressbook المنشور في مجلد eepsite لدي 14:03 <ant> <BS314159> هممم 14:04 <postman> Ragnarok: كانت تلك مفاتيح أُضيفت يدوياً، ولم يكن من المفترض نشرها 14:04 <cervantes> هذا الأسبوع نُكرِّم duck على تميّزه العام كمقدّم خدمات للمجتمع وكـ«خامل» رائع شامل: http://forum.i2p/viewtopic.php?t=275 14:04 <jrandom> w00t! 14:04 <jrandom> (هيا يا duck هيا، هيا يا duck هيا) 14:05 <Teal`c> وماذا عن اختطاف أسماء النطاقات؟ 14:05 * brachtus يصفّق 14:05 * orion يؤدي مشية البط كعلامة احترام. 14:05 <cervantes> نقطة مهمة للمستقبل... ليس عليك أن تكون عبقري تشفير لتحصل على المديح! 14:06 <+Ragnarok> لا، هذا سلوك متوقَّع. أستطيع تغييره، لكن أولاً عليّ إنهاء تنفيذ قفل الملفات حتى تتمكن من تغيير 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 الخاص بهم؟ 14:08 <jrandom> Teal`c: لا توجد طريقة لاختطاف اسم نطاق، لا يتم الكتابة فوق أي إدخالات، وuserhosts يتفوّق دائماً على hosts 14:09 <jrandom> Ragnarok: ربما يمكن لواجهة الويب معالجة مسألة القفل، بما أن المستخدمين لن يضيفوا إلى الملفات يدوياً 14:09 <+Ragnarok> حالما يتم القفل، لا يوجد سبب حقيقي لجلب العناوين من userhosts.txt بعد الآن (فهو حالياً الطريقة الوحيدة لتفادي سباق)، لذا لا جدوى حقيقية من إضافة ملف ثالث 14:10 <+Ragnarok> jrandom: حسناً، كنت أخطط لاستخدام Java File Locking API 14:10 <jrandom> إن كنت تراه ضرورياً، فأنت صاحب القرار :) 14:10 <ant> <BS314159> سيتيح لك حذف كل الأسماء التي حصلتَ عليها من الآخرين مع إبقاء تلك التي أنشأتها بنفسك 14:10 <ant> <BS314159> ببساطة عبر تفريغ hosts.txt وتغيير اشتراكك 14:11 <ant> <BS314159> لكن أظن أن ذلك يمكن أن ينتظر توقيع الأسماء 14:11 <orion> البيانات الوصفية ستحل هذه المشكلة. هل صيغت مواصفة بعد؟ 14:11 <jrandom> استخدام ملفين فقط ينبغي أن يكون جيداً - واحد تديره addressbook وواحد لا 14:12 <jrandom> (يمكنك حتى جعل addressbook يتجاهل userhosts.txt تماماً - فـ userhosts.txt يتفوّق على hosts.txt على أي حال) 14:12 <+Ragnarok> jrandom: هذه ستكون الخطة، بمجرد إنجاز القفل (والذي حقاً لا ينبغي أن يتطلب عملاً كثيراً، فقط لم أتفرّغ له بعد :) 14:13 <+Ragnarok> وأنا حالياً أعمل على تعلم ما يكفي من مخطط XML لكتابة واحد لـ namerecords 14:13 <ant> <dr_kavra> هل هذه القناة لـ kenosis؟ قناة أخرى قالت لي أن آتي هنا :D 14:13 <jrandom> لول 14:13 <jrandom> لا، آسف، هذه قناة i2p 14:14 <jrandom> (إلا إذا كنت تبحث عن طبقة تواصل مجهولة) 14:14 <jrandom> رائع يا Ragnarok 14:14 <ant> <BS314159> ما زلتُ أرى أن XML مطوّل وغير مقروء للبشر لهذا الغرض، مقارنةً بـ YAML، لكنني لست من يكتب الشيفرة 14:14 <jrandom> Ragnarok: الجزء الصعب سيكون تنفيذ التشفير مع XML دون الرجوع إلى CDATA القبيحة 14:14 <orion> هل كتب أحد مسودة عملية لمواصفة البيانات الوصفية حتى الآن؟ 14:15 <jrandom> (أنا شخصياً أظن أن XML سيئ، لكنني مجرد مُثبِّط) 14:15 <jrandom> orion: http://dev.i2p.net/pipermail/i2p/2004-February/000135.html يحوي إعداداً أساسياً 14:15 <orion> (بيانات وصفية للاسم/المفتاح) 14:15 <dox> هل تم الإعلان عن addressbook وميزاته في مكان ما؟ لم أكن أعلم أن hosts.txt الخاص بي منشور 14:15 <jrandom> (انظر عناصر NameReference وLocalEntry) 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 + تشفير بدون CDATA = ‏MIME، أليس كذلك؟ 14:19 <jrandom> رائع يا orion 14:19 <jrandom> BrockSamson: ‏S/MIME، مع محلّلات مختلفة ;) 14:19 <orion> (وأيضاً واحدة لبيانات الاسم الوصفية) 14:21 <jrandom> هناك طرق كثيرة للتعامل مع البيانات الوصفية، المهم هو المرونة و«الصحة» حتى يمكنها أن تنمو أو تتغير بمرور الوقت 14:21 * jrandom واثق أن Ragnarok وآخرين سيخرجون بأشياء جيدة :) 14:21 <orion> لهذا أعتقد أن مسودة عامة مطلوبة. 14:22 <ant> <cervantes> اتحاد i2p :P 14:22 <jrandom> حسناً، كان الناس يقولون «على أحدهم أن يضع أفكاره على الويكي» خلال الاجتماعات القليلة الماضية، لكن صفحات الويكي لا تنمو كثيراً ;) والذي لا بأس به، نمضي بالوتيرة التي نمضي بها 14:23 * orion يَعِد بأن يطلق ثلاث ويكيات خلال يوم ويرسل للجميع مواقعها عبر البريد 14:23 <BrockSamson> نادِني كسولاً، لكن جرّب مقارنة أمر شراء EDI وفق ANSI 850 بأي أمر شراء مبني على XML، وسأفضل فك الترميز والبرمجة والتنقيح لنسخة XML. حتى لو كانت بحجم أكبر 5 مرات من EDI 14:23 <jrandom> w00t 14:23 <jrandom> هه يا BrockSamson 14:24 <BrockSamson> الموضع 10 هو ST؟ أوه إذن الموضع 310 يجب أن يكون الاسم 14:24 <BrockSamson> يا لغبائي 14:24 <jrandom> BrockSamson: لا أظن أن مخططات XML لأوامر الشراء أفضل بكثير ;) 14:24 <jrandom> (لكن نعم، تلك الأشياء كارثة كاملة الأوصاف) 14:25 <BrockSamson> هي كذلك عند الرابعة والنصف صباحاً 14:25 <BrockSamson> إلا إذا... 14:25 <jrandom> هه 14:25 <BrockSamson> كانت مكتوبة بواسطة مبرمج EDI سابق 14:25 <BrockSamson> ويبدو XML هكذا: <p1><po><q>1</q></po></p1> 14:26 <BrockSamson> أراهن، مع ذلك، لو جمعت ساعات المشاريع مفتوحة المصدر التي تُقضى في الحديث عن «‏XML» أو «ليس ‏XML» لتمكنت من برمجة لينكس عشر مرات. 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*، مختتماً الاجتماع