رسول كل شيء

جميع الرسل الحاليين لديهم إيجابيات وسلبيات ، ولكن كل منهم يسحب البطانية إلى جانبه بسبب عدم التوافق مع الآخرين - ويعاني المستخدمون من ذلك.

يمكن أن يصبح XMPP معيارًا واحدًا ، ولكنه على عكس البريد الإلكتروني ، بدا متأخرًا نسبيًا ولم يتمكن من اكتساب عدد كافٍ من الجمهور بحيث لا تستطيع الشركات رفضه بالفعل. بعد كل شيء ، أدركوا بسرعة أنه بدون الاحتفاظ بالجمهور في نظامهم البيئي الخاص بهم ، فلن يكون هناك الكثير لتربحه. وإلى جانب ذلك ، يجب أن أعترف ، أن XMPP لديها أوجه قصور كافية بسبب وفرة التمديدات ، والتي ظل العديد منها ، على الرغم من أهميتها ، في حالة تجريبية ، وبعضها مكرر تمامًا.

بعد أن عشت في "العالم الرائع الجديد" لعشرات الرسائل الفورية في الهاتف الذكي ، وبعد أن شعرت بكل أوجه القصور في هذه الحالة ، نحن مستعدون أخيرًا لشيء جديد.

ونعم ، نحن بحاجة إلى معيار جديد!

يفي برنامج Future Messenger الممتاز بالمتطلبات التالية: ضمان الموثوقية والأمان ، من خلال التطوير اللامركزي واللامركزية ، قابلية النقل (عبر الأنظمة الأساسية) ، والبروتوكولات المتعددة (القدرة على الاتصال بشبكات الاتصال الأخرى) وسهولة الاستخدام.

لماذا كل شيء سيء للغاية؟

ولكن أولاً ، دعنا نكتشف لماذا لا يتحول الجميع إلى أي شخص مشهور بالفعل == رسول مركزي ، سواء كان تطبيق WhatsApp مشروطًا ، أو على سبيل المثال ، Telegram ، التي لديها جمهور كبير في روسيا.

بالطبع ، يسمح البناء المركزي للمالكين بكسب المزيد من المال ، وبالتالي لا يسددون فقط التنمية ، ولكن أيضًا استثمار أموال كبيرة في الدعاية وحتى تمجيد الوظائف الغائبة عمليًا ، مثل أمان الخدمة ، على سبيل المثال. ومع ذلك ، إلى جانب ذلك ، قد يقرر المالك فجأة إغلاق الخدمة ، أو الجرار لنقل السلك من مركز البيانات ، أو يمكن حظر مجرد رسول في أراضي دولة معينة. ليس بالضرورة لأسباب سياسية ، ربما ، وبناءً على طلب أصحاب حقوق النشر المشروط ، يمكن أن يكون هناك العديد من الأسباب. من الجيد أنه على الرغم من الحجم الضئيل للسوق ، واصلت Telegram العمل في روسيا بنجاح متفاوت ، ولكن هذا يرجع إلى الحسابات الشخصية للمالك ، وفي حالة حظر WhatsApp نفسه ، فمن غير المرجح أن يستثمر Facebook بشكل كبير لتجاوز الأقفال.

من الصعب التحدث فورًا عن جميع الرسل المركزيين ، الذين يجمعون تحت مشط واحد. هناك شر مطلق مع عميل وملقم وبروتوكول خاص يعمل حتى على عدد قليل من أكثر المنصات شيوعًا ولا يوجد لديه أي تشفير. هناك أيضًا جودة نسبية ، على سبيل المثال ، Signal messenger ، وهو مفتوح بالكامل ، لكن الخوادم لا تدعم الوضع المتحد ، وهذا هو السبب في أن الجميع يعتمد على الخادم المركزي مع جميع العواقب المترتبة عليه. هنا ، يجب أن يتم التصنيف وفقًا لمبدأ مختلف ، ولكن هذا يتجاوز نطاق هذه المقالة.

حسنا ، لماذا لا ننتقل إلى شيء اتحادي. على سبيل المثال ، نفس المصفوفة. لن أتحدث عن HTTP Long Polling ، والمرونة الضعيفة للخادم ، والمرح الواضح لواجهة العميل - كل هذه مهام قابلة للحل ، وإن لم تكن تافهة (على المستوى العالمي ، هذا لا يغير أي شيء). يعجبني أن المطورين أخذوا في الاعتبار تجربة XMPP ووضعوا مواصفات مشتركة بدلاً من مجموعة من XEPs المستقلة ، ولكن هذا ليس سوى أحد عيوب XMPP. هناك مشكلة أخرى هي الجهاز الكلاسيكي للشبكة الفيدرالية ، عندما نضطر إلى اختيار خادم ما ونثق في صاحبه أنه سيضمن عمل الخادم ولن يغلقه. وفي حالة حدوث فشل آخر في مركز البيانات ، سيتم فصلنا عن العالم ، ولن نتمكن من التواصل مع الحساب السابق على خادم آخر. حتى إذا قمت بإنشاء حساب جديد ، وقمت بطريقة ما بنقل قائمة جهات الاتصال الخاصة بك إليه من الخادم القديم ، عند الاتصال ، سيكون عليك بطريقة ما أن تؤكد مرة أخرى أنه أنت بالفعل ، وليس شخصًا يقدم لك.

