أعدّت هذه المقالة ريم المصري وريما الصغير، وهما عضوان مستقلان في منظمة تحالف الحقوق الرقمية في منطقة غرب آسيا وشمال أفريقيا (MADR).

في مطلع عام 2026، اتفق أعضاء “تحالف الحقوق الرقمية في منطقة الشرق الأوسط وشمال أفريقيا” (MADR) على ضرورة اعتماد أداة جديدة للتواصل الداخلي، تلبّي احتياجات التحالف في ظلّ اتساع عضويته وتشكيل لجان فرعية وبروز أوجه تعاون جديدة. خلال سنوات التحالف الأولى، استخدمنا تطبيق “سيغنال” لتبادل الأخبار بأمان. لكنّنا أصبحنا بحاجة إلى أداة تتيح قنوات تواصل متعددة وتساعدنا  في  تنظيم العمل المشترك بصورة أفضل. وكما فعلنا عند اختيار “سيغنال”، اتفقنا على أن تنسجم الأداة الجديدة مع قيم التحالف في استخدام التكنولوجيا بمسؤولية، وأن تعطي الأولوية “للبرمجيات الحرّة ومفتوحة المصدر” (FLOSS)، والتشفير القوي، وسهولة الاستخدام، وإمكانية الوصول، والحوكمة الذاتية حيثما أمكن. استرشدنا في ذلك بتجربة “رابطة الاتصالات التقدمية” (APC)، التي أكّدت، استناداً إلى ثلاثين عاماً من العمل عبر الإنترنت من أجل التغيير الاجتماعي، “أهمية الابتعاد عن الصيحات التقنية والتركيز بدلاً من ذلك على ما تؤدّيه الأدوات نفسها من وظائف“.

قدّم أعضاء التحالف مقترحات كثيرة لأدوات استخدموها في شبكات أخرى أو رغبوا في اعتمادها، منها “إليمنت” (Element)، و”دلتا تشات” (Delta Chat)، و”روكيت تشات” (Rocket.Chat)، و”زوليب” (Zulip)، و”سيمبل إكس تشات” (SimpleX Chat)، و”كوايت” (Quiet)، و”ماترموست” (Mattermost). وبدلاً من الاكتفاء بتجارب الأعضاء وآرائهم، أطلقنا مشروعاً بحثياً تشاركياً لاستكشاف الخيارات المتاحة، وجعلنا احتياجاتهم الفعلية أساساً لاختيار أدوات التواصل مفتوحة المصدر التي سنقيّمها ونقارن بينها.

تولّينا، بصفتنا عضوتَيْن مستقلّتَيْن في التحالف، قيادة هذه الجهود، وشكّلنا لجنة تتولّى البحث واختبار الأدوات بمشاركة المستخدمين. جمعت اللجنة تجارب أعضاء التحالف المتنوّعة ونماذج التهديد (threat models) الخاصة بهم، سواء كانوا في بلدان مختلفة من المنطقة أو في المهجر، مع مراعاة اختلاف أجهزتهم وأنظمة التشغيل التي يستخدمونها وظروف اتصالهم بالشبكة.

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

خصائص لا يمكن التنازل عنها

يجب أن تدعم أيّ أداة نعتمدها استخدام اللغة العربية، بما في ذلك عرض النصوص من اليمين إلى اليسار (RTL) والنصوص ثنائية الاتجاه (BiDi) على نحو صحيح، حتى تظهر الرسائل التي تجمع بين العربية والإنكليزية كما ينبغي. ويجب أن تتيح الأداة إنشاء قنوات متعددة وإدارتها بمرونة، وتبادل الملفات، وإرسال الرسائل المباشرة، وأن توفّر تطبيقاً للهاتف المحمول يسهل استخدامه فعلاً. ولأنّ أعضاءنا يستخدمون أجهزة متعددة ويعملون في أوقات مختلفة، يجب أن تكون تجربة استخدام الأداة على الحاسوب والهاتف سهلة وسريعة الاستجابة بالقدر نفسه.
يواجه بعض أعضاء التحالف مخاطر أمنية جسيمة، منها مصادرة أجهزتهم. لذلك، نحتاج إلى ميزات فعّالة للأمن التشغيلي (OpSec). وتشمل هذه الميزات تشفيراً قوياً للبيانات أثناء نقلها وتخزينها، ويُفضّل أن يكون التشفير من طرف إلى طرف (E2EE)، فضلاً عن إمكانية قفل التطبيق على الهاتف، وإرسال رسائل ذاتية الاختفاء، واستضافة الأداة ذاتياً، ومحو بيانات الحساب عن بُعد.
ويجب أيضاً أن يكون البرنامج موثوقاً، وأن يواصل مطوّروه صيانته وتحديثه. واعتمدنا في تقييم ذلك على وتيرة إصدار تحديثات البرنامج والتحديثات الأمنية، ولا سيّما توافر عمليات تدقيق أمني مستقلة.
وأخيراً، من المهم أن تكون الأداة مألوفة للأعضاء ويسهل عليهم اعتمادها، وأن يراعي تصميمها إمكانية الوصول والشمول. ويُفضَّل أن تشبه تجربة استخدامها (UX) ما اعتاد عليه الأعضاء، وقد استطلعنا ذلك من خلال استبيان. وإن لم يكن ذلك ممكناً، فيجب على الأقل أن يسهل عليهم تعلّم استخدامها.

