يستضيف الناس Matrix ذاتيًا لمنع شركة ما من الاحتفاظ بمحادثاتهم، وهذا الجزء يعمل تمامًا كما هو معلَن. ما يفاجئهم لاحقًا هو طبيعة ما ثبّتوه فعليًا: الخادم الذاتي ليس صندوقًا خاصًا يتحدث الدردشة فحسب، بل هو عقدة تكرار (replication node) في شبكة عامة، وتتصرف الفيدرالية بشكل أقرب إلى بروتوكول نشر منه إلى ما يتوقعه معظم المسؤولين الجدد.
لا شيء مما سبق حجة ضد تشغيل خادمك الخاص — بل هو الحجة لتشغيله عن قصد. الخصوصية التي تكسبها حقيقية لكنها محددة: تنتقل الحيازة (custody) إليك، ولا يمكن لأحد آخر إغلاق حسابك، وتَصِل الأسئلة القانونية إلى الولاية القضائية التي اخترتَها أنت لا التي اختارتها شركة. أما الخصوصية التي لا تكسبها فمحددة بالقدر نفسه، وتكمن في الفجوة بين «الرسائل مشفّرة» و«لا أحد يمكنه معرفة من يتحدث إلى من». يغطي هذا الدليل كلا النصفين، ثم التفاصيل التشغيلية التي تحدد ما إذا كان الخادم سيبقى بصحة جيدة بعد عام من الآن.
ما الذي يتغيّر فعليًا عند تشغيل خادم Matrix الخاص بك
ابدأ بفصل التهديدات عن بعضها، لأن الخادم الذاتي يجيب عن بعضها إجابة كاملة، وعن بعضها الآخر جزئيًا، وعن بعضها لا يجيب إطلاقًا. الجدول أدناه هو النسخة الصادقة من العرض، ويستحق أن تقرأه قبل اختيار العتاد لا بعده.
| ما الذي يقلقك | هل يحل خادمك الخاص هذه المشكلة؟ |
|---|---|
| قراءة شركة لمحتوى رسائلك | التشفير التام من طرف إلى طرف يغطي هذا أصلًا في الغرف الخاصة — ونعم، الاستضافة الذاتية تُبعد الشركة أيضًا |
| تحليل شركة لمن تتحدث إليه ومتى | جزئيًا. تتوقف عن تغذية مشغّل مركزي واحد، ويحتفظ خادمك الخاص الآن بهذا السجل بدلًا منه |
| إغلاق حسابك أو تعليقه من قِبل طرف آخر | نعم. أوضح مكسب في العملية كلها، والأقل حديثًا عنه |
| طلب قانوني للحصول على بياناتك | ينتقل الطلب ولا يختفي. يصلك الطلب الآن بموجب قانون البلد الذي اخترته |
| معرفة أطراف أخرى بشبكة علاقاتك الاجتماعية | لا. كل خادم فيه عضو في الغرفة يتلقى بيانات العضوية نفسها التي تتلقاها أنت |
| إخفاء وجود الخادم أصلًا | لا. تحتاج الفيدرالية إلى اسم عام ومنفذ يمكن الوصول إليه؛ فهذا عكس الإخفاء تمامًا |
اقرأ السطرين الأخيرين بعناية، فهما حيث تنكسر التوقعات عادة. إن كان هدفك ألا يستطيع أحد إثبات وجود الخدمة أصلًا، فـMatrix ليست الأداة المناسبة، والخدمة المخفية (onion service) أقرب إلى الأداة الصحيحة. أما إن كان هدفك الحيازة والتحكم والولاية القضائية، فالخادم الذاتي أداة ممتازة، وبقية هذا الدليل تتناول كيفية تشغيله جيدًا.