في هذه الحالة ، ربما التخلي تماما عن الخادم؟ هناك عدد من برامج المراسلة الفورية القائمة على تقنية بدون خادم. هناك حالة خاصة هنا هي الأكثر شيوعًا في الدوائر الضيقة Firechat ، والتي تستخدم شبكة شبكة من أجهزة wifi و bluetooth للتواصل مع المستخدمين. يعمل هذا البرنامج بشكل جيد عندما يركز جميع المستخدمين ، على سبيل المثال ، على المنطقة. لكن هذا وضع محدد إلى حد ما ، وحتى إذا تصورنا موقفًا يقوم فيه كل سكان الكوكب بتثبيت تطبيق ، فإن هذا يخلق الكثير من المشاكل الأخرى من فواصل الشبكة المتداخلة من خلال العلامات الجغرافية وسرعة تبادل الرسائل مع المستخدمين البعيدين ، إلى كمية البيانات المخزنة الضرورية على الأجهزة. ولكن ، على الأرجح ، خرج هذا الرسول من الكتلة الإجمالية وفي مقارنتنا غير ضرورية. إنها أكثر تجريبية من التركيز على المستخدم.

هناك أيضًا مشاريع مثل Tox تحاول تنفيذ برنامج p2p messenger. يسمح لك هذا النهج بعدم القلق بشأن سلامة الخادم ، ومن المستحيل تقريبًا حظر مثل هذا المراسلة. لدى Tox الكثير من المشاكل ، ولكن هذا مشروع مثير للاهتمام للغاية وله مكانة خاصة به. ليس من المنطقي سرد ​​العيوب المحددة لـ Tox ، لأن المشروع يتطور وعلى الرغم من حقيقة أن خدمات p2p أكثر صعوبة في التطوير ، إذا قمت بتعيين مثل هذه المهمة ، يمكنك التوصل إلى العديد من البنى المثيرة للاهتمام لبناء مثل هذه الشبكة: مع مزاياها وعيوبها ، ومتطلبات مختلفة لعرض قناة الإنترنت و مقدار المساحة على الجهاز ، مع العقد الفائقة ، وتسجيل الدخول المتزامن من أجهزة مختلفة وحتى تسليم الرسائل في وضع عدم الاتصال. ولكن من الشائع دائمًا أن يكون تكرارًا كبيرًا لحركة المرور مقارنة ببنية خادم العميل وزيادة استنزاف البطارية على الأجهزة المحمولة نظرًا للحاجة إلى الاحتفاظ باستمرار بعدد كبير من الاتصالات والحسابات المختلفة.

وبالتالي ، على الرغم من أن p2p هي تقنية مثيرة للاهتمام ، إلا أنها ستصبح غير فعالة إذا لزم الأمر ، على سبيل المثال ، لإرسال الإحداثيات الخاصة بك إلى رجال الإنقاذ ، حيث تكون في مكان ما في شجرة في التايغا بدون اتصال بالإنترنت تقريبًا و 1 ٪ شحن للبطارية.

كيفية إصلاحها؟

لذلك ، أود أن أعرض بنية مختلطة للعملاء والخوادم التي اتخذت أفضل الأساليب القائمة وتجنب عيوبها.

لذلك ، حتى يعمل برنامج المراسلة لدينا مع الحد الأدنى من الموارد المطلوبة على الأجهزة المحمولة ، سنستخدم نموذج خادم العميل ، حيث يتم تركيز الحد الأقصى لعمليات الحوسبة والموارد التي تتطلب حركة المرور على الخوادم ، وعلى جانب العميل يتم فك تشفير البيانات وعرضها للمستخدم.

العنونة

يتلقى كل مستخدم عنوانه بتنسيق البريد الإلكتروني أو XMPP ، أي nickname @ domain. ولكن على عكس الخدمات المذكورة أعلاه ، فإن تحديد النطاق لا يحمل نفس دور العنوان المهم في هذه البنية.

من المرجح أن يتم استخدام المجالات كمسجلين للاسم المستعار لاستبعاد احتمال أن تكون جميع الأسماء المستعارة الحالية مشغولة عن قصد أو عن غير قصد.

تكلف المجالات المال على الإنترنت ، وهو ما لا يمنع التسجيل الجماعي ، ولكنه يقلل بشكل كبير من نطاقه. في الخدمات المركزية ، غالبًا ما يكون الوصول من خلال رابط لهاتف محمول ، وهو أيضًا ليس عاملاً حصريًا ، ولكن لا يتم أخذ بطاقات SIM أيضًا من الجو! وفي هذا الصدد ، بالمناسبة ، أتساءل كيف سيقاتلون هذا في https://toxme.io/ - خدمة Tox التي تسمح لك بربط المفاتيح الطويلة مع لقب قصير. لا أرى أي سبب يمنعهم من إرسال رسائل غير مرغوب فيها بمليارات الألقاب غير المرغوب فيها.
بالإضافة إلى ذلك ، قد يكون المجال منطقيًا لحسابات مختلفة للمنزل والعمل. أو لتنظيم شبكة داخلية للشركات.

من وجهة نظر المستخدم ، من أجل الكتابة إلى شخص ما ، تحتاج إلى معرفة تسجيل الدخول الكامل أو المفتاح العام.

من وجهة نظر برنامج الخادم ، إذا تم طلب مستخدم لبصمة إصبعه ، يبحث الخادم في جدوله عن تسجيل الدخول المرتبط به ، إذا تم طلبه على الفور لتسجيل الدخول ، على التوالي ، يتم تخطي هذه الخطوة. بعد ذلك ، يتم تسجيل الدخول وعنوان الخادم الذي يتم تفويض الحساب إليه حاليًا. إذا لم يكن هناك مثل هذه الإدخالات ، فيعتبر أن الحساب المشار إليه بعد @ في تسجيل الدخول هو المسؤول عن الحساب.

ملف تعريف المستخدم

يخزن تطبيق العميل ملف تعريف مستخدم يمثل:

• تسجيل دخول المستخدم الكامل
• قائمة خوادم النسخ الاحتياطي
• مفتاح المستخدم العام والخاص
• معلومات الملف الشخصي مثل قائمة جهات الاتصال وإعدادات الدردشة وملف تعريف المستخدم

يتم توزيع المفاتيح العامة لكل مستخدم بين كل من الخوادم في الشبكة المتحدة. يمكن للمستخدم تسجيل الدخول إلى أي من الخوادم ، نظرًا لأن المصادقة لا تستخدم تجزئة كلمة المرور المخزنة في قاعدة بيانات الخادم ، ولكن المفتاح الخاص للمستخدم.

إجراء التفويض كما يلي: يرسل الخادم إلى العميل مجموعة عشوائية من البيانات المشفرة بالمفتاح العام للعميل ، ويقوم العميل بفك التشفير بمفتاحه الخاص ويرسل تجزئة البيانات التي تم فك تشفيرها إلى الخادم. في حالة تطابق تجزئات البيانات ، سيقوم الخادم بتفويض المستخدم. في الوقت نفسه ، إذا قام المستخدم في المرة الأخيرة بتغيير الخادم الذي تم الاتصال به ، فسيتم إبلاغ جميع خوادم الشبكة المتحدة بالموقع الجديد للمستخدم.

يؤدي عدم الحاجة إلى تذكر كلمة المرور (ومع ذلك ، يسمح لك العميل بتشفير المفتاح الخاص) إلى تبسيط التفاعل مع برنامج المراسلة ويخلق خطر فقدان مفاتيحك. لتجنب ذلك ، يوصى بتكرارها على أجهزة المستخدم الأخرى. لا شيء يمنع الدردشة تحت نفس الحساب من أجهزة متعددة في نفس الوقت ، ولكن القيد الوحيد هو أنه يجب أن تكون جميعها متصلة بنفس الخادم ، وإلا ستصبح البنية مربكة للغاية. ولكن هذا بالكاد ناقص.

إضافة للمتصفحات

بالنسبة للعديد من المنتجات ، فإن نقطة الضعف هي تطبيق ويب. وهذا الحل ، بالطبع ، له الكثير من العيوب. لن يتم تنزيل مثل هذه الدردشة عندما تكون غير متصل ، ثم ستحتاج إلى انتظار التنزيل الكامل ، وقد يتم حظر العنوان ، أو قد يتعطل الخادم. فرز العناوين يدويًا - لا أرغب في ذلك بشكل خاص.

ولا يزال الخيار ممكنًا أن يقوم أحد المهاجمين باختراق تطبيق ويب وتضمين رمزًا يدمج كل بياناتك - حتى بعد أن يقوم الجزء الآخر من التطبيق بفك تشفيرها لك ، ولا تعرف حتى ذلك.