الخصائص غير الأساسية
لا تُعَدّ القدرة على مواصلة العمل عند انقطاع الإنترنت شرطاً أساسياً لمنصة التواصل الداخلي الرئيسية للتحالف، لأنّ التحالف ليس شبكة محلّية تحتاج إلى التواصل المستمر كل يوم.
وتقلّ أهمية النسخ الاحتياطية في تطبيقات المستخدمين إذا استضفنا الأداة بأنفسنا، ما دامت الجهة الموفِّرة للبنية التحتية تحتفظ بنسخ احتياطية منتظمة للخوادم، وتتّبع إجراءات واضحة لاستعادة البيانات.
وقد يكون التكامل مع تطبيقات أخرى، مثل منصات الاجتماعات عبر الفيديو وإدارة المشاريع، مفيداً، ولكنّه ليس شرطاً أساسياً في هذا السياق.
وتبقى بعض الميزات إضافات لطيفة، وإن لم تكن ضرورية، مثل الرسائل الصوتية، ومشاركة جهات الاتصال، وإمكانية استخدام الصور المتحركة (GIF) والرموز التعبيرية داخل الأداة. توفّر معظم المنصات الحديثة هذه الميزات أصلاً، لكنّنا نعترف بأنّ الرموز التعبيرية النصية على طريقة التسعينيات لا تزال قادرة على التعبير عمّا نشعر به. ¯(ツ)/¯

الخلاصة في هذه المرحلة: التوجّه نحو الاستضافة الذاتية

استبعدنا أداة “ماترموست” (Mattermost) في البداية لأنّه لا يوفّر ميزة مدمجة للتشفير من طرف إلى طرف، إذ بدا لنا أنّ هذا التشفير ينبغي أن يكون من أولوياتنا. فقد أراد كثير من الأعضاء حماية بياناتهم من جهات خارجية قد تستهدفهم، والاطمئنان إلى أنّ مسؤولي النظام الذين يديرون الخادم أنفسهم لا يستطيعون الاطّلاع على محادثاتهم. بحثنا في بدائل تضع هذا التشفير في مقدّمة أولوياتها، وهي “إليمنت” (Element) و”دلتا تشات” (Delta Chat) و”روكيت تشات” (Rocket.Chat) و”سيمبل إكس تشات” (SimpleX Chat) و”كوايت” (Quiet). ولكنّ هذه البدائل لم تلبِّ جميع احتياجاتنا من حيث الوظائف، وظهرت في كلٍّ منها إحدى المشكلات الآتية على الأقل:

• غياب دعم استخدام اللغة العربية وعرض النصوص من اليمين إلى اليسار
• مشكلات في عرض الردود التي تجمع بين العربية والإنكليزية
• عدم استقرار البرنامج وعدم انتظام صيانته
• عدم توافر نسخ مستقرة للهاتف المحمول توفّر الوظائف المطلوبة
• غياب الشفافية وعدم توافر عمليات تدقيق أمني مستقلة
• حصر ميزات الأمان المتقدّمة وإدارة الصلاحيات في فئة المؤسسات المدفوعة (Enterprise)، وفق نموذج “النواة المفتوحة” (open core)
• حاجة أعضاء التحالف إلى وقت وجهد كبيرَين لتعلّم استخدام الأداة واعتمادها

بعد أن تبيّنت لنا هذه المشكلات، اتفقنا على إعادة النظر في الخصائص التي كنّا نشترط توافرها، مع مراعاة ملاحظات الأعضاء بشأن المفاضلة بين وظائف الأداة وتصميمها. وأعطينا الأولوية للأدوات التي تتيح التواصل عبر قنوات متعددة وتسهّل البحث في أرشيف الرسائل، فحصرنا خياراتنا في “إليمنت” (Element) و”زوليب” (Zulip) و”ماترموست” (Mattermost). وأبدينا مخاوف بشأن عدم توفّر ميزة مدمجة للتشفير من طرف إلى طرف في “زوليب” (Zulip) و”ماترموست” (Mattermost). أمّا “إليمنت” فيوفّر هذه الميزة، لكنّ تعلّم إدارة مفاتيح الأمان فيه يتطلّب وقتاً وجهداً، كما يواجه مشكلات في عرض النصوص التي تجمع بين العربية والإنكليزية. وقد ثنى ذلك كثيراً من الأعضاء عن اختياره.