الفيدرالية: بروتوكول تكرار يرتدي ثوب بروتوكول دردشة
إليك الآلية التي تفسر معظم المفاجآت. حين ينضم أحد مستخدميك إلى غرفة مستضافة في مكان آخر، لا يجلب خادمك الرسائل عند الطلب كما يفعل عميل بريد إلكتروني. بل ينضم إلى الغرفة كمشارك في رسم بياني موزّع للأحداث، ثم يسحب نسخة ويخزّنها من أحداث الغرفة وعضويتها وقدر كافٍ من تاريخ الحالة للتحقق مما سيأتي لاحقًا. ومنذ تلك اللحظة يحمل جهازك نسخة مكررة، ويحمل كل خادم آخر مشارك نسخة أيضًا.
تسير النتائج في الاتجاهين، ولا واحد منهما بديهي. البيانات التي يُنشئها مستخدموك — اسم العرض، الصورة الرمزية، الانضمام والمغادرة، الطوابع الزمنية، ردود الفعل — تُنسخ إلى كل خادم فيه عضو في تلك الغرفة، وتبقى في قواعد بياناتهم بصرف النظر عمّا تحذفه لاحقًا من قاعدتك. الحذف (redaction) هو طلب يُرسَل إلى الأقران لا أمر يُنفَّذ. لا وجود لـ«إلغاء الإرسال» عبر فيدرالية من خوادم تُدار باستقلالية، وتوقّع ذلك هو أكثر سوء فهم شائع عن هذا البروتوكول.
وفي الاتجاه الآخر، الانضمام إلى غرف عامة كبيرة يعني استيراد تاريخ أشخاص آخرين إلى قرصك. لهذا السبب قد يحمل خادم جديد كليًا بثلاثة مستخدمين فقط قاعدة بيانات بعشرات الغيغابايتات: ليس لأن مستخدميك الثلاثة كتبوا الكثير، بل لأنهم انضموا إلى غرف فيها خمسون ألف عضو وسنوات من الحالة المتراكمة. اختيار الغرف بتعمّد قرار سعة تخزينية بقدر ما هو قرار خصوصية.
ما الذي يغطيه التشفير، وما الذي يبقى ظاهرًا بلا حماية
تشفّر Matrix محتوى الرسائل باستخدام Megolm، وهو مفعّل افتراضيًا في الغرف الخاصة. هذا يحمي الجزء الذي يهتم به الناس أكثر من غيره، وهو يعمل فعليًا — يخزّن خادمك نصًا مشفّرًا لا يستطيع قراءته، وهذه خاصية حقيقية ومفيدة حين يكون الخادم عتادًا مستأجرًا. أما الغلاف المحيط بالرسالة فقصة مختلفة تمامًا، والفجوة فيه أوسع مما تعترف به معظم الملخصات.
| الإشارة | مشفّرة؟ | مرئية لـ |
|---|---|---|
| نص الرسالة ومحتوى الملفات | نعم | أجهزة أعضاء الغرفة الموثّقة فقط |
| من هو في الغرفة، وكل انضمام أو مغادرة | لا | كل خادم فيه عضو في تلك الغرفة |
| الطوابع الزمنية، وتيرة الرسائل، ساعات النشاط | لا | كل خادم مشارك |
| أسماء العرض، الصور الرمزية، الحضور والكتابة | لا | كل خادم مشارك |
| اسم الغرفة وموضوعها وصورتها الرمزية | لا | كل خادم مشارك |
| حجم المرفق وتوقيت نقله | لا | كل خادم مشارك |
| نطاق خادمك وعنوان IP الخاص به | لا | الفيدرالية بأكملها — وهذا مقصود بالتصميم |
القراءة العملية: التشفير يحمي ماذا، والفيدرالية تنشر من، ومتى، وكم مرة. بالنسبة إلى معظم المجتمعات هذه المقايضة مقبولة تمامًا، والصراحة هي بيت القصيد. أما في نموذج تهديد يكون فيه رسم العلاقات الاجتماعية نفسه هو الجزء الحساس، فبروتوكول فيدرالي هو الشكل الخطأ من حيث البنية، ولا يغيّر ذلك أي إعداد تهيئة.
Synapse أم Dendrite أم Conduit — أيّها تُشغّل فعليًا
ثلاثة تطبيقات تهم عمليًا، والاختيار بينها قرار موارد في الغالب لا قرارًا فلسفيًا.
- Synapse هو الخادم المرجعي، مكتوب بلغة Python، والوحيد الذي تعمل فيه كل ميزة منذ اليوم الأول. وهو أيضًا الأكثر شراهة للموارد: تنمو الذاكرة مع عدد الغرف التي ينضم إليها مستخدموك وحجمها، ويحتاج الخادم المزدحم في النهاية إلى تقسيمه إلى عمليات عاملة (worker processes). اختره حين تحتاج إلى أن تعمل المساحات (spaces) وأدوات الإشراف والجسور وواجهات برمجة الإدارة تمامًا كما هو موثّق.
- Dendrite هو إعادة الكتابة بلغة Go. أخف وزنًا من Synapse بشكل ملحوظ، وصالح تمامًا لخادم صغير، مقابل بعض التأخر في الميزات. خيار وسط معقول حين يبدو Synapse ثقيلًا بالنسبة إلى عدد الأشخاص الذين لديك فعليًا.
- Conduit والفرع الذي يُطوَّر بنشاط منه،
conduwuit، مكتوبان بلغة Rust ويأتيان كثنائي واحد مع قاعدة بيانات مضمّنة. يُشغّلان خادم عائلة أو مجتمع صغير على أصغر خطة نبيعها دون أي شكوى. المقايضة هي نظام بيئي أصغر: بعض أدوات الإدارة وقلة من الجسور تفترض وجود Synapse.
لخادم أول بحفنة من المستخدمين، برنامج عائلة Conduit على VPS صغير هو الطريق الأقل إيلامًا إلى شيء يعمل ويبقى رخيصًا. أما لأي خادم تتوقع له أن ينمو — مجتمع عام، شركة، مشروع بجسور — فابدأ بـSynapse مباشرة وتجنّب الترحيل لاحقًا، لأن الانتقال بين التطبيقات فيما بعد عملية تصدير وإعادة بناء لا مجرد تغيير إعداد.
إعداد التفويض الذي يخطئ فيه الجميع
تفصل Matrix بين الاسم في معرّفات المستخدمين لديك وبين الجهاز الذي يخدم حركة المرور، وقلب هذا الترتيب هو الخطأ الدائم الأكثر شيوعًا في الاستضافة الذاتية. server_name هو النطاق الذي يظهر بعد النقطتين الرأسيتين في كل معرّف مستخدم على خادمك. يصبح جزءًا من هويتك في الفيدرالية لحظة توقيع أول حدث، ولا يمكن تغييره بعد ذلك إلا بالتخلي عن كل حساب وغرفة على الجهاز.
الإعداد الذي تريده تقريبًا دائمًا: يكون server_name نطاقك المجرّد، بينما يعمل البرنامج على نطاق فرعي. تربط بينهما بالتفويض (delegation)، بإحدى طريقتين. الأبسط هي ملف JSON ثابت يُقدَّم عند /.well-known/matrix/server على النطاق المجرّد، يسمّي المضيف والمنفذ الحقيقيين. البديل هو سجل DNS، وهو _matrix._tcp، يشير إلى المكان نفسه. قدّم أيضًا ملف جانب العميل عند /.well-known/matrix/client، حتى تجد التطبيقات الخادم انطلاقًا من العنوان وحده.
قرّر الاسم قبل تثبيت أي شيء. ضبط server_name على النطاق الفرعي لمجرد أن البرنامج يعمل هناك هو الخطأ الكلاسيكي، وهو خطأ لا رجعة فيه: كل معرّف مستخدم ومعرّف غرفة وحدث موقَّع يحمله إلى الأبد. اختر النطاق الذي تريده مطبوعًا على بطاقة عمل، وفوّض إلى أي مكان تستمع فيه العملية فعليًا، وحافظ على TLS صالح على كلا الاسمين — فشل شهادة على المضيف المُفوَّض يُسقط الفيدرالية حتى وإن بدا التطبيق سليمًا محليًا.
تقدير الحجم بصدق
لا ترتبط Matrix بالمعالج (CPU) في التشغيل العادي؛ بل ترتبط بالذاكرة وبسلوك قاعدة البيانات. الأرقام المنشورة لـSynapse حدّ أدنى مفيد: نحو 2 GB من RAM للبدء، وحوالي 4 GB عند وجود عشرة إلى خمسين مستخدمًا نشطًا، و8 GB أو أكثر بعد المئة. أما خوادم عائلة Conduit فتقل عن ذلك بكثير. وما تغفله هذه الأرقام هو أن الاستهلاك يتبع الغرف المنضمّ إليها لا عدد الأشخاص المسجَّلين — فخمسة مستخدمين في مئة غرفة عامة كبيرة يكلفون أكثر بكثير من خمسين مستخدمًا في حفنة غرف خاصة.
تترتب على ذلك قاعدتان عمليتان. ضع قاعدة البيانات على تخزين سريع وامنحها مساحة للنمو، لأن نمط الكتابة صغير ومستمر لا متفجّر. ولا تُقدّر الحجم بناءً على عدد المستخدمين اليوم: قدّره بناءً على الغرف التي سينضم إليها هؤلاء المستخدمون في الشهر الأول، فهذا عادة مكمن المفاجأة. تحمل خطتنا الابتدائية خادم Conduit أو Dendrite صغيرًا بارتياح، بينما ينتمي مثيل Synapse لمجتمع حقيقي إلى خطة متوسطة أو أعلى — تسرد صفحة استضافة الدردشة الفئات التي نوصي بها لكل من هذه الحالات.
وقت التشغيل (uptime) يهم هنا أكثر مما يهم في معظم أحمال العمل الأخرى، لأن خادم دردشة متوقف ليس مجرد غير متاح — بل يفوّت بصمت أحداثًا سيعيد الأقران محاولة إرسالها لفترة ثم يتوقفون عن ذلك. تتسامح الفيدرالية مع الدقائق ولا ترحم الأيام.
مخزن الوسائط: قنبلة قرص بطيئة الانفجار
كل صورة وفيديو وملف يمر عبر غرفة يتواجد فيها مستخدموك قد ينتهي به الأمر مخزَّنًا مؤقتًا على قرصك، بما في ذلك وسائط بعيدة لم يفتحها مستخدموك أبدًا. الاحتفاظ الافتراضي في Synapse يبقيها إلى ما لا نهاية. النتيجة متوقعة ولا تزال تفاجئ الناس: خادم قاعدة بياناته مستقرة ومجلد وسائطه ينمو بهدوء حتى يمتلئ التخزين، وعندها لا يكون العرض «القرص ممتلئ» بل «الخادم يتصرف بغرابة».
اضبط سياسة احتفاظ للوسائط البعيدة منذ اليوم الأول لا بعد أول انقطاع. يعرض Synapse إعدادات الاحتفاظ في homeserver.yaml، إضافة إلى نقاط إدارة نهائية للتخلص من التاريخ القديم والملفات المخزَّنة مؤقتًا؛ ويستعيد synapse-compress-state قدرًا مفاجئًا من المساحة من جداول الحالة على خادم قديم. راقب قاعدة البيانات ومسار الوسائط معًا، وفعّل التنبيه عند نفاد المساحة الحرة لا عند توقف الخدمة — فالعرض الثاني يصل بعد الأول بأيام.
هناك إعداد واحد يستحق قرارًا واعيًا لا اكتفاءً بالإعداد الافتراضي. معاينات الروابط (URL previews) تجعل خادمك يجلب أي رابط يُنشر في غرفة، ما يعني أن عنوان IP الخاص بخادمك يرسل طلبًا صادرًا إلى طرف ثالث لحظة يلصق أحدهم رابطًا — بما في ذلك رابط اختير خصيصًا لمعرفة من سيقع في الفخ. إن كان خادمك خلف واجهة أمامية وكان عنوانه الحقيقي مهمًا، فزِن الأمر بعناية؛ يغطي دليلنا حول إخفاء عنوان الأصل النوع نفسه من التسريب بتفصيل أكبر.
التسجيل، البريد العشوائي، والسمعة التي ترثها
التسجيل المفتوح على خادم عام دعوة، وليست من النوع الذي تريده. التسجيلات الآلية تحوّل خادمًا صغيرًا إلى مصدر بريد عشوائي خلال أيام، والنتيجة ليست محلية: تضيف خوادم أخرى نطاقك إلى قوائم تحكم الوصول، وحين يصبح اسمك على عدد كافٍ منها يتوقف مستخدموك الشرعيون عن القدرة على المشاركة في غرف في أماكن أخرى. استعادة سمعة نطاق محترق أصعب بكثير من تجنّب حرقه أصلًا، تمامًا كما هو الحال مع إمكانية تسليم البريد الإلكتروني.
الإعدادات الافتراضية القابلة للدفاع عنها بسيطة. أبقِ enable_registration معطّلًا لخادم خاص ووزّع الحسابات بنفسك. إن أردت فتح الباب، فقيّده: يحوّل registration_requires_token التسجيل إلى نظام دعوات دون أي خدمة طرف ثالث، ويساعد الكابتشا ضد الطرف الخشن من المشكلة. أما بالنسبة إلى الغرف التي تديرها، فتتيح لك روبوتات الإشراف من عائلة Mjolnir وDraupnir تطبيق قوائم حظر وقوائم تحكم وصول للغرف عبر مجتمع بأكمله بدلًا من غرفة واحدة في كل مرة.
يستحق أن تعرف في الاتجاه المعاكس: نطاقات عناويننا غير مدرجة في قوائم حظر ACL الخاصة بـMatrix المتداولة بين الخوادم، لذا يبدأ خادمك الجديد بسمعة نظيفة. أما ما يحدث لتلك السمعة لاحقًا فتحدده طريقة إدارتك للتسجيل، لا مكان وجود الجهاز.
الجسور، وفاتورة البيانات الوصفية المرافقة لها
الجسور هي السبب الصادق الذي يجعل كثيرًا من الناس يبقون على Matrix: عميل واحد لغرف تعيش على شبكات أخرى. لكنها تغيّر أيضًا موقع خادمك الأمني بطريقة يسهل تجاهلها. يحتفظ الجسر ببيانات اعتماد الحساب البعيد، وعند الحد الفاصل الذي يلتقي فيه البروتوكولان، يتعامل بالضرورة مع الرسائل بصيغة يستطيع تحويلها — ما يعني أن عملية الجسر ترى نصًا صريحًا لحركة مرور مشفّرة تشفيرًا تامًا من طرف إلى طرف على جانبيه معًا.
هذا ليس سببًا لتجنّب الجسور. إنه سبب لمعاملة مضيف الجسر بوصفه بنية تحتية حسّاسة: فهو الجهاز الذي يكشف، إن اختُرق، عن الحسابات التي يتحدث نيابة عنها. كل جسر يضاعف تقريبًا البصمة الذاكرية لخادم صغير، فخطّط للسعة تبعًا لذلك، وأولِ اختيار مكان تشغيله التفكير نفسه الذي أوليته للخادم الذاتي نفسه — وينطبق المنطق في دليل الولاية القضائية بقوة أكبر على جهاز يحمل بيانات اعتماد عدة شبكات في آن واحد.
إبقاؤه حيًا: المفاتيح، النسخ الاحتياطي، والترقيات
لخادم Matrix ملف واحد فقدانه لا يمكن تداركه بطريقة لا علاقة لها بحجم البيانات. مفتاح التوقيع — signing.key في Synapse — هو ما يثبت به خادمك أن الأحداث التي تدّعي القدوم من نطاقك تأتي منه فعلًا. افقده ولن تعود قادرًا على أن تكون خادمك بمصداقية بعد الآن؛ سيرفض الأقران أحداثًا موقّعة من غريب يحمل اسمك. انسخه احتياطيًا بمعزل عن كل شيء آخر، واحتفظ بتلك النسخة بعيدًا عن الجهاز.
انسخ المفتاح وقاعدة البيانات احتياطيًا معًا، وافهم لماذا تكون استعادة أحدهما دون الآخر خطيرة. إعادة قاعدة بيانات Matrix إلى لقطة أقدم تضع خادمك في حالة تجاوزها أقرانه بالفعل، والتباعد الناتج عن ذلك أصعب بكثير في إصلاحه من إعادة بناء نظيفة. خذ نسخًا متسقة باستخدام pg_dump، واحتفظ بها خارج الجهاز، وتذكّر أنه لا توجد على هذه المنصة نسخة من المزوّد يمكن الرجوع إليها — فلا شيء يُحتفظ به بعد الإنهاء، وهذا هو بيت القصيد من هذا الترتيب، وهو مشروح في دليل النسخ الاحتياطي.
الترقيات أمر عادي لكنه ليس اختياريًا. تحمل إصدارات الخادم ترحيلات مخطط قاعدة بيانات (schema migrations)، وتخطي إصدارات كثيرة يحوّل ترقية من خمس دقائق إلى أمسية كاملة. اقرأ ملاحظات الإصدار قبل القفز، ورقّي بانتظام كافٍ لتبقى كل خطوة صغيرة، وطبّق نظافة الاستضافة الأساسية من قائمة تحصين الساعة الأولى — خادم الدردشة خدمة طويلة العمر ومواجهة للإنترنت ومرتبطة بقاعدة بيانات، وتستحق المعاملة نفسها التي تستحقها أي خدمة من هذا النوع.
مكان إقامة الخادم لا يزال يحدد النتيجة
كل ما سبق مسألة إعداد. أما الجزء الذي لا يستطيع الإعداد لمسه فهو أي نظام قانوني يتلقى طلبًا بشأن مستخدميك، وبالنسبة إلى خادم اتصالات يحمل هذا السؤال وزنًا أكبر مما يحمله بالنسبة إلى موقع ويب عادي. يحتفظ الخادم الذاتي بسجلات العضوية والطوابع الزمنية وبيانات رسم العلاقات الاجتماعية ظاهرة بلا تشفير حتى حين تكون نصوص الرسائل مشفّرة — لذا فإن الولاية القضائية التي تستضيفه هي التي تحكم الوصول إلى ذلك السجل.
هذه هي الحجة العملية لاختيار الموقع بتعمّد لا بالاعتماد على زمن الاستجابة وحده. نُشغّل سبعة مواقع، والمقايضات بينها مشروحة في دليل الولاية القضائية وعلى صفحة المواقع. أما النصف الآخر من السؤال نفسه فهو من يعرف المزوّد أنك أنت: حساب بلا هوية مرفقة لا يستطيع تقديم وثائق هوية لم يجمعها قط، وهذا هو السبب البسيط الذي يجعل الاستضافة بلا KYC والاتصالات المستضافة ذاتيًا تظهران معًا في الحديث نفسه دائمًا. لا واحدة منهما دفاع أمام محكمة تعرف اسمك أصلًا، ودليلنا حول الأمن التشغيلي (OpSec) صريح بشأن أين يقع ذلك الخط.
الخلاصة
إن كنت ستأخذ ستة أشياء من هذه الصفحة، فلتكن هذه:
- اختر
server_nameقبل تثبيت أي شيء — إنه القرار الوحيد الذي لن تستطيع مراجعته أبدًا. - فوّض باستخدام
/.well-known/matrix/serverأو سجل SRV، وحافظ على TLS صالح على كلا الاسمين. - قدّر الحجم بناءً على الغرف التي سينضم إليها مستخدموك، لا بناءً على عددهم.
- اضبط سياسة الاحتفاظ بالوسائط منذ اليوم الأول، وقرّر أمر معاينات الروابط بدلًا من وراثة الإعداد الافتراضي.
- أبقِ التسجيل مغلقًا أو مقيَّدًا برموز؛ فسمعة النطاق المحترقة مكلفة التراجع عنها.
- انسخ
signing.keyاحتياطيًا بمعزل عن غيره، ولا تُعِد قاعدة البيانات إلى الوراء خلف أقرانك أبدًا.
افعل ذلك وسيكون الخادم عاديًا بلا أي لفت للنظر، وهذا بالضبط ما ينبغي أن يكون عليه خادم دردشة. أما ما تحصل عليه في المقابل فيستحق أن تكون واضح النظر بشأنه: ليس عدم الظهور، وليس بروتوكولًا يخفي من يتحدث إلى من، بل محادثات محتواها ملكك أنت، وحساب لا يستطيع أحد آخر إغلاقه، وجهاز يقع تحت نظام قانوني اخترته أنت بتعمّد. ضع خادمًا ذاتيًا في مكان اخترته، ودع الفيدرالية تأتي إليه.