في هذا الصدد ، أقترح التخلي عن تطبيق الويب على هذا النحو ، واقترح تثبيت وظيفة إضافية للمتصفح ، حيث تكون جميع هذه العيوب غير موجودة بحكم التعريف.

بالإضافة إلى ذلك ، عدم وجود حاجة لمالكي خوادم تكوين عميل الويب لخفض حد الدخول لإنشاء خادمهم. لكل أسرة خادمها الخاص!

النقل

من يحتاج إلى رسول لا يوجد أحد للتواصل معه؟ هناك مشاريع مثيرة للاهتمام من رسل غير عاديين ، لكن مشكلة عدم وجود جمهور لا تسمح لهم باكتساب بعض الشعبية على الأقل. ونتيجة لذلك ، في كثير من الأحيان يكتسب الرسل الذين لديهم جمهور كبير جمهورًا أكبر ، ويفقده الرسل الفوريون مع جمهور صغير. وفي معظم الأحيان لا يمكن لهذا الوضع سوى تغيير استثمارات كبيرة في الإعلان.
حسنًا ، بالإضافة إلى ذلك ، تتطلب هذه الحالة تثبيت رسول آخر ، عندما تحتاج بشكل عاجل إلى الاتصال بشخص ليس على شبكات أخرى.

لذلك ، يجب أن يدعم الخادم تشغيل عمليات النقل إلى شبكات الجهات الخارجية.
إذا قام المستخدم بتحديد البيانات للاتصال بحساباته في برامج المراسلة الفورية الأخرى ، فسيرى أشخاصًا من الشبكات التي ربطها في جهات اتصاله.
يتم الاتصال بشبكات الجهات الخارجية من جانب الخادم ، وفي العميل يتم عرض جهات الاتصال على أنها الأكثر عادية ، مع وجود اختلافات طفيفة - على سبيل المثال ، يتم عرض رمز الشبكة التي ينتمي إليها المستخدم.

كعيب ، يصبح من الضروري الوثوق بالخادم ببياناته للاتصال بشبكات الجهات الخارجية. ليس كل شخص مستعدًا لتفويض سلطته إلى خادم جهة خارجية ، لذلك تحتاج إلى تشجيع إنشاء خوادمك الخاصة بكل طريقة.

التشفير

بالطبع ، لا يتمكن جهاز الشبكة اللامركزي من الاستغناء عن تشفير جميع البيانات المرسلة ، لأنه لا يمكننا التأكد من أنه حتى في الخادم الموكول إلينا ، هناك نوع من الإشارة المرجعية التي تدمج جميع البيانات غير مدمجة.
في وقت سابق ، تمت الإشارة سابقًا إلى أن زوج المفاتيح المستخدم يتم استخدامه للتفويض ، ويتم أيضًا توقيع جميع الرسائل المرسلة إلى مستخدمين آخرين باستخدام المفتاح الخاص للمرسل ويتم تشفيرها باستخدام المفتاح العام للمستلم.

لا يوجد شيء جديد هنا ، يتم استخدام أدوات تشفير GPG القياسية.
لم يتم حل مشكلة التشفير في المجموعات بعد ، ولكن ربما يمكنك استخدام الآلية المستخدمة في Signal.

ما تم بالفعل

في الوقت الحالي ، قمنا بالفعل بإنشاء خادم Python باستخدام Tornado ، الذي ينفذ الوظائف الأساسية للمراسلة ، هناك إصدار ويب مجمّد قليلاً يجب تحويله إلى وظيفة إضافية للمتصفح ، وهناك مكتبة Rust تعتمد على عميل يعمل بواجهة QML.

يتم إجراء الاتصال بالخادم باستخدام WebSockets ، حيث يتم إجراء تسلسل للبيانات بشكل افتراضي إلى التنسيق الثنائي لتمثيل بيانات CBOR ، ولكن عند إنشاء اتصال WebSockets ، من الممكن طلب تنسيق مختلف ، على سبيل المثال protobuf.

أرى أيضًا أنه من المهم ملاحظة أن العميل يستخدم قسمًا في قائمة الدردشات ، مرتبة حسب تاريخ أحدث الرسائل ، وتستخدم على نطاق واسع في الرسائل الفورية الحديثة ، والقائمة التقليدية ، مع فرز جهات الاتصال إلى فئات. مع الاستخدام الفعال للرسول ، يجب عليك التفاعل مع عدد كبير من الدردشات ، ويصبح من الصعب البحث عنها في ترتيب قائمة دائم التغير. في نفس Telegram يحل جزئيا مشكلة تثبيت الدردشات المحددة في أعلى القائمة ، ولكن هذا ليس سوى حل مؤقت للمشكلة.

→ إليك المستودعات التي تحتوي على رؤيتنا