ينظّم “زوليب” (Zulip) المحادثات بحسب الموضوع ويعرضها في أعمدة متعددة، بخلاف “سلاك” (Slack) و”ماترموست” (Mattermost) حيث تتوالى الرسائل داخل القنوات. ويحتاج الأعضاء، نتيجةً لذلك، إلى الاعتياد على طريقة مختلفة لمتابعة المحادثات. لذا، اختار التحالف “ماترموست” بدلاً من “زوليب”، لأنّ عدداً أكبر من الأعضاء كان مرتاحاً إلى استخدامه، ما يسهّل عليهم اعتماده.

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

يتوقّف أمان أدوات التواصل على أمان البيئة التي تستضيفها. وقد نشر “ماترموست” (Mattermost) قائمة تحقّق تستند إلى مبدأ “الثقة الصفرية” (Zero Trust)، للمساعدة في تطبيق ضوابط أمنية على مستويات متعددة. كذلك، لا يكفي الإعلان عن دعم التشفير من طرف إلى طرف ما لم تخضع هذه الميزة لتدقيق أمني مستقل تُنشَر نتائجه. ويبرز ذلك عند النظر في إضافة التشفير من طرف إلى طرف التي طوّرتها شركة الأمن السيبراني الفرنسية “كواركسلاب” (Quarkslab) لتطبيق “ماترموست” على الويب؛ فالإضافة لم تُحدَّث منذ عام 2023.

أبرز النتائج والدروس المستفادة

لم نقصد بهذا العمل إجراء تقييم شامل لتطبيقات التواصل مفتوحة المصدر أو المقارنة بينها، بل أردنا توثيق المسار الذي اتبعناه معاً لاختيار أداة تنطلق من احتياجات أعضاء التحالف. فقد وجدنا في كثير من التطبيقات التي اختبرناها نقاط قوة تلائم ظروفاً أمنية معيّنة. يوفّر “سيمبل إكس تشات” مستوى عالياً من الأمان والخصوصية، لأنّه لا يخصّص معرّفات لمستخدميه. ويعتمد “دلتا تشات” على بروتوكول البريد الإلكتروني، ما يجعله أقلّ تأثّراً بالرقابة وانقطاع الإنترنت. أمّا “كوايت” فيزامن الرسائل مباشرةً بين أجهزة أعضاء الفريق عبر شبكة “تور” (Tor)، من دون الحاجة إلى خادم. ويتيح “إليمنت” (Element) التواصل اللامركزي بين مستخدمي خوادم مستقلة، فضلاً عن التشغيل البيني مع أنظمة أخرى. وتتولّى “مؤسسة زوليب” (Zulip Foundation)، وهي منظمة غير ربحية تتبع نموذج حوكمة شبيهاً بنموذج “سيجنال”، صيانة “زوليب“، ما يساعد على ضمان استقلاله واستدامته على المدى الطويل.

لا يخلو “ماترموست” (Mattermost) من مشكلات أيضاً. ومع ذلك، وجدناه الأداة الأنسب لنا، بالنظر إلى قيمنا وما نحتاج إليه عملياً بوصفنا تحالفاً وإلى صعوبة الحفاظ على أمان تواصلنا.

شكّل اختيار تطبيق للتواصل الداخلي إحدى أسهل الخطوات في مسارنا لتعزيز قدرتنا على مواصلة العمل رغم المخاطر الرقمية. ومع ذلك، أثارت العملية أسئلةً سنحتاج إلى العودة إليها عندما نعتمد بنيةً تحتيةً مستقلةً أوسع نطاقاً، مثل منصات التخزين الداخلي، ومنها “نكست كلاود” (Nextcloud)، أو منصات التواصل الاجتماعي البديلة ضمن “الفيديفرس[U1] ” (Fediverse). وقد خرجنا من هذه التجربة ببعض الملاحظات:

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

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

وندعو أيضاً تحالفات وشبكات ومجموعات الأخرى تُعنى بحقوق الإنسان إلى مشاركتنا تجاربها: ما الخطوات التي اتّبعتموها للانتقال إلى بنية تحتية مستقلة تستضيفونها بأنفسكم لتسيير أعمالكم